kernel/linux.git/drivers/gpu/drm/i915, branch v3.13.3

drm/i915: Decouple GPU error reporting from ring initialisation

2014-02-13T21:55:42+00:00

commit 372fbb8e3927fc76b0f842d8eb8a798a71d8960f upstream. Currently we report through our error state only the rings that have been initialised (as detected by ring->obj). This check is done after the GPU reset and ring re-initialisation, which means that the software state may not be the same as when we captured the hardware error and we may not print out any of the vital information for debugging the hang. This (and the implied object leak) is a regression from commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05 Author: Ben Widawsky Date: Mon Oct 14 10:01:36 2013 -0700 drm/i915: Do a fuller init after reset Note that we are already starting to get bug reports with incomplete error states from 3.13, which also hampers debugging userspace driver issues. v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where the scratch obj may be NULL. Signed-off-by: Chris Wilson Cc: Ben Widawsky Cc: Ville Syrjälä References: https://bugs.freedesktop.org/show_bug.cgi?id=74094 Reviewed-by: Ville Syrjälä [danvet: Add a bit of fluff to make it clear we need this expedited in stable.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

i915: remove pm_qos request on error

2014-02-13T21:55:42+00:00

commit 22accca01713b13dac386ca90b787aadf88f6551 upstream. Not removing pm qos request and free memory for it can cause crash, when some other driver use pm qos. For example, this oops: BUG: unable to handle kernel paging request at fffffffffffffff8 IP: [] plist_add+0x5b/0xd0 Call Trace: [] pm_qos_update_target+0x125/0x1e0 [] pm_qos_add_request+0x91/0x100 [] e1000_open+0xe4/0x5b0 [e1000e] was caused by earlier i915 probe failure: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000 [drm:i915_driver_load] *ERROR* failed to init modeset i915: probe of 0000:00:02.0 failed with error -5 Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1057533 Reported-by: Giandomenico De Tullio Signed-off-by: Stanislaw Gruszka [danvet: Drop unnecessary code movement.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: VLV2 - Fix hotplug detect bits

2014-02-13T21:55:42+00:00

commit 232a6ee9af8adb185640f67fcaaa9014a9aa0573 upstream. Add new definitions for hotplug live status bits for VLV2 since they're in reverse order from the gen4x ones. Changelog: - Restored gen4 bit definitions - Added new definitions for VLV2 - Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct bit defintions - Replaced a lost trailing brace for the added switch() Signed-off-by: Todd Previte Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951 [danvet: Switch to _VLV postfix instead of prefix and regroupg comments again so that the g4x warning is right next to those defines. Also add a _G4X suffix for those special ones. Also cc stable.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix the offset issue for the stolen GEM objects

2014-02-13T21:55:42+00:00

commit ec14ba47791965d2c08e0a681ff44eacbf3c4553 upstream. The 'offset' field of the 'scatterlist' structure was wrongly programmed with the offset value from the base of stolen area, whereas this field indicates the offset from where the interested data starts within the first PAGE pointed to by 'scattterlist' structure. As a result when a new GEM object allocated from stolen area is mapped to GTT, it could lead to an overwrite of GTT entries as the page count calculation will go wrong, refer the function 'sg_page_count'. v2: Modified the commit message. (Chris) Signed-off-by: Akash Goel Reviewed-by: Jesse Barnes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71908 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69104 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Flush outstanding requests before allocating new seqno

2014-02-13T21:55:41+00:00

commit 304d695c3dc8eb65206b9eaf16f8d1a41510d1cf upstream. In very rare cases (such as a memory failure stress test) it is possible to fill the entire ring without emitting a request. Under this circumstance, the outstanding request is flushed and waited upon. After space on the ring is cleared, we return to emitting the new command - except that we just cleared the seqno allocated for this operation and trigger the sanity check that a request is only ever emitted with a valid seqno. The fix is to rearrange the code to make sure the allocation of the seqno for this operation is after any required flushes of outstanding operations. The bug exists since the preallocation was introduced in commit 9d7730914f4cd496e356acfab95b41075aa8eae8 Author: Chris Wilson Date: Tue Nov 27 16:22:52 2012 +0000 drm/i915: Preallocate next seqno before touching the ring Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Daniel Vetter Signed-off-by: Chris Wilson Reviewed-by: Jani Nikula Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915/bdw: make sure south port interrupts are enabled properly v2

2014-01-10T21:35:15+00:00

We were apparently relying on the defaults on BDW, which resulted in no hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to enable all interrupts. v2: use preinstall instead of redundant SDIER write References: https://bugs.freedesktop.org/show_bug.cgi?id=72834 References: https://bugs.freedesktop.org/show_bug.cgi?id=72833 Signed-off-by: Jesse Barnes Signed-off-by: Daniel Vetter

drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()

2014-01-10T07:46:19+00:00

When the pipe A force quirk is applied the code will attempt to grab a crtc mutex during intel_modeset_setup_hw_state(). If we're already holding all crtc mutexes this will obviously deadlock every time. So instead of using drm_modeset_lock_all() just grab the mode_config.mutex. This is enough to avoid the unlocked mutex warnings from certain lower level functions. The regression was introduced in: commit 027476642811f8559cbe00ef6cc54db230e48a20 Author: Ville Syrjälä Date: Mon Dec 2 11:08:06 2013 +0200 drm/i915: Take modeset locks around intel_modeset_setup_hw_state() Signed-off-by: Ville Syrjälä Cc: stable@vger.kernel.org [danvet: Add cc: stable since the offending commit has that, too.] Signed-off-by: Daniel Vetter

drm/i915: fix DDI PLLs HW state readout code

2014-01-08T14:54:09+00:00

Properly zero the refcounts and crtc->ddi_pll_set so the previous HW state doesn't affect the result of reading the current HW state. This fixes WARNs about WRPLL refcount if we have an HDMI monitor on HSW and then suspend/resume. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379 Tested-by: Qingshuai Tian Signed-off-by: Paulo Zanoni Signed-off-by: Daniel Vetter

Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"

2014-01-06T10:16:39+00:00

My Acer 8510TZ stops displaying anything when X starts with Linus' current tree. I bisected it down to commit ee1452d74584. This patch reverts commit ee1452d74584. After the revert, everything works as before. Signed-off-by: Alexander van Heukelum Reported-by: Dylan Borg (for a Acer Extensa 5635Z) Signed-off-by: Jani Nikula Signed-off-by: Daniel Vetter

drm/i915/bdw: Flush system agent on gen8 also

2014-01-06T10:11:04+00:00

gem_gtt_cpu_tlb seems to indicate that it is needed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72869 Signed-off-by: Ben Widawsky Signed-off-by: Daniel Vetter