- 30 Mar, 2016 5 commits
-
-
Matthew Auld authored
Lets BUG_ON and don't bother with a WARN and returning an error, so we can remove the need to pollute the code with error handling, after all it is a programmer error to provide NULL view. Also while we're here remove redundant NULL ggtt_view check. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Bjørn Mork authored
commit e2c8b870 moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 #385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] #6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
-
Daniel Vetter authored
Signed-off-by: -
Lyude authored
Since we need MST devices ready before we try to resume displays, calling this after intel_display_resume() can result in some issues with various laptop docks where the monitor won't turn back on after suspending the system. This order was originally changed in commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state") In order to fix some unclaimed register errors, however the actual cause of those has since been fixed. CC: stable@vger.kernel.org Signed-off-by:
Lyude <cpaul@redhat.com> [danvet: Resolve conflicts with locking changes.] Signed-off-by:
-
Lukas Wunner authored
The ->lastclose callback invokes intel_fbdev_restore_mode() and has been witnessed to run before intel_fbdev_initial_config_async() has finished. We might likewise receive hotplug events before we've had a chance to fully set up the fbdev. Fix by waiting for the asynchronous thread to finish. v2: An async_synchronize_full() was also added to intel_fbdev_set_suspend() in v1 which turned out to be entirely gratuitous. It caused a deadlock on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela for CI support) and was unnecessary since a device is never suspended until its ->probe callback (and all asynchronous tasks it scheduled) have finished. See dpm_prepare(), which calls wait_for_device_probe(), which calls async_synchronize_full(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Reported-by:
Gustav Fägerlind <gustav.fagerlind@gmail.com> Reported-by:
"Li, Weinan Z" <weinan.z.li@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
- 29 Mar, 2016 4 commits
-
-
Jani Nikula authored
Set from VBT, but never used. Good riddance. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-5-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
Move all data initialized from VBT under dev_priv->vbt. No functional changes. Reviewed-by:
-
Jani Nikula authored
Move all data initialized from VBT under dev_priv->vbt. No functional changes. Reviewed-by:
-
Jani Nikula authored
Housekeeping, similar to psr, backlight, and dsi. No functional changes. Reviewed-by:
-
- 24 Mar, 2016 4 commits
-
-
Dave Gordon authored
Having provided for_each_engine_id() for cases where the third (id) argument is useful, we can now replace all the remaining instances with a simpler version that takes only two parameters. In many cases, this also allows the elimination of the local variable used in the iterator (usually 'i'). v2: s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson] Signed-off-by:Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458757194-17783-2-git-send-email-david.s.gordon@intel.com
-
Dave Gordon authored
Equivalent to the existing for_each_engine() macro, this will replace the latter wherever the third argument *is* actually wanted (in most places, it is not used). The third argument is renamed to emphasise that it is an engine id (type enum intel_engine_id). All the callers of the macro that actually need the third argument are updated to use this version, and the argument (generally 'i') is also updated to be 'id'. Other callers (where the third argument is unused) are untouched for now; they will be updated in the next patch. Signed-off-by:
-
Imre Deak authored
Currently the machine hangs during booting while accessing the BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some experimentation I found that the hang is caused by the DSI PLL being disabled, or it being enabled but with an incorrect divider configuration. Enabling the PLL got rid of the boot problem, so fix this by checking the PLL enabled state/configuration before attempting to read out the HW state. The DSI_PLL_ENABLE register is in the always-on power well, while the BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the transcoder power domain, but what we really need is just a runtime PM reference, which is provided by any power domain. Ville also found this dependency specified in BSpec, so I added a reference to that too. v2: - Make sure we hold a power reference while accessing the PLL registers. v3: (Jani) - Simplify check in bxt_get_dsi_transcoder_state() - Add comment explaining why we check for valid dividers in bxt_dsi_pll_is_enabled() CC: Shashank Sharma <shashank.sharma@intel.com> CC: Uma Shankar <uma.shankar@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Fixes: c6c794a2 ("drm/i915/bxt: Initialize MIPI DSI for BXT") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458816100-31269-1-git-send-email-imre.deak@intel.com
-
Maarten Lankhorst authored
intel_post_plane_update did an extra vblank wait that's no longer needed when enabling ips. Changes since v1: - Add comment explaining why vblank wait is performed. (Paulo) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56F29B28.5070804@linux.intel.com
-
- 23 Mar, 2016 18 commits
-
-
Chris Wilson authored
In commit 0a878716 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 14:23:01 2015 +0200 drm/i915: restore ggtt double-bind avoidance we wrote the ggtt_bind_vma() observing a number of cleanups we could do over the template of aliasing_gtt_bind_vma(). Now let's apply the cleanups we made there back to the original. The essence is to avoid redundant variables and assignements, and by doing so make the code easier to read. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split a pnv_crtc_compute_clock(), so the differences between platforms become more obvious. With this, there are no more users of intel_limit() or the ->find_dpll() hook, so get rid of them. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-16-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Split a G4X specific version from i9xx_crtc_compute_clock(). With this the differences between platforms become more obvious. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this there is no need for i9xx_get_refclk() anymore, and the differences between platforms become more obvious. v2: Use i8xx as prefix instead of gen2. (Ville and Daniel) Signed-off-by:
-
Ander Conselvan de Oliveira authored
In order for VLV and CHV to use i9xx_crtc_compute_clocks(), a number of if ladders is necessary: one for setting the find_dpll() hook, one for choosing the limits struct, one for choosing the right compute dpll function and one for initializing the crtc_compute_clock() hook. By extracting a platform specific implementation for each platform, the number of if-ladders is reduced to one. While at it also clean up bxt_find_best_dpll() which depends on some of the CHV code. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Merge ironlake_compute_clocks() into ironlake_crtc_compute_clock() so the clock computation logic is all in one place. The resulting function is still quite simple. Follow up patches will make the similar code for GMCH platforms look similar. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and move the lower level details of setting crtc_state->dpll_hw_state into the _compute_dpll() function. Reviewed-by:
-
Ander Conselvan de Oliveira authored
When calculating clocks, just pass a pointer to crtc_state->dpll directly to the find_dpll() hook. Back when this was introduced in commit f47709a9 ("drm/i915: create pipe_config->dpll for clock state") there was no staged crtc config or atomic crtc state, so it was possible to overwrite the current configuration on error. That hasn't been the case for a while now, so finally make it "disappear". Signed-off-by:
-
Ander Conselvan de Oliveira authored
None of the code in ironlake_crtc_compute_clock() is relevant for CPU eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off} from the DP code and that doesn't depend on the crtc_state->dpll values, so just return early in that case. v2: Rebase without patch that drops lvds downclock code. (Ville) Signed-off-by: -
Ander Conselvan de Oliveira authored
The checks were added in commit 5dc5298b ("drm/i915: add proper CPU/PCH checks to crtc_mode_set functions") in a time when there was doubts on what PCHs would be supported by HSW. There are similar checks for PCH type in intel_detect_pch() and the function pointers are initialized based on platform/pch information, so the removed WARN can't ever be reached. v2: Rebase without patch that drops lvds downclock code. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Remove the clock calculation from ironlake_crtc_compute_clock() when the encoder compute_config() already set one. The value was just thrown away in that case. Note that the previously set clock is not validated against the limits anymore. That is ok since the fixed clocks from DP and SDVO are within the supported range, so the call to ironlake_compute_clocks() would never fail in that case. v2: Add note about not checking fixed clocks agains limits. (Maarten) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Check has_reduced_clock only once when setting dpll_hw_state, making the code slightly more readable. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The call to dev_priv->display.find_dpll() is already in platform specific code, so avoid the extra detour. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function intel_ironlake_limit() is only called by the crtc compute clock path. By merging it into ironlake_compute_clocks(), the code gets clearer, since there's no more if-ladders to follow. Signed-off-by:
-
Ander Conselvan de Oliveira authored
A previous patch made ironlake_get_refclk() very simple, so merge it into its only caller. Signed-off-by:
-
Ander Conselvan de Oliveira authored
LVDS is not cloneable, so the check is unnecessary. Removing it makes the code neater. v2: Remove checks from GMCH code too, not only ILK+. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The wait for other gens was added in commit 564ed191 ("drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode") since that's necessary when disabling cxsr. However, cxsr disabling was later moved to intel_pre_disable_primary() in commit 87d4300a ("drm/i915: Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use it there.") and that function got its own vblank wait for cxsr in commit 262cd2e1 ("drm/i915: CHV DDR DVFS support and another watermark rewrite"). So remove the extra vblank wait from i9xx_crtc_distable(). Cc: Kalyan Kondapally <kalyan.kondapally@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Commit d15d7538 ("drm/i915: Tune down init error message due to failure injection") added i915_load_error message to failure path on device initialization. The message is printed after the device is freed. And as the message printing helper uses the device structure, this leads to use after free. Spotted by Kasan. Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
- 22 Mar, 2016 5 commits
-
-
Shashank Sharma authored
This patch contains following changes: 1. Add BXT MIPI display address base. 2. Call dsi_init from display_setup function. v2: Rebased on latest nightly branch v3 by Jani: init dsi after ddi Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Acked-by:
-
Imre Deak authored
Joonas and Daniel remarked that our debugging output should stay compatible with the core DRM's debug facility. The recently added __i915_printk() would output debug messages even if debugging is completely disabled via the drm.debug option. To fix this make __i915_printk behave the same as DRM_DEBUG_DRIVER in this case. CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Matt Roper authored
At the end of an atomic commit, we currently wait for vblanks to complete, call put() on the various runtime PM references, and then try to optimize our watermarks (on platforms that need two-step watermark programming). This can lead to watermark registers being programmed while the power well is powered down. We need to wait until after watermark optimization is complete before dropping our runtime power references. Note that in the future the watermark optimization is probably going to move to an asynchronous workqueue task that happens at some arbitrary point after vblank. When we make that change, we'll no longer necessarily be operating under the power reference held here, so we'll need to wrap the watermark register programmin in a call to intel_runtime_pm_get_if_in_use() or similar. Cc: arun.siluvery@linux.intel.com Cc: ville.syrjala@linux.intel.com Cc: maarten.lankhorst@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94349 Fixes: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)") Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
arun.siluvery@linux.intel.com authored
In preparation for engine reset, the wedged argument of i915_handle_error() is extended to reflect as a mask of engines that are hung. This is further passed down to error state capture functions which are also updated. Engine reset recovery mechanism uses this mask and schedules recovery work for those particular engines. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
Tomas Elf authored
Initialize hangcheck struct during driver load. Since we do the same after recovering from a reset, this is extracted into a helper function. v2: remove redundant hangcheck init during load as this is done when engines are initialized (Chris) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
- 21 Mar, 2016 4 commits
-
-
Lionel Landwerlin authored
Patch based on a previous series by Shashank Sharma. v2: Update contributors v3: Refactor degamma/gamma LUTs load into a single function v4: Remove unused variable Signed-off-by:
Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by:
Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor degamma/gamma LUTs load into a single function v6: Fix missing intel_crtc variable (bisect issue) v7: Fix & simplify limited range matrix multiplication (Matt Roper's comment) Signed-off-by: -
Lionel Landwerlin authored
Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. v2: Read GAMMA_MODE register value at init (Matt Roper's comment) v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along with other registers (Matt Roper's comment). v4: Mask GAMMA_MODE register with interesting bits when reading Signed-off-by: -
Lionel Landwerlin authored
The moves a couple of functions programming the gamma LUT and CSC units into their own file. On generations prior to Haswell there is only a gamma LUT. From haswell on there is also a new enhanced color correction unit that isn't used yet. This is why we need to set the GAMMA_MODE register, either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or 12bits). The CSC unit is only available from Haswell on. We also need to make a special case for CherryView which is recognized as a gen 8 but doesn't have the same enhanced color correction unit from Haswell on. v2: Fix access to GAMMA_MODE register on older generations than Haswell (from Matt Roper's comments) Signed-off-by:
-
