linux/drivers/gpu, branch v3.2.38

Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"

2013-02-06T04:33:54Z

commit 48e858340dae43189a4e55647f6eac736766f828 upstream. This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364. The bogus lvds output is actually a lvds->hdmi bridge, which we don't really support. But unconditionally disabling it breaks some existing setups. Reported-by: John Tapsell References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237 Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

2013-02-06T04:33:54Z

commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream. Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to "1", Project: DevSNB " Reviewed-by: Rodrigo Vivi Signed-off-by: Daniel Vetter Signed-off-by: Abdallah Chatila Signed-off-by: Ben Hutchings

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-06T04:33:50Z

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream. Originally 'efi_enabled' indicated whether a kernel was booted from EFI firmware. Over time its semantics have changed, and it now indicates whether or not we are booted on an EFI machine with bit-native firmware, e.g. 64-bit kernel with 64-bit firmware. The immediate motivation for this patch is the bug report at, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 which details how running a platform driver on an EFI machine that is designed to run under BIOS can cause the machine to become bricked. Also, the following report, https://bugzilla.kernel.org/show_bug.cgi?id=47121 details how running said driver can also cause Machine Check Exceptions. Drivers need a new means of detecting whether they're running on an EFI machine, as sadly the expression, if (!efi_enabled) hasn't been a sufficient condition for quite some time. Users actually want to query 'efi_enabled' for different reasons - what they really want access to is the list of available EFI facilities. For instance, the x86 reboot code needs to know whether it can invoke the ResetSystem() function provided by the EFI runtime services, while the ACPI OSL code wants to know whether the EFI config tables were mapped successfully. There are also checks in some of the platform driver code to simply see if they're running on an EFI machine (which would make it a bad idea to do BIOS-y things). This patch is a prereq for the samsung-laptop fix patch. Cc: David Airlie Cc: Corentin Chary Cc: Matthew Garrett Cc: Dave Jiang Cc: Olof Johansson Cc: Peter Jones Cc: Colin Ian King Cc: Steve Langasek Cc: Tony Luck Cc: Konrad Rzeszutek Wilk Cc: Rafael J. Wysocki Signed-off-by: Matt Fleming Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: - Adjust context (a lot) - Add efi_is_native() function from commit 5189c2a7c776 ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel') - Make efi_init() bail out when booted non-native, as it would previously not be called in this case - Drop inapplicable changes to start_kernel()] Signed-off-by: Ben Hutchings

drm/radeon: fix a rare case of double kfree

2013-02-06T04:33:47Z

commit 1da80cfa8727abf404fcee44d04743febea54069 upstream. If one (but not both) allocations of p->chunks[].kpage[] in radeon_cs_parser_init fail, the error path will free the successfully allocated page, but leave a stale pointer value in the kpage[] field. This will later cause a double-free when radeon_cs_parser_fini is called. This patch fixes the issue by forcing both pointers to NULL after kfree in the error path. The circumstances under which the problem happens are very rare. The card must be AGP and the system must run out of kmalloc area just at the right time so that one allocation succeeds, while the other fails. Signed-off-by: Ilija Hadzic Cc: Herton Ronaldo Krzesinski Signed-off-by: Alex Deucher [bwh: Backported to 3.2: s/p->chunk_ib_idx/i/] Signed-off-by: Ben Hutchings

drm/i915: dump UTS_RELEASE into the error_state

2013-02-06T04:33:46Z

commit 4518f611ba21ba165ea3714055938a8984a44ff9 upstream. Useful for statistics or on overflowing bug reports to keep things all lined up. Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits

2013-02-06T04:33:46Z

commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream. On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1, the hardware can not program the scanline values. Those scanline values then control when the signal is sent from the display engine to the render ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB invalidations must be performed explicitly through the appropriate bits being set in PIPE_CONTROL. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: s/_MASKED_BIT/GFX_MODE/] Signed-off-by: Ben Hutchings

drm/i915: Disable AsyncFlip performance optimisations

2013-02-06T04:33:45Z

commit 1c8c38c588ea91f8deeae21284840459d1bb58e3 upstream. This is a required workarounds for all products, especially on gen6+ where it causes the command streamer to fail to parse instructions following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising between the GPU and the display engines, and so this bit being unset may cause hangs. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: - Adjust context - s/_MASKED_BIT/GFX_MODE/] Signed-off-by: Ben Hutchings

drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.

2013-02-06T04:33:45Z

commit fc74d8e01165b567922921d110b6d16320a61fa6 upstream. Older specs claimed this was bit 11, but newer specs and the actual simulator code say it was bit 12. Regardless, we don't use MI_FLUSH, or try to enable it any more. Signed-off-by: Eric Anholt Reviewed-by: Kenneth Graunke Reviewed-by: Ben Widawsky [danvet: Anyone trying to use this bit, please read all the relevant discussions, it's epic.] Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Remove the MI_FLUSH_ENABLE setting.

2013-02-06T04:33:45Z

commit 8d79c3490aecfe6e51f0ba6f9780746fb1434954 upstream. We have always been using the wrong bit -- it's bit 12. However, the bit also doesn't do anything -- hardware has always accepted the MI_FLUSH command even when it was specced not to. Given that there is only one MI_FLUSH emitted in all of the driver stack on gen6+ (in i965_video.c of the 2d driver, and it should be using other code to do its flush instead), just remove the MI_FLUSH enable instead of trying to fix it. Signed-off-by: Eric Anholt Reviewed-by: Kenneth Graunke Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Invalidate the relocation presumed_offsets along the slow path

2013-02-06T04:33:35Z

commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream. In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings