kernel.git/drivers/gpu/drm/i915, branch linux-3.13.y

drm/i915: Undo gtt scratch pte unmapping again

2014-04-03T19:02:36Z

commit 8ee661b505613ef2747b350ca2871a31b3781bee upstream. It apparently blows up on some machines. This functionally reverts commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841 Reported-and-Tested-by: Brad Jackson Cc: Takashi Iwai Cc: Paulo Zanoni Cc: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Disable stolen memory when DMAR is active

2014-03-31T17:05:13Z

commit 0f4706d2740f2a221cd502922b22e522009041d9 upstream. We have reports of heavy screen corruption if we try to use the stolen memory reserved by the BIOS whilst the DMA-Remapper is active. This quirk may be only specific to a few machines or BIOSes, but first lets apply the big hammer and always disable use of stolen memory when DMAR is active. v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't enable display error interrupts from the start

2014-03-31T17:05:13Z

commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b upstream. We need to enable interrupt processing before all the modeset state is set up. But that means we can fall over when we get a pipe underrun. This shouldn't happen as long as the bios works correctly but as usual this turns out to be wishful thinking. So disable error interrupts at irq install time and rely on the re-enabling code in the modeset functions to take care of this. Note that due to the SDE interrupt handling race we must uncondtionally enable all interrupt sources in SDEIER, hence no need to enable the SERR bit specifically. On gmch platforms we don't have an explicit enable/mask bit for fifo underruns. Fixing this up would require a bit of software tracking, hence is material for a separate patch. To make this possible we need to switch all gmch platforms to the new pipestat interrupt handling scheme Imre implemented for vlv, and then also add a safe form of sw state checking to __cpu_fifo_underrun_reporting_enabled a bit. v2: Also handle the ilk/snb cpu fifo underrun bits accordingly. Spotted by Ville. v3: Also handle the south interrupt underrun bits on ibx. Again spotted by Ville. Reported-by: Rob Clark Cc: Rob Clark Cc: Ville Syrjälä Tested-by: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix PSR programming

2014-03-31T17:05:13Z

commit 24bd9bf54d45d28089251cdf62bf14323d1aa827 upstream. | has a higher precedence than ?. Therefore, the calculation doesn't do at all what you would expect. Thanks to Ken for convincing me that this was indeed the issue. Send me back to C programmer school, please. I'm sort of surprised PSR was continuing to work for people. It should be broken IMO (and it was broken for me, but I had assumed it never worked). Regression from: commit ed8546ac1f99b850879f07b1e9b06b42fb0a36d9 Author: Ben Widawsky Date: Mon Nov 4 22:45:05 2013 -0800 drm/i915/bdw: Support eDP PSR Cc: Rodrigo Vivi Cc: Kenneth Graunke Cc: Art Runyan Reported-by: "Kumar, Kiran S" Signed-off-by: Ben Widawsky Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: Reject >165MHz modes w/ DVI monitors

2014-03-24T04:44:14Z

commit 6375b768a9850b6154478993e5fb566fa4614a9c upstream. Single-link DVI max dotclock is 165MHz. Filter out modes with higher dotclock when the monitor doesn't support HDMI. Modes higher than 165 MHz were allowed in commit 7d148ef51a657fd04036c3ed7803da600dd0d451 Author: Daniel Vetter Date: Mon Jul 22 18:02:39 2013 +0200 drm/i915: fix hdmi portclock limits Also don't attempt to use 12bpc mode with DVI monitors. Cc: Adam Nielsen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331 Tested-by: Ralf Jung Signed-off-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915: fix pch pci device enumeration

2014-03-24T04:44:14Z

commit bcdb72ac7c00d2b56359fc82bcc8fe50454717d5 upstream. pci_get_class(class, from) drops the refcount for 'from', so the extra pci_dev_put we do on it will result in a use after free bug starting with the WARN below. Regression introduced in commit 6a9c4b35e6696a63805b6da5e4889c6986e9ee1b Author: Rui Guo Date: Wed Jun 19 21:10:23 2013 +0800 drm/i915: Fix PCH detect with multiple ISA bridges in VM [ 164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110() [ 164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G O 3.13.0-imre+ #354 [ 164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013 [ 164.368796] Call Trace: [ 164.371609] [] dump_stack+0x4e/0x7a [ 164.377447] [] warn_slowpath_common+0x7d/0xa0 [ 164.384238] [] warn_slowpath_null+0x1a/0x20 [ 164.390851] [] klist_next+0xae/0x110 [ 164.396777] [] ? pci_do_find_bus+0x70/0x70 [ 164.403286] [] bus_find_device+0x89/0xc0 [ 164.409719] [] pci_get_dev_by_id+0x63/0xa0 [ 164.416238] [] pci_get_class+0x44/0x50 [ 164.422433] [] intel_dsm_detect+0x16f/0x1f0 [i915] [ 164.429801] [] intel_register_dsm_handler+0xe/0x10 [i915] [ 164.437831] [] i915_driver_load+0xafe/0xf30 [i915] [ 164.445126] [] ? intel_alloc_coherent+0x110/0x110 [ 164.452340] [] drm_dev_register+0xc7/0x150 [drm] [ 164.459462] [] drm_get_pci_dev+0x11f/0x1f0 [drm] [ 164.466554] [] ? _raw_spin_unlock_irqrestore+0x51/0x70 [ 164.474287] [] i915_pci_probe+0x56/0x60 [i915] [ 164.481185] [] pci_device_probe+0x78/0xf0 [ 164.487603] [] driver_probe_device+0x155/0x350 [ 164.494505] [] __driver_attach+0x6e/0xa0 [ 164.500826] [] ? __device_attach+0x50/0x50 [ 164.507333] [] bus_for_each_dev+0x6e/0xc0 [ 164.513752] [] driver_attach+0x1e/0x20 [ 164.519870] [] bus_add_driver+0x138/0x260 [ 164.526289] [] ? 0xffffffffa0187fff [ 164.532116] [] driver_register+0x98/0xe0 [ 164.538558] [] ? 0xffffffffa0187fff [ 164.544389] [] __pci_register_driver+0x60/0x70 [ 164.551336] [] drm_pci_init+0x6d/0x120 [drm] [ 164.558040] [] ? 0xffffffffa0187fff [ 164.563928] [] i915_init+0x6a/0x6c [i915] [ 164.570363] [] do_one_initcall+0xaa/0x160 [ 164.576783] [] ? set_memory_nx+0x40/0x50 [ 164.583100] [] load_module+0x1fb5/0x2550 [ 164.589410] [] ? store_uevent+0x40/0x40 [ 164.595628] [] SyS_init_module+0xed/0x100 [ 164.602048] [] system_call_fastpath+0x16/0x1b v2: simplify the loop further (Chris) Signed-off-by: Imre Deak Cc: Jesse Barnes Reported-by: Jesse Barnes Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161 Reviewed-by: Chris Wilson Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: add native aux defer retry limit

2014-03-07T06:06:31Z

commit f51a44b9a6c4982cc25bfb3727de9bb893621ebc upstream. Retrying indefinitely places too much trust on the aux implementation of the sink devices. Reported-by: Daniel Martin Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267 Signed-off-by: Jani Nikula Tested-by: Theodore Ts'o Tested-by: Sree Harsha Totakura Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: increase native aux defer retry timeout

2014-03-07T06:06:31Z

commit 04eada25d1f72efdecd32d702706594f81de65d5 upstream. Give more slack to sink devices before retrying on native aux defer. AFAICT the 100 us timeout was not based on the DP spec. Signed-off-by: Jani Nikula Cc: stable@vger.kernel.org (on Jani's request) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB

2014-03-07T06:06:06Z

commit f66fab8e1cd6b3127ba4c5c0d11539fbe1de1e36 upstream. According to BSpec the entire MI_DISPLAY_FLIP packet must be contained in a single cacheline. Make sure that happens. v2: Use intel_ring_begin_cacheline_safe() v3: Use intel_ring_cacheline_align() (Chris) Cc: Bjoern C Cc: Alexandru DAMIAN Cc: Enrico Tagliavini Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053 Signed-off-by: Ville Syrjälä Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Add intel_ring_cachline_align()

2014-03-07T06:06:06Z

commit 753b1ad4a281b0663329409d410243e91825c323 upstream. intel_ring_cachline_align() emits MI_NOOPs until the ring tail is aligned to a cacheline boundary. Cc: Bjoern C Cc: Alexandru DAMIAN Cc: Enrico Tagliavini Suggested-by: Chris Wilson Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman