aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2014-09-08drm/i915: Wait for vblank before enabling the TV encoderVille Syrjälä1-0/+4
The vblank waits in intel_tv_detect_type() are timing out for some reason. This is a regression caused removing seemingly useless vblank waits from the modeset seqeuence in: commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f Author: Ville Syrjälä <[email protected]> Date: Thu May 8 19:23:15 2014 +0300 drm/i915: Kill vblank waits after pipe enable on gmch platforms So it turns out they weren't all entirely useless. Apparently the pipe has to go through one full frame before we enable the TV port. Add a vblank wait to intel_enable_tv() to make sure that happens. Another approach was attempted by placing the vblank wait just after enabling the port. The theory behind that attempt was that we need to let the port stay enabled for one full frame before disabling it again during load detection. But that didn't work, and we definitely must have the vblank wait before enabling the port. Cc: [email protected] Cc: Alan Bartlett <[email protected]> Tested-by: Alan Bartlett <[email protected]> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311 Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-08drm/i915: Evict CS TLBs between batchesChris Wilson2-31/+47
Running igt, I was encountering the invalid TLB bug on my 845g, despite that it was using the CS workaround. Examining the w/a buffer in the error state, showed that the copy from the user batch into the workaround itself was suffering from the invalid TLB bug (the first cacheline was broken with the first two words reversed). Time to try a fresh approach. This extends the workaround to write into each page of our scratch buffer in order to overflow the TLB and evict the invalid entries. This could be refined to only do so after we update the GTT, but for simplicity, we do it before each batch. I suspect this supersedes our current workaround, but for safety keep doing both. v2: The magic number shall be 2. This doesn't conclusively prove that it is the mythical TLB bug we've been trying to workaround for so long, that it requires touching a number of pages to prevent the corruption indicates to me that it is TLB related, but the corruption (the reversed cacheline) is more subtle than a TLB bug, where we would expect it to read the wrong page entirely. Oh well, it prevents a reliable hang for me and so probably for others as well. Signed-off-by: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-08drm/i915: Fix irq enable tracking in driver loadDaniel Vetter1-2/+7
A bunch of warnings fire on some ->irq_postinstall hooks since those can enable interrupts (e.g. rps interrupts). And then our ordering self-checks fire and complain. To fix that set the tracking boolen before enabling the irqs with drm_irq_install. Quoting the discussion with Jesse why that's safe: On Tue, Aug 26, 2014 at 11:18 PM, Jesse Barnes <[email protected]> wrote: > Yes, it might work, but if you look through the history, we set this > field carefully; first to true in the irq_init code, then to false only > after the irq_install completes. So I think your fragility arguments > apply to this change too. Well we've done it in 4 commits or so, but currently we have: - Set irqs_disabled to true early in driver load to make sure checks that. That's done in irq_init, which is totally not the function that enables interrupts, only the function that initializes all the vtables and similar things. We actually have a fairly sane naming scheme nowadays (not fully consistent ofc): _init is sw setup, _enable/_hw_init is the actual hw setup. That is done in 95f25beddba2ec9510b249740bacc11eca70cf75 - Set irqs_disabled to false right after the irqs are actually enabled. This is done in ed2e6df18935beb3d63613c50103bf9757b2aa85 So my change should only move the flag change over the ->preinstall and ->postinstall hooks. I've done a little audit and didn't spot anything amiss. Furthermore the runtime pm setup already clears irqs_disabled _before_ calling these two hooks. This regression has been introduced in commit ed2e6df18935beb3d63613c50103bf9757b2aa85 Author: Jesse Barnes <[email protected]> Date: Fri Jun 20 09:39:36 2014 -0700 drm/i915: clear pm._irqs_disabled field after installing IRQs Cc: Jesse Barnes <[email protected]> Cc: Oliver Hartkopp <[email protected]> Tested-by: Oliver Hartkopp <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Tested-by: Chris Wilson <[email protected]> # gm45, ilk Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-08drm/i915: Fix EIO/wedged handling in gem fault handlerDaniel Vetter1-4/+7
In commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c Author: Daniel Vetter <[email protected]> Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions I've accidentally inverted the EIO/wedged handling in the fault handler: We want to return the EIO as a SIGBUS only if it's not because of the gpu having died, to prevent userspace from unduly dying. In my defence the comment right above is completely misleading, so fix both. v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO when swap-in fails. v3: Don't remove too much ... oops. Reported-by: Chris Wilson <[email protected]> Cc: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-08drm/i915: Prevent recursive deadlock on releasing a busy userptrChris Wilson2-184/+235
During release of the GEM object we hold the struct_mutex. As the object may be holding onto the last reference for the task->mm, calling mmput() may trigger exit_mmap() which close the vma which will call drm_gem_vm_close() and attempt to reacquire the struct_mutex. In order to avoid that recursion, we have to defer the mmput() until after we drop the struct_mutex, i.e. we need to schedule a worker to do the clean up. A further issue spotted by Tvrtko was caused when we took a GTT mmapping of a userptr buffer object. In that case, we would never call mmput as the object would be cyclically referenced by the GTT mmapping and not freed upon process exit - keeping the entire process mm alive after the process task was reaped. The fix employed is to replace the mm_users/mmput() reference handling to mm_count/mmdrop() for the shared i915_mm_struct. INFO: task test_surfaces:1632 blocked for more than 120 seconds.       Tainted: GF          O 3.14.5+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. test_surfaces   D 0000000000000000     0  1632   1590 0x00000082  ffff88014914baa8 0000000000000046 0000000000000000 ffff88014914a010  0000000000012c40 0000000000012c40 ffff8800a0058210 ffff88014784b010  ffff88014914a010 ffff880037b1c820 ffff8800a0058210 ffff880037b1c824 Call Trace:  [<ffffffff81582499>] schedule+0x29/0x70  [<ffffffff815825fe>] schedule_preempt_disabled+0xe/0x10  [<ffffffff81583b93>] __mutex_lock_slowpath+0x183/0x220  [<ffffffff81583c53>] mutex_lock+0x23/0x40  [<ffffffffa005c2a3>] drm_gem_vm_close+0x33/0x70 [drm]  [<ffffffff8115a483>] remove_vma+0x33/0x70  [<ffffffff8115a5dc>] exit_mmap+0x11c/0x170  [<ffffffff8104d6eb>] mmput+0x6b/0x100  [<ffffffffa00f44b9>] i915_gem_userptr_release+0x89/0xc0 [i915]  [<ffffffffa00e6706>] i915_gem_free_object+0x126/0x250 [i915]  [<ffffffffa005c06a>] drm_gem_object_free+0x2a/0x40 [drm]  [<ffffffffa005cc32>] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm]  [<ffffffffa005ccd4>] drm_gem_object_release_handle+0x64/0x90 [drm]  [<ffffffff8127ffeb>] idr_for_each+0xab/0x100  [<ffffffffa005cc70>] ? drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm]  [<ffffffff81583c46>] ? mutex_lock+0x16/0x40  [<ffffffffa005c354>] drm_gem_release+0x24/0x40 [drm]  [<ffffffffa005b82b>] drm_release+0x3fb/0x480 [drm]  [<ffffffff8118d482>] __fput+0xb2/0x260  [<ffffffff8118d6de>] ____fput+0xe/0x10  [<ffffffff8106f27f>] task_work_run+0x8f/0xf0  [<ffffffff81052228>] do_exit+0x1a8/0x480  [<ffffffff81052551>] do_group_exit+0x51/0xc0  [<ffffffff810525d7>] SyS_exit_group+0x17/0x20  [<ffffffff8158e092>] system_call_fastpath+0x16/0x1b v2: Incorporate feedback from Tvrtko and remove the unnessary mm referencing when creating the i915_mm_struct and improve some of the function names and comments. Reported-by: Jacek Danecki <[email protected]> Test-case: igt/gem_userptr_blits/process-exit* Signed-off-by: Chris Wilson <[email protected]> Tested-by: "Gong, Zhipeng" <[email protected]> Cc: Jacek Danecki <[email protected]> Cc: "Ursulin, Tvrtko" <[email protected]> Reviewed-by: "Ursulin, Tvrtko" <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: [email protected] # hold off until 3.17 ships for additional testing Signed-off-by: Jani Nikula <[email protected]>
2014-09-02drm/i915: Fix lock dropping in intel_tv_detect()Ville Syrjälä1-3/+7
When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä <[email protected]> Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() v2: Make the code more readable (Chris) v3: Drop WARN_ON(type < 0) (Chris) Cc: [email protected] Cc: Tibor Billes <[email protected]> Reported-by: Tibor Billes <[email protected]> Tested-by: Tibor Billes <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-01drm/i915: handle G45/GM45 pulse detection connected state.Dave Airlie1-18/+37
In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Fixes: http://lkml.kernel.org/r/[email protected] Reported-by: Mike Galbraith <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-08-28drm/i915: Remove bogus __init annotation from DMI callbacksMathias Krause3-3/+3
The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: Mathias Krause <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Duncan Laurie <[email protected]> Cc: Jarod Wilson <[email protected]> Cc: Rusty Russell <[email protected]> # Can modpost be fixed? Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]>
2014-08-27drm/i915: don't warn if backlight unexpectedly enabledScot Doyle1-4/+4
BIOS or firmware can modify hardware state during suspend/resume, for example on the Toshiba CB35 or Lenovo T400, so log a debug message instead of a warning if the backlight is unexpectedly enabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80930 Cc: Jani Nikula <[email protected]> Signed-off-by: Scot Doyle <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-08-26drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to haswell_crtc_disable()Ville Syrjälä1-4/+3
Somehow the intel_ddi_set_vc_payload_alloc(false) call has ended up in ironlake_crtc_disable() rather than haswell_crtc_disable(). Move it to the correct place. intel_ddi_disable_transcoder_func() already disables the vc payload allocation so this doesn't actually do anything more. The spec says we should wait for some kind of ack after frobbing the bit. We don't appear to do that currently, but if and when someone decides that we should do it, intel_ddi_set_vc_payload_alloc() would appear to be be the right place for it. So having the function call in haswell_crtc_disable() seems like the right thing for the future even if it does nothing currently. Cc: Dave Airlie <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-08-26drm/i915: fix plane/cursor handling when runtime suspendedPaulo Zanoni1-0/+24
If we're runtime suspended and try to use the plane interfaces, we will get a lot of WARNs saying we did the wrong thing. We need to get runtime PM references to pin the objects, and to change the fences. The pin functions are the ideal places for this, but intel_crtc_cursor_set_obj() doesn't call them, so we also have to add get/put calls inside it. There is no problem if we runtime suspend right after these functions are finished, because the registers written are forwarded to system memory. Note: for a complete fix of the cursor-dpms test case, we also need the patch named "drm/i915: Don't try to enable cursor from setplane when crtc is disabled". v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel) v3: - Make get/put also surround the fence and unpin calls (Daniel and Ville). - Merge all the plane changes into a single patch since they're the same fix. - Add the comment requested by Daniel. v4: - Remove spurious whitespace (Ville). v5: - Remove intel_crtc_update_cursor() chunk since Ville did an equivalent fix in another patch (Ville). v6: - Remove unpin chunk: it will be on a separate patch (Ville, Chris, Daniel). v7: - Same thing, new color. Testcase: igt/pm_rpm/cursor Testcase: igt/pm_rpm/cursor-dpms Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603 Cc: [email protected] Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-08-26drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)Scot Doyle1-0/+3
commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <[email protected]> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a misconfigured VBT. Apply quirk to ignore the VBT backlight presence check during backlight setup. Signed-off-by: Scot Doyle <[email protected]> Tested-by: Tyler Cleveland <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] (3.15+) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: don't try to retrain a DP link on an inactive CRTCImre Deak1-0/+3
Atm we may retrain the DP link even if the CRTC is inactive through HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY (at least on BYT), since the DP port is disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948 Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: [email protected] (3.16+) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: make sure VDD is turned off during system suspendImre Deak3-0/+34
Atm we may leave eDP VDD enabled during system suspend after the CRTCs are disabled through an HPD->DPCD read event. So disable VDD during suspend at a point when no HPDs can occur. Note that runtime suspend doesn't have the same problem, since there the RPM ref held by VDD provides already the needed serialization. v2: - add note to commit message about the runtime suspend path (Ville) - use edp_panel_vdd_off_sync(), so we can keep the WARN in edp_panel_vdd_off() (Ville) v3: - rebased on -fixes (for_each_intel_encoder()->list_for_each_entry()) (Imre) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> (v2) Cc: [email protected] (3.16+) [Jani: fix sparse warning reported by Fengguang Wu] Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: cancel hotplug and dig_port work during suspend and unloadImre Deak3-2/+18
Make sure these work handlers don't run after we system suspend or unload the driver. Note that we don't cancel the handlers during runtime suspend. That could lead to a lockup, since we take a runtime PM ref from the handlers themselves. Fortunaltely canceling there is not needed since the RPM ref itself provides for the needed serialization. v2: - fix the order of canceling dig_port_work wrt. hotplug_work (Ville) - zero out {long,short}_hpd_port_mask and hpd_event_bits for speed (Ville) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Cc: [email protected] (3.16+) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: fix HPD IRQ reenable work cancelationImre Deak3-22/+14
Atm, the HPD IRQ reenable timer can get rearmed right after it's canceled. Also to access the HPD IRQ mask registers we need to wake up the HW. Solve both issues by converting the reenable timer to a delayed work and grabbing a runtime PM reference in the work. By this we can also forgo canceling the timer during runtime suspend, since the only important thing there is that the HW is awake when we write the registers and that's ensured by the RPM ref. So do the cancelation only during driver unload time; this is also a requirement for an upcoming patch where we want to cancel all HPD related works only during system suspend and driver unload time, but not during runtime suspend. Note that there is still a race between the HPD IRQ reenable work and drm_irq_uninstall() during driver unload, where the work can reenable the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since the HPD IRQs will still be effectively masked by the first level interrupt mask. v2-3: - unchanged v4: - use proper API for changing the expiration time for an already pending delayed work (Jani) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> (v2) Cc: [email protected] (3.16+) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: take display port power domain in DP HPD handlerImre Deak1-5/+14
Ville noticed that we can call ibx_digital_port_connected() which accesses the HW without holding any power well/runtime pm reference. Fix this by holding a display port power domain reference around the whole hpd_pulse handler. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Dave Airlie <[email protected]> Cc: [email protected] (3.16+) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: Don't try to enable cursor from setplane when crtc is disabledVille Syrjälä1-2/+2
Make sure the cursor gets fully clipped when enabling it on a disabled crtc via setplane. This will prevent the lower level code from attempting to enable the cursor in hardware. Cc: Paulo Zanoni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: Skip load detect when intel_crtc->new_enable==trueVille Syrjälä1-4/+8
During suspend we turn off the crtcs, but leave the staged config in place so that we can restore the display(s) to their previous state on resume. During resume when we attempt to apply the force pipe A quirk we use the load detect mechanism. That doesn't check whether there was an already staged configuration for the crtc since that's not even possible during normal runtime load detection. But during resume it is possible, and if we just blindly go and overwrite the staged crtc configuration for the load detection we can no longer restore the display to the correct state. Even worse, we don't even clear all the staged connector->encoder->crtc links so we may end up using a cloned setup for the load detection, and after we're done we just clear the links related to the VGA output leaving the links for the other outputs in place. This will eventually result in calling intel_set_mode() with mode==NULL but with valid connector->encoder->crtc links which will result in dereferencing the NULL mode since the code thinks it will have to a modeset. To avoid these problems don't use any crtc with new_enabled==true for load detection. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: [email protected] (for 3.16) Signed-off-by: Jani Nikula <[email protected]>
2014-08-18drm/i915: Fix locking for intel_enable_pipe_a()Ville Syrjälä4-21/+17
intel_enable_pipe_a() gets called with all the modeset locks already held (by drm_modeset_lock_all()), so trying to grab the same locks using another drm_modeset_acquire_ctx is going to fail miserably. Move most of the drm_modeset_acquire_ctx handling (init/drop/fini) out from intel_{get,release}_load_detect_pipe() into the callers (intel_{crt,tv}_detect()). Only the actual locking and backoff handling is left in intel_get_load_detect_pipe(). And in intel_enable_pipe_a() we just share the mode_config.acquire_ctx from drm_modeset_lock_all() which is already holding all the relevant locks. It's perfectly legal to lock the same ww_mutex multiple times using the same ww_acquire_ctx. drm_modeset_lock() will convert the returned -EALREADY into 0, so the caller doesn't need to do antyhing special. Fixes a hang on resume on my 830. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]>
2014-08-08Revert "drm/i915: Enable PSR by default."Linus Torvalds1-2/+2
This reverts commit b6d547791fd3ef4ccc89ad2556ab01045640aef7. The panel self refresh clearly isn't stable yet, and causes my laptop (Haswell ULT in a Sony Vaio Pro) to have the screen lock up. Maybe it doesn't ever get out of self-refresh, or maybe there are gremlins in the machine that get unhappy. Regardless, it's broken, and it gets reverted. Cc: Rodrigo Vivi <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-08-08Merge tag 'drm-intel-fixes-2014-08-08' of ↵Linus Torvalds19-102/+310
git://anongit.freedesktop.org/drm-intel Pull intel drm fixes from Daniel Vetter: "So I heard that proper pull requests have a revert on top ;-) So here we go with my usual mid-merge-window pile of fixes. [ Ed. This revert thing had better not become the "in" thing ] Big fix is the duct-tape for ring init on g4x platforms, we seem to have found the magic again to make those machines as happy as before (not perfect though unfortunately, but that was never the case). Otherwise fixes all over: - tune down some overzealous debug output - VDD power sequencing fix after resume - bunch of dsi fixes for baytrail among them hw state checker de-noising - bunch of error state capture fixes for bdw - misc tiny fixes/workarounds for various platforms Last minute rebase was to kick out two patches that shouldn't have been in here - they're for the state checker, so 0 functional code affected. Jani's back from vacation, so he'll take over -fixes from here" * tag 'drm-intel-fixes-2014-08-08' of git://anongit.freedesktop.org/drm-intel: (21 commits) Revert "drm/i915: Enable semaphores on BDW" drm/i915: read HEAD register back in init_ring_common() to enforce ordering drm/i915: Fix crash when failing to parse MIPI VBT drm/i915: Bring GPU Freq to min while suspending. drm/i915: Fix DEIER and GTIER collecting for BDW. drm/i915: Don't accumulate hangcheck score on forward progress drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround. drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper. drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL values drm/i915: Fix drain latency precision multipler for VLV drm/i915: Collect gtier properly on HSW. drm/i915: Tune down MCH_SSKPD values warning drm/i915: Tune done rc6 enabling output drm/i915: Don't require dev->struct_mutex in psr_match_conditions drm/i915: Fix error state collecting drm/i915: fix VDD state tracking after system resume drm/i915: Add correct hw/sw config check for DSI encoder drm/i915: factor out intel_edp_panel_vdd_sanitize drm/i915: wait for all DSI FIFOs to be empty drm/i915: work around warning in i915_gem_gtt ...
2014-08-08Revert "drm/i915: Enable semaphores on BDW"Rodrigo Vivi1-0/+4
This reverts commit 521e62e49a42661a4ee0102644517dbe2f100a23. Although POST_SYNC brought a bit of stability to Semaphores on BDW it didn't solved all issues and some hungs can still occour when semaphores are enabled on BDW. Also some sloweness can be found on some igt tests, althoguth it apparently doesn't affect real workloads. Besides that, no real performance gain was found on our tests with different and even multiple workloads. Let's disable it again for now. At least until we are sure it is safe to re-enable it. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-08drm/i915: read HEAD register back in init_ring_common() to enforce orderingJiri Kosina1-0/+3
Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000 This is not a complete fix, but it is verified to make the ring initialization failures during resume much less likely. We were not able to root-cause this bug (likely HW-specific to Gen4 chips) yet. This is therefore used as a ducttape before problem is fully understood and proper fix created, so that people don't suffer from completely unusable systems in the meantime. The discussion and debugging is happening at https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Jiri Kosina <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2014-08-08drm/i915: Fix crash when failing to parse MIPI VBTRafael Barbalho1-1/+1
This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also disable the panel using the generic mipi panel functions in dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would cause a crash within those functions. However, all of this is happening while console_lock is held from do_register_framebuffer inside fbcon.c. Which means that you got kernel log and just the device appearing to reboot/hang for no apparent reason. The fault started from the FB_EVENT_FB_REGISTERED event using the fb_notifier_call_chain call in fbcon.c. This regression has been introduced in commit d3b542fcfc72d7724585e3fd2c5e75351bc3df47 Author: Shobhit Kumar <[email protected]> Date: Mon Apr 14 11:00:34 2014 +0530 drm/i915: Add parsing support for new MIPI blocks in VBT Cc: Shobhit Kumar <[email protected]> Signed-off-by: Rafael Barbalho <[email protected]> Reviewed-by: Shobhit Kumar <[email protected]> [danvet: Add regression citation.] Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds48-2423/+6157
Pull DRM updates from Dave Airlie: "Like all good pull reqs this ends with a revert, so it must mean we tested it, [ Ed. That's _one_ way of looking at it ] This pull is missing nouveau, Ben has been stuck trying to track down a very longstanding bug that revealed itself due to some other changes. I've asked him to send you a direct pull request for nouveau once he cleans things up. I'm away until Monday so don't want to delay things, you can make a decision on that when he sends it, I have my phone so I can ack things just not really merge much. It has one trivial conflict with your tree in armada_drv.c, and also the pull request contains some component changes that are already in your tree, the base tree from Russell went via Greg's tree already, but some stuff still shows up in here that doesn't when I merge my tree into yours. Otherwise all pretty standard graphics fare, one new driver and changes all over the place. New drivers: - sti kms driver for STMicroelectronics chipsets stih416 and stih407. core: - lots of cleanups to the drm core - DP MST helper code merged - universal cursor planes. - render nodes enabled by default panel: - better panel interfaces - new panel support - non-continuous cock advertising ability ttm: - shrinker fixes i915: - hopefully ditched UMS support - runtime pm fixes - psr tracking and locking - now enabled by default - userptr fixes - backlight brightness fixes - MST support merged - runtime PM for dpms - primary planes locking fixes - gen8 hw semaphore support - fbc fixes - runtime PM on SOix sleep state hw. - mmio base page flipping - lots of vlv/chv fixes. - universal cursor planes radeon: - Hawaii fixes - display scalar support for non-fixed mode displays - new firmware format support - dpm on more asics by default - GPUVM improvements - uncached and wc GTT buffers - BOs > visible VRAM exynos: - i80 interface support - module auto-loading - ipp driver consolidated. armada: - irq handling in crtc layer only - crtc renumbering - add component support - DT interaction changes. tegra: - load as module fixes - eDP bpp and sync polarity fixed - DSI non-continuous clock mode support - better support for importing buffers from nouveau msm: - mdp5/adq8084 v1.3 hw enablement - devicetree clk changse - ifc6410 board working tda998x: - component support - DT documentation update vmwgfx: - fix compat shader namespace" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (551 commits) Revert "drm: drop redundant drm_file->is_master" drm/panel: simple: Use devm_gpiod_get_optional() drm/dsi: Replace upcasting macro by function drm/panel: ld9040: Replace upcasting macro by function drm/exynos: dp: Modify driver to support drm_panel drm/exynos: Move DP setup into commit() drm/panel: simple: Add AUO B133HTN01 panel support drm/panel: simple: Support delays in panel functions drm/panel: simple: Add proper definition for prepare and unprepare drm/panel: s6e8aa0: Add proper definition for prepare and unprepare drm/panel: ld9040: Add proper definition for prepare and unprepare drm/tegra: Add support for panel prepare and unprepare routines drm/exynos: dsi: Add support for panel prepare and unprepare routines drm/exynos: dpi: Add support for panel prepare and unprepare routines drm/panel: simple: Add dummy prepare and unprepare routines drm/panel: s6e8aa0: Add dummy prepare and unprepare routines drm/panel: ld9040: Add dummy prepare and unprepare routines drm/panel: Provide convenience wrapper for .get_modes() drm/panel: add .prepare() and .unprepare() functions drm/panel: simple: Remove simple-panel compatible ...
2014-08-08Revert "drm: drop redundant drm_file->is_master"Dave Airlie1-2/+2
This reverts commit 48ba813701eb14b3008edefef4a0789b328e278c. Thanks to Chris: "drm_file->is_master is not synomous with having drm_file->master == drm_file->minor->master. This is because drm_file->master is the same for all drm_files of the same generation and so when there is a master, every drm_file believes itself to be the master. Confusion ensues and things go pear shaped when one file is closed and there is no master anymore." Conflicts: drivers/gpu/drm/drm_drv.c drivers/gpu/drm/drm_stub.c
2014-08-07drm/i915: Bring GPU Freq to min while suspending.Deepak S1-1/+1
We might be leaving the PGU Frequency (and thus vnn) high during the suspend. Flusing the delayed work queue should take care of this. Signed-off-by: Deepak S <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Fix DEIER and GTIER collecting for BDW.Rodrigo Vivi2-6/+15
BDW has many other Display Engine interrupts and GT interrupts registers. Collecting it properly on gpu_error_state. On debugfs all was properly listed already but besides we were also listing old DEIER and GTIER that doesn't exist on BDW anymore. This was causing unclaimed register messages v2: Fix small issues of first version and don't read DEIER regs when pipe's power well is disabled v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection v4: Ben notice previous version was checking for display_power_enabled without using propper locks. Using _unlocked version isn't reliable and we cannot get this registers when power well is off. So let's avoid getting all DE_IER per pipe for now. If someone think this is an useful information it can be added later. v5: Ben: put back debugfs stuff that might be coverred by pm_get and use gen >= 8 trying to predict future. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81701 Cc: Ben Widawsky <[email protected]> Cc: Paulo Zanoni <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Reviewed-by: (v3) Paulo Zanoni <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Don't accumulate hangcheck score on forward progressMika Kuoppala3-3/+16
If the actual head has progressed forward inside a batch (request), don't accumulate hangcheck score. As the hangcheck score in increased only by acthd jumping backwards, the result is that we only declare an active batch as stuck if it is trapped inside a loop. Or that the looping will dominate the batch progression so that it overcomes the bonus that forward progress gives. v2: Improved commit message (Chris Wilson) Signed-off-by: Mika Kuoppala <[email protected]> [danvet: s/active_loop/active (loop)/ as requested by Chris.] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.Kenneth Graunke1-0/+9
On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set must be preceded by a PIPE_CONTROL with the "CS Stall" bit set. Documented on the BSpec 3D workarounds page. Reviewed-by: Rafael Barbalho <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> [vsyrjala: add chv w/a note too] Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.Kenneth Graunke1-15/+22
We'll want to reuse this for a workaround. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> [danvet: Rmove now unused int.] Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL valuesVille Syrjälä1-5/+4
The DDL registers can hold 7bit numbers. Make the most of those seven bits by adjusting the threshold where we switch between the 64 vs. 32 precision multipliers. Also we compute 'entries' to make the decision about precision, and then we recompute the same value to calculate the actual drain latency. Just use the already calculate 'entries' there. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Fix drain latency precision multipler for VLVZhenyu Wang2-31/+31
Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Collect gtier properly on HSW.Rodrigo Vivi2-10/+12
GTIER and DEIER doesn't have same interface on HSW so this "or" operation makes the information provided useless. v2: since we have gtier variable already let's split for everybody and avoid the strange | op. Also avoid overriding the value that was set for vlv. In this case I believe that we should reorganize the whole function, but I'll respect the comment that ask to not touch the order and let this organization work to be done later. v3: moving VLV check to the right place. Cc: Paulo Zanoni <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Tune down MCH_SSKPD values warningDaniel Vetter1-5/+3
Users often can't do anything about this since their vendors stopped providing BIOS updates. Also we seem to be able to hack around it with increased latency values, and thus far the only reports have been for screens with really high resolutions. So tune it down to a level where only developers can see it. Also drop some of the end-user fluff. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Tune done rc6 enabling outputDaniel Vetter1-6/+6
Power users spot this and then get adventurous and try to adjust module driver options. Nothing good ever came out of that, so hide it better. Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Don't require dev->struct_mutex in psr_match_conditionsDaniel Vetter1-1/+0
Since I've reworked psr support to no longer require x-tiling we don't check any state protected by the Giant GEM Lock. So drop that check. Also boo for lockdep_assert_held for not yelling when lockdep is disabled. Cc: Paulo Zanoni <[email protected]> Reported-by: Paulo Zanoni <[email protected]> Acked-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Fix error state collectingRodrigo Vivi1-1/+2
Fix signal_offset when recording semaphore state on BDW. Reviewed-by: Ben Widawsky <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: fix VDD state tracking after system resumeImre Deak1-0/+6
Just like during booting the BIOS can leave the VDD bit enabled after system resume. So apply the same state sanitization there too. This fixes a problem where after resume the port power domain refcount gets unbalanced. v2: - unchanged v3: - call edp sanitizing from the encoder reset handler (Daniel) Reported-and-tested-by: Jarkko Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: Add correct hw/sw config check for DSI encoderShobhit Kumar4-1/+106
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read. It will not be enabled for DSI and avoid dpio read WARN dumps. Absence of ->get_config was causing other WARN dumps as well. Update dpll_hw_state as well correctly v2: Address review comments by Daniel - Check if DPLL is enabled rather than checking pipe output type - set adjusted_mode->flags to 0 in compute_config rather than using pipe_config->quirks - Add helper function in intel_dsi_pll.c and use that in intel_dsi.c - updated dpll_hw_state correctly - Updated commit message and title v3: Address review comments by Imre - Proper masking of P1, M1 fields while computing divisors - assert in case of bpp mismatch - guard for divide by 0 while computing pclk - Use ARRAY_SIZE instead of direct calculation Signed-off-by: Shobhit Kumar <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: factor out intel_edp_panel_vdd_sanitizeImre Deak2-17/+44
This will be needed by an upcoming patch too that needs to sanitize the VDD state during resume. The additional async disabling is only needed for the resume path, here it doesn't make a difference since we enable VDD right after the sanitize call. v2: - don't set intel_dp ptr for non-eDP encoders (Ville) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: wait for all DSI FIFOs to be emptyShobhit Kumar3-0/+25
Ensure that the DSI packets for a particular sequence are completely sent before going ahead in the enabling or disabling of the panel Signed-off-by: Shobhit Kumar <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-08-07drm/i915: work around warning in i915_gem_gttPavel Machek1-5/+6
Gcc warns that addr might be used uninitialized. It may not, but I see why gcc gets confused. Additionally, hiding code with side-effects inside WARN_ON() argument seems uncool, so I moved it outside. Signed-off-by: Pavel Machek <[email protected]> [danvet: Add obligatory /* shuts up gcc */ comment.] Signed-off-by: Daniel Vetter <[email protected]>
2014-08-06Merge branch 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux into ↵Dave Airlie1-2/+2
drm-next bunch of cleanups * 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux: drm: mark drm_context support as legacy drm: make sysfs device always available for minors drm: make minor->index available early drm: merge drm_drv.c into drm_ioctl.c drm: move module initialization to drm_stub.c drm: don't de-authenticate clients on master-close drm: drop redundant drm_file->is_master drm: extract legacy ctxbitmap flushing
2014-08-05Merge branch 'timers-core-for-linus' of ↵Linus Torvalds3-29/+18
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer and time updates from Thomas Gleixner: "A rather large update of timers, timekeeping & co - Core timekeeping code is year-2038 safe now for 32bit machines. Now we just need to fix all in kernel users and the gazillion of user space interfaces which rely on timespec/timeval :) - Better cache layout for the timekeeping internal data structures. - Proper nanosecond based interfaces for in kernel users. - Tree wide cleanup of code which wants nanoseconds but does hoops and loops to convert back and forth from timespecs. Some of it definitely belongs into the ugly code museum. - Consolidation of the timekeeping interface zoo. - A fast NMI safe accessor to clock monotonic for tracing. This is a long standing request to support correlated user/kernel space traces. With proper NTP frequency correction it's also suitable for correlation of traces accross separate machines. - Checkpoint/restart support for timerfd. - A few NOHZ[_FULL] improvements in the [hr]timer code. - Code move from kernel to kernel/time of all time* related code. - New clocksource/event drivers from the ARM universe. I'm really impressed that despite an architected timer in the newer chips SoC manufacturers insist on inventing new and differently broken SoC specific timers. [ Ed. "Impressed"? I don't think that word means what you think it means ] - Another round of code move from arch to drivers. Looks like most of the legacy mess in ARM regarding timers is sorted out except for a few obnoxious strongholds. - The usual updates and fixlets all over the place" * 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits) timekeeping: Fixup typo in update_vsyscall_old definition clocksource: document some basic timekeeping concepts timekeeping: Use cached ntp_tick_length when accumulating error timekeeping: Rework frequency adjustments to work better w/ nohz timekeeping: Minor fixup for timespec64->timespec assignment ftrace: Provide trace clocks monotonic timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC seqcount: Add raw_write_seqcount_latch() seqcount: Provide raw_read_seqcount() timekeeping: Use tk_read_base as argument for timekeeping_get_ns() timekeeping: Create struct tk_read_base and use it in struct timekeeper timekeeping: Restructure the timekeeper some more clocksource: Get rid of cycle_last clocksource: Move cycle_last validation to core code clocksource: Make delta calculation a function wireless: ath9k: Get rid of timespec conversions drm: vmwgfx: Use nsec based interfaces drm: i915: Use nsec based interfaces timekeeping: Provide ktime_get_raw() hangcheck-timer: Use ktime_get_ns() ...
2014-08-06drm/i915: lock around link status and link training.Dave Airlie1-1/+5
We need to take the connection mutex around the link status check for non-MST case, but also around the MST link training on short HPDs. I suspect we actually should have a dpcd lock in the future as well, that just lock the local copies of dpcd and flags stored from that. Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-08-05drm: drop redundant drm_file->is_masterDavid Herrmann1-2/+2
The drm_file->is_master field is redundant as it's equivalent to: drm_file->master && drm_file->master == drm_file->minor->master 1) "=>" Whenever we set drm_file->is_master, we also set: drm_file->minor->master = drm_file->master; Whenever we clear drm_file->is_master, we also call: drm_master_put(&drm_file->minor->master); which implicitly clears it to NULL. 2) "<=" minor->master cannot be set if it is non-NULL. Therefore, it stays as is unless a file drops it. If minor->master is NULL, it is only set by places that also adjust drm_file->is_master. Therefore, we can safely drop is_master and replace it by an inline helper that matches: drm_file->master && drm_file->master == drm_file->minor->master Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: David Herrmann <[email protected]>
2014-08-05drm/i915: Update DRIVER_DATE to 20140725Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <[email protected]>
2014-08-04Merge tag 'driver-core-3.17-rc1' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here's the big driver-core pull request for 3.17-rc1. Largest thing in here is the dma-buf rework and fence code, that touched many different subsystems so it was agreed it should go through this tree to handle merge issues. There's also some firmware loading updates, as well as tests added, and a few other tiny changes, the changelog has the details. All have been in linux-next for a long time" * tag 'driver-core-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits) ARM: imx: Remove references to platform_bus in mxc code firmware loader: Fix _request_firmware_load() return val for fw load abort platform: Remove most references to platform_bus device test: add firmware_class loader test doc: fix minor typos in firmware_class README staging: android: Cleanup style issues Documentation: devres: Sort managed interfaces Documentation: devres: Add devm_kmalloc() et al fs: debugfs: remove trailing whitespace kernfs: kernel-doc warning fix debugfs: Fix corrupted loop in debugfs_remove_recursive stable_kernel_rules: Add pointer to netdev-FAQ for network patches driver core: platform: add device binding path 'driver_override' driver core/platform: remove unused implicit padding in platform_object firmware loader: inform direct failure when udev loader is disabled firmware: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN firmware: read firmware size using i_size_read() firmware loader: allow disabling of udev as firmware loader reservation: add suppport for read-only access using rcu reservation: update api and add some helpers ... Conflicts: drivers/base/platform.c