summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2014-06-05drm/panel: simple - Disable panel on shutdownThierry Reding
When a device is shut down, disable the panel to make sure the display backlight doesn't stay lit. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/panel: add support for EDT ET057090DHU panelStefan Agner
This panel is sold by Toradex for Colibri T20/T30 and Apalis T30 evaluation kits. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panelsPhilipp Zabel
The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels, which can be supported by the simple panel driver. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/panel: ld9040: add power control sequenceAndrzej Hajda
Some ld9040 panels do not start without providing power control sequence during initialization. The patch fixes the driver by providing such sequence for all panels. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/panel: s6e8aa0: silence array overflow warningDan Carpenter
Smatch complains that we are reading beyond the end of the array here: drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id() warn: buffer overflow 's6e8aa0_variants' 4 <= 4 We set the error code, so it's not harmful but it looks like a return was intended here so lets add that and silence the warning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/dsi: Support device shutdownThierry Reding
Hook up the MIPI DSI bus's .shutdown() function to allow drivers to implement code that should be run when a device is shut down. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-06-05drm/i915: BDW: Adding missing cursor offsets.Rodrigo Vivi
BDW uses IVB cursor offsets. Whithout this patch it is not possible to use multiple outputs with cursor on BDW. The cursor gets completely crazy because update position uses the wrong cursor register for the second pipe. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79621 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm: Fix getconnector connection_mutex lockingDaniel Vetter
I've fumbled my own idea and enthusiastically wrapped all the getconnector code with the connection_mutex. But we only need it to chase the connector->encoder link. Even there it's not really needed since races with userspace won't matter, but better paranoid and consistent about this stuff. If we grap it everywhere connector probe callbacks can't grab it themselves, which means they'll deadlock. i915 does that for the load detect pipe. Furthermore i915 needs to do a ww dance since we also need to grab the mutex of the load detect crtc. This is a regression from commit 6e9f798d91c526982cca0026cd451e8fdbf18aaf Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 29 23:54:47 2014 +0200 drm: Split connection_mutex out of mode_config.mutex (v3) Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05i2c: pca954x: Fix compilation without CONFIG_GPIOLIBLaurent Pinchart
The pca954x driver recently switched to the GPIO descriptor API without including the correct <linux/gpio/consumer.h> header. This breaks compilation without CONFIG_GPIOLIB. drivers/i2c/muxes/i2c-mux-pca954x.c: In function ‘pca954x_probe’: drivers/i2c/muxes/i2c-mux-pca954x.c:204:2: error: implicit declaration of function ‘devm_gpiod_get’ [-Werror=implicit-function-declaration] gpio = devm_gpiod_get(&client->dev, "reset"); ^ drivers/i2c/muxes/i2c-mux-pca954x.c:204:7: warning: assignment makes pointer from integer without a cast [enabled by default] gpio = devm_gpiod_get(&client->dev, "reset"); ^ drivers/i2c/muxes/i2c-mux-pca954x.c:206:3: error: implicit declaration of function ‘gpiod_direction_output’ [-Werror=implicit-function-declaration] gpiod_direction_output(gpio, 0); ^ cc1: some warnings being treated as errors make[3]: *** [drivers/i2c/muxes/i2c-mux-pca954x.o] Error 1 Fix it by including the right header. Reported-by: Jim Davis <jim.epost@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-06-05ACPI: Fix bug when ACPI reset register is implemented in system memoryRandy Wright
Use acpi_os_map_generic_address to pre-map the reset register if it is memory mapped, thereby preventing the BUG_ON() in line 1319 of mm/vmalloc.c from triggering during panic-triggered reboots. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77131 Signed-off-by: Randy Wright <rwright@hp.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> [rjw: Changelog, simplified code] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-05regulator: palmas: Fix SMPS list for 0VNishanth Menon
get_voltage_sel reads from SMPS register - if the read selector value is 0, the SMPS is actually disabled - So, this is in addition to the ctrl_register that may also be used to enable/disable the SMPS. The original logic(prior to commit dbabd624d4eec50b6) used to be: static int palmas_map_voltage_smps(struct regulator_dev *rdev, int min_uV, int max_uV) <snip> if (min_uV == 0) return 0; To handle this scenario, with the transition to regulator_list implementation, we seem to have missed the data necessary to mark as one of the valid entries as "0" 'disabled regulator' which results in 0 volts - So, stick with pre-existing logic. Without this added to the list, palmas regulator driver, on probe, attempts to setup constraints and in the case of OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in regulator_list_voltage_linear_range mapping of '0', and as a fall back of constraints not being applied, the entire regulator list is not enumerated due to assumption that something system wide has gone bad on with the PMIC. Fixes: dbabd624d4eec50b6 ("regulator: palmas: Reemove open coded functions with helper functions") Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-05Merge commit '9e9a928eed8796a0a1aaed7e0b676db86ba84594' into drm-nextDave Airlie
Merge drm-fixes into drm-next. Both i915 and radeon need this done for later patches. Conflicts: drivers/gpu/drm/drm_crtc_helper.c drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_execbuffer.c drivers/gpu/drm/i915/i915_gem_gtt.c
2014-06-05cpuidle: Set polling in poll_idleAndy Lutomirski
poll_idle is the archetypal polling idle loop; tell the core idle code about it. This avoids pointless IPIs when all of the other cpuidle states are disabled. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: nicolas.pitre@linaro.org Cc: umgwanakikbuti@gmail.com Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/c65ce49615d338bae8fb79df5daffab19353c900.1401902905.git.luto@amacapital.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-05i40e: add missing VSI statisticsShannon Nelson
Add a couple more statistics that the hardware offers but aren't part of the standard netdev stats. Change-ID: I201db2898f2c284aee3d9631470bc5edd349e9a5 Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e/i40evf: remove rx_errors and rx_missedShannon Nelson
The rx_errors (GLV_REPC) and rx_missed (GLV_RMPC) were removed from the chip design. Change-ID: Ifdeb69c90feac64ec95c36d3d32c75e3a06de3b7 Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: refactor stats collectionShannon Nelson
Pull the PF stat collection out of the VSI collection routine, and add a unifying stats update routine to call the various stat collection routines. Change-ID: I224192455bb3a6e5dc0a426935e67dffc123e306 Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: refactor send versionJesse Brandeburg
This change moves some common code in two places into a small helper function, and corrects a bug in one of the two places in the process. Change-ID: If3bba7152b240f13a7881eb0e8a781655fa66ce7 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e/i40evf: VEB structure added, GTIME macro updateKamil Krawczyk
Structure for VEB context added. Update macro for transition from ms to GTIME (us) time units. Change-ID: Ib3a19587b4cf355348655df8f60c6f37bb1497a3 Signed-off-by: Kamil Krawczyk <kamil.krawczyk@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: notify VF of all types of resetsMitch Williams
Currently, the PF driver only notifies the VFs for PF reset events. Instead, notify the VFs for all types of resets, so they can attempt a graceful reinit. Change-ID: I03eb7afde25727198ef620f8b4e78bb667a11370 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40evf: fix crash when changing ring sizesMitch Williams
i40evf_set_ringparam was broken in several ways. First, it only changed the size of the first ring, and second, changing the ring size would often result in a panic because it would change the count before deallocating resources, causing the driver to either free nonexistent buffers, or leak leftover buffers. Fix this by storing the descriptor count in the adapter structure, and updating the count for each ring each time we allocate them. This ensures that we always free the right size ring, and always end up with the requested count when the device is (re)opened. Change-ID: I298396cd3d452ba8509d9f2d33a93f25868a9a55 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40evf: set descriptor multiple to 32Mitch Williams
Hardware requires descriptors to be allocated in groups of 32. Change-ID: I752ccc96769d1bd8d3018c004b8aeff464045bf2 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Sibai Li <sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chipTony Lindgren
If the GPIO for the backlight is on an I2C chip, we currently get nasty warnings like this during the boot: WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c() Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400 Workqueue: deferwq deferred_probe_work_func [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14) [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c) [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c) [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24) [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c) [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74) [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254) [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48) [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238) [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c) [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c) [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0) [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94) [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc) [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398) [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4) [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c) Fix this by using gpio_set_value_cansleep() as suggested in drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers are also doing. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-06-05i40e: clamp jumbo frame sizeJesse Brandeburg
The driver was allowing the user to set larger size MTU than the hardware was being configured to support. The driver was already using VLAN_HLEN when setting the hardware max receivable frame size, so just add it to the netdev MTU set entry point as well. Change-ID: Ie20e2a35d04f8c411253e255bea79ca69aaeaea3 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e/i40evf: remove unused RX_LRO defineJesse Brandeburg
Remove unused defines and macros for RX_LRO. Change-ID: I8ca6715edfa62b56837417a1c4ff68c2345dab6e Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Jim Young <jamesx.m.young@intel.com> Tested-by: Sibai Li <sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: remove check for large bufferKamil Krawczyk
We introduced this check in case this structure changed in the future, the AQ definition is now mature enough that this check is no longer necessary. Change-ID: Ic66321d0a08557dc9d8cb84029185352cb534330 Signed-off-by: Kamil Krawczyk <kamil.krawczyk@intel.com> Tested-by: Jim Young <jamesx.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: Rework register diagnosticKamil Krawczyk
Register range, being subject to register diagnostic, can vary among different NVMs. We will try to identify the full range and use it for a register test. This is needed to avoid false test results. If we fail to define the proper register range we will test only the first register from that group. Change-ID: Ieee7173c719733b61d3733177a94dc557eb7b3fd Signed-off-by: Kamil Krawczyk <kamil.krawczyk@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05i40e: don't use OR to check a valueJesse Brandeburg
A couple of FD checks ended up using bitwise OR to check a value, which ends up always being evaluated to true. This should fix the issue. Thanks to DaveJ for noticing and reporting the issue! CC: Dave Jones <davej@redhat.com> Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-06-05md/raid5: deadlock between retry_aligned_read with barrier iohui jiao
A chunk aligned read increases counter active_aligned_reads and decreases it after sub-device handle it successfully. But when a read error occurs, the read redispatched by raid5d, and the active_aligned_reads will not be decreased until we can grab a stripe head in retry_aligned_read. Now suppose, a barrier io comes, set conf->quiesce to 2, and wait until both active_stripes and active_aligned_reads are zero. The retried chunk aligned read gets stuck at get_active_stripe waiting until conf->quiesce becomes 0. Retry_aligned_read and barrier io are waiting each other now. One possible solution is that we ignore conf->quiesce, let the retried aligned read finish. I reproduced this deadlock and test this patch on centos6.0 Signed-off-by: NeilBrown <neilb@suse.de>
2014-06-05drm/i915/bdw: Only use 2g GGTT for 32b platformsBen Widawsky
Daniel requested in the bug that I use a 3GB fallback size. Since this is not in the spec as a valid size, I decided against it. We could potentially add a patch to bump it to 3GB on top of this one. This probably should be CC: stable - but I'll let the powers that be decide that one. Regression from a revert of the revert: commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Feb 19 22:05:46 2014 -0800 Revert "drm/i915/bdw: Limit GTT to 2GB" v2: Change ifdef to 32b, instead of ifndef update comment v3. Update comment to not wrap (Daniel). Update commit message v4: s/CONFIG_32/CONFIG_X86_32 (Jani). v5: s/CONFIG_x86_32BIT/CONFIG_x86_32, as meant in v4 s/32B/32b (chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76619 Cc: stable@vger.kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: "Yang, Guang A" <guang.a.yang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Nuke pipe A quirk on i830MDaniel Vetter
Apparently it does more harm than good. Thomas Richter reports that it helps his machine (Thinkpad X31) and there's another report from a Fujitsu S6010. Also, we've nuked it on i845G already to make Chris' machine happy. Cc: Thomas Richter <richter@rus.uni-stuttgart.de> References: http://mid.mail-archive.com/538C54E0.8090507@rus.uni-stuttgart.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: fix display power sw state reportingImre Deak
Atm, we refcount both power domains and power wells and intel_display_power_enabled_sw() returns the power domain refcount. What the callers are really interested in though is the sw state of the underlying power wells. Due to this we will report incorrectly that a given power domain is off if its power wells were enabled via another power domain, for example POWER_DOMAIN_INIT which enables all power wells. As a fix return instead the state based on the refcount of all power wells included in the passed in power domain. References: https://bugs.freedesktop.org/show_bug.cgi?id=79505 References: https://bugs.freedesktop.org/show_bug.cgi?id=79038 Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Always apply cursor width changesChris Wilson
It is possible for userspace to create a big object large enough for a 256x256, and then switch over to using it as a 64x64 cursor. This requires the cursor update routines to check for a change in width on every update, rather than just when the cursor is originally enabled. This also fixes an issue with 845g/865g which cannot change the base address of the cursor whilst it is active. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [Antti:rebased, adjusted macro names and moved some lines, no functional changes] Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Tested-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Cc: stable@vger.kernel.org Testcase: igt/kms_cursor_crc/cursor-size-change Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: tell the user if both KMS and UMS are disabledJani Nikula
If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might not be aware his setup is not supported. Inform the users (and, by extension, the poor i915 developers having to read their dmesgs in bug reports) why their graphics experience might be lacking. A similar message was added on the UMS path in commit e147accbd19f55489dabdcc4dc3551cc3e3f2553 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 10 15:25:37 2013 +0300 drm/i915: tell the user KMS is required for gen6+ but it won't be reached if CONFIG_DRM_I915_UMS=n since commit b30324adaf8d2e5950a602bde63030d15a61826f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 13 22:11:25 2013 +0100 drm/i915: Deprecated UMS support v2: Use DRM_DEBUG_DRIVER. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/plane-helper: Add drm_plane_helper_check_update() (v3)Matt Roper
Pull the parameter checking from drm_primary_helper_update() out into its own function; drivers that provide their own setplane() implementations rather than using the helper may still want to share this parameter checking logic. A few of the checks here were also updated based on suggestions by Ville Syrjälä. v3: - s/primary_helper/plane_helper/ --- this checking logic may be useful for other types of planes as well. - Fix visibility check (need to dereference visibility pointer) v2: - Pass src/dest/clip rects and min/max scaling down to helper to avoid duplication of effort between helper and drivers (suggested by Ville). - Allow caller to specify whether the primary plane should be updatable while the crtc is disabled. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> [danvet: Include header properly and fixup declaration mismatch to make this compile.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm: Check CRTC compatibility in setplaneMatt Roper
The DRM core setplane code should check that the plane is usable on the specified CRTC before calling into the driver. Prior to this patch, a plane's possible_crtcs field was purely informational for userspace and was never actually verified at the kernel level (aside from the primary plane helper). Cc: dri-devel@lists.freedesktop.org Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: use VBT to determine whether to enumerate the VGA portJesse Barnes
Some platforms may not have it, and enumerating it is both confusing and time consuming due to the hotplug and DDC probing. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Don't WARN about ring idle bit on gen2Ville Syrjälä
Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register, so don't go spewing warnings about the state of those bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent objectChris Wilson
If the user tries to mmap through the GTT an object that is marked as snooped, we report an error rather than allow the GPU to hang the machine. The choice of EINVAL, however, was unfortunate as we turn that into a WARN rather than a quiet SIGBUS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() for KMSVille Syrjälä
Move the MI_ARB_STATE MI_ARB_C3_LP_WRITE_ENABLE setup to gen3_init_clock_gating() from i915_gem_load() when KMS is enabled. Leave it in i915_gem_load() for the UMS case, but add an explcit check, just to make it easier to spot it when we eventually rip out UMS support. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Enable interrupt-based AGPBUSY# enable on 85xVille Syrjälä
85x also has a similar AGPBUSY# bit as gen3. Enable it to make sure vblank interrupts don't get dealyed during C3 state. There's also another bit which controls whether AGPBUSY# is asserted based on pending cacheable cycles and interrupts, or just based on pending commands in the ring and interrupts. Select the cacheable cycles mode since that seems to be the new way of doing things in 85x, and it does give slightly better C3 residency numbers with glxgears running. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Flip the sense of AGPBUSY_DIS bitVille Syrjälä
My Gen3 Bspec lists the AGPBUSY# bit in INSTPM as an enable bit rather than a disable bit. Our code has the opposite idea. Make the code match the spec. Might fix some gen3 C3 related interrupt delivery problems. Untested due to lack of hardware. v2: call it AGPBUSY_INT_EN to make it clearer it has to do with interrupts Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Set AGPBUSY# bit in init_clock_gatingVille Syrjälä
I don't see why we wouldn't want interrupts to wake up the CPU from C3 always, so just set the AGPBUSY# bit in gen3_init_clock_gating(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: add pll assertion when disabling DPIO common wellJesse Barnes
When doing this, all PLLs should be disabled. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_wellJesse Barnes
We need to do this anytime we power gate the DPIO common well. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: re-order power wells so DPIO common comes after TXJesse Barnes
There may be a dependency here. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: move CRI refclk enable into __vlv_set_power_wellJesse Barnes
This needs to be done before we power back on the CMN_BC well so the PHY can calibrate properly. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: drop power well enable in uncore_sanitizeJesse Barnes
We do this at runtime and later on now. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3Jesse Barnes
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except that it resets the whole common lane section of the PHY. This is required on machines where the BIOS doesn't do this for us on boot or resume to properly re-calibrate and get the PHY ready to transmit data. Without this patch, such machines won't resume correctly much of the time, with the symptom being a 'port ready' timeout and/or a link training failure. Note that simply asserting reset at suspend and de-asserting at resume is not sufficient, nor is simply de-asserting at boot. Both of these cases have been tested and have still been found to have failures on some configurations. v2: extract simpler set_power_well function for use in reset_dpio (Imre) move to reset_dpio (Daniel & Ville) v3: don't reset if DPIO reset is already de-asserted (Imre) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable orderingImre Deak
If we disable first the port (by disabling DPI) and only then the display pipe the pipe-off flag will never be set, possibly leading to a hanged pipe state at the next modeset-enable. Note that according to the VLV2 display cluster HAS, we should disable the port before the pipe. This doesn't seem to match reality based on the above and it's also asymmetric with the enabling sequence, where we first enable the port and then the pipe. v2: - send the panel shutdown command before stopping the pipe, since this is the recommended sequence (Shobhit) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-05drm/i915: Detect if MIPI panel based on VBT and initialize only if presentShobhit Kumar
It seems by default the VBT has MIPI configuration block as well. The Generic driver will assume always MIPI if MIPI configuration block is found. This is causing probelm when actually there is eDP. Fix this by looking into general definition block which will have device configurations. From here we can figure out what is the LFP type and initialize MIPI only if MIPI is found. v2: Addressed review comments by Damien - Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA - renamed is_mipi to has_mipi and moved definition as suggested - Check has_mipi inside parse_mipi and intel_dsi_init insted of outside v3: Make has_mipi as a bitfield as suggested Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: fold in conditions to pack everything neatly below 80 chars.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit (git 2.34.1) at 2025-10-02 15:46:31 +0000