linux-stable.git/drivers/gpu, branch v3.7.6

drm/i915: fix FORCEWAKE posting reads

2013-02-04T00:27:08+00:00

commit b514407547890686572606c9dfa4b7f832db9958 upstream.

We stopped reading FORCEWAKE for posting reads in

commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky 
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

and started using something from the same cacheline instead. On the
bug reporter's machine this broke entering rc6 states after a
suspend/resume cycle. It turns out reading ECOBUS as posting read
worked fine, while GTFIFODBG did not, preventing RC6 states after
suspend/resume per the bug report referenced below. It's not entirely
clear why, but clearly GTFIFODBG was nowhere near the same cacheline
or address range as FORCEWAKE.

Trying out various registers for posting reads showed that all tested
registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
work. Conversely, most (but not quite all) registers for which
NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
bug.

Based on the above, add posting reads on ECOBUS where GTFIFODBG was
previously relied on.

In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
address range as FORCEWAKE_VLV.

v2: Add more details to the commit message. No functional changes.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
Reported-and-tested-by: Alexander Bersenev 
CC: Ben Widawsky 
Signed-off-by: Jani Nikula 
Reviewed-by: Chris Wilson 
Cc: stable@vger.kernel.org
[danvet: add cc: stable and make the commit message a bit clearer that
this is a regression fix and what exactly broke.]
Signed-off-by: Daniel Vetter 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix a rare case of double kfree

2013-02-04T00:27:06+00:00

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 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix error path in kpage allocation

2013-02-04T00:27:06+00:00

commit 25d8999780f8c1f53928f4a24a09c01550423109 upstream.

Index into chunks[] array doesn't look right.

Signed-off-by: Ilija Hadzic 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

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

2013-02-04T00:27:05+00:00

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.

Signed-off-by: Matt Fleming 
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: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

drm/i915: dump UTS_RELEASE into the error_state

2013-02-04T00:27:01+00:00

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 
Signed-off-by: Greg Kroah-Hartman

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

2013-02-04T00:27:01+00:00

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 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Disable AsyncFlip performance optimisations

2013-02-04T00:27:01+00:00

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 
Signed-off-by: Greg Kroah-Hartman

radeon_display: Use pointer return error codes

2013-02-04T00:27:01+00:00

commit b2f4b03f8a378cd626d2ea67d19e7470c050a098 upstream.

drm_mode_addfb() expects fb_create return error code
instead of NULL.

Signed-off-by: xueminsu 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix cursor corruption on DCE6 and newer

2013-02-04T00:27:01+00:00

commit e521a29014794d139cca46396d1af8faf1295a26 upstream.

Aruba and newer gpu does not need the avivo cursor work around,
quite the opposite this work around lead to corruption.

agd5f: check DCE6 rather than ARUBA since the issue is DCE
version specific rather than family specific.

Signed-off-by: Jerome Glisse 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

2013-01-28T04:49:02+00:00

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: Greg Kroah-Hartman