linux-toradex.git/drivers/gpu/drm, branch v3.2.46

drm/radeon: check incoming cliprects pointer

2013-05-30T13:34:57+00:00

commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream.

The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.

Signed-off-by: Kees Cook 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

Revert "drm/i915: Fix detection of base of stolen memory"

2013-05-30T13:34:48+00:00

This reverts commit 53e587aa5ca81497d0ea6e340320ec5778d1f311.
Yves-Alexis Perez reported that it broke the driver on two machines
with GMA4500 and i965 chips.  Only the backported version in 3.2.45
had this effect; the fix in mainline is fine.

Daniel Vetter stated that the fix is not needed in 3.2 anyway.

Reported-by: Yves-Alexis Perez 
Signed-off-by: Ben Hutchings

drm/i915: Fix detection of base of stolen memory

2013-05-13T14:02:43+00:00

commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream.

The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.

It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.

Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.

Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

drm/radeon: fix handling of v6 power tables

2013-05-13T14:02:31+00:00

commit 441e76ca83ac604eaf0f046def96d8e3a27eea28 upstream.

The code was mis-handling variable sized arrays.

Reported-by: Sylvain BERTRAND 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: fix possible segfault when parsing pm tables

2013-05-13T14:02:30+00:00

commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream.

If we have a empty power table, bail early and allocate
the default power state.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=63865

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

2013-05-13T14:02:30+00:00

commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream.

Reviwed-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: fix hdmi mode enable on RS600/RS690/RS740

2013-05-13T14:02:23+00:00

commit dcb852905772416e322536ced5cb3c796d176af5 upstream.

These chips were previously skipped since they are
pre-R600.

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: Fall back to bit banging mode for DVO transmitter detection

2013-05-13T14:02:22+00:00

commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream.

As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.

The attached patch fixes this by falling back to bit banging mode for
the time DVO transmitter detection is in progress.

Signed-off-by: David Müller 
Tested-by: David Müller 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: ensure single initialization and cleanup of backlight device

2013-05-13T14:02:21+00:00

commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.

Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula 
Tested-by: Peter Verthez 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2:
 - Adjust context
 - s/dev_priv->backlight\.device/dev_priv->backlight/]
Signed-off-by: Ben Hutchings

drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

2013-05-13T14:02:21+00:00

commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream.

In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
manually flush writes to memory prior to writing the fence register in
conjunction with the memory barriers placed around the register write.

Fixes i-g-t/gem_fence_thrash

v2: Bring a bigger gun
v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
v4: Remove changes for working generations.
v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
v6: Rewrite comments to ellide forgotten history.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191
Signed-off-by: Chris Wilson 
Cc: Jon Bloomfield 
Tested-by: Jon Bloomfield  (v2)
Reviewed-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2: insert the cache flush in i915_gem_object_get_fence()]
Signed-off-by: Ben Hutchings