linux-toradex.git/drivers/gpu, branch v3.2.47

drm/i915: prefer VBT modes for SVDO-LVDS over EDID

2013-06-19T01:16:58+00:00

commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream.

In

commit 53d3b4d7778daf15900867336c85d3f8dd70600c
Author: Egbert Eich 
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC

Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SDVO-LVDS panels.
Unfortunately some machines seem to not be able to cope with the mode
provided in the EDID. Specifically they seem to not be able to cope
with a 4x pixel mutliplier instead of a 2x one, which seems to have
been worked around by slightly changing the panels native mode in the
VBT so that the dotclock is just barely above 50MHz.

Since it took forever to notice the breakage it's fairly safe to
assume that at least for SDVO-LVDS panels the VBT contains fairly sane
data. So just switch around the order and use VBT modes first.

v2: Also add EDID modes just in case, and spell Egbert correctly.

v3: Elaborate a bit more about what's going on on Chris' machine.

Cc: Egbert Eich 
Cc: Chris Wilson 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
Reported-and-tested-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.

2013-06-19T01:16:54+00:00

commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.

In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.

This regression seems to have been introduced in

commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson 
Date:   Tue Jul 20 15:44:45 2010 -0700

    drm/i915: use GMBUS to manage i2c links

Signed-off-by: Egbert Eich 
Reviewed-by: Chris Wilson 
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

radeon: Fix system hang issue when using KMS with older cards

2013-06-19T01:16:53+00:00

commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream.

The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.

A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
 * rv515_init (rv515.c)
 * radeon_irq_kms_init (radeon_irq_kms.c)
 * drm_irq_install (drm_irq.c)
 * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
 * rs600_irq_process (rs600.c)
 * radeon_fence_process - due to SW interrupt (radeon_fence.c)
 * radeon_fence_read (radeon_fence.c)
 * hang due to RREG32(-1)

The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.

This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.

Bug reports:
https://bugzilla.redhat.com/show_bug.cgi?id=845745
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789
https://bbs.archlinux.org/viewtopic.php?id=156964

Signed-off-by: Adis Hamzić 
Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes for Southern Islands]
Signed-off-by: Ben Hutchings

drm/i915: no lvds quirk for hp t5740

2013-06-19T01:16:53+00:00

commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream.

Last year, a patch was made for the "HP t5740e Thin Client" (see
http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
This device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.

Signed-off-by: Ben Mesman 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm: fix a use-after-free when GPU acceleration disabled

2013-06-19T01:16:53+00:00

commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.

When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.

Fix this by return immediately if dev->num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.

Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[   62.628906] [] drm_vblank_post_modeset+0x34/0xb4
[   62.628906] [] atombios_crtc_dpms+0xb4/0x174
[   62.628906] [] atombios_crtc_commit+0x18/0x38
[   62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc
[   62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988
[   62.628906] [] drm_fb_helper_set_par+0x94/0x104
[   62.628906] [] fbcon_init+0x424/0x57c
[   62.628906] [] visual_init+0xb8/0x118
[   62.628906] [] take_over_console+0x238/0x384
[   62.628906] [] fbcon_takeover+0x7c/0xdc
[   62.628906] [] notifier_call_chain+0x44/0x94
[   62.628906] [] __blocking_notifier_call_chain+0x48/0x68
[   62.628906] [] register_framebuffer+0x228/0x260
[   62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314
[   62.628906] [] drm_fb_helper_initial_config+0x200/0x234
[   62.628906] [] radeon_fbdev_init+0xd4/0xf4
[   62.628906] [] radeon_modeset_init+0x9bc/0xa18
[   62.628906] [] radeon_driver_load_kms+0xdc/0x12c
[   62.628906] [] drm_get_pci_dev+0x148/0x238
[   62.628906] [] local_pci_probe+0x5c/0xd0
[   62.628906] [] work_for_cpu_fn+0x1c/0x30
[   62.628906] [] process_one_work+0x274/0x3bc
[   62.628906] [] process_scheduled_works+0x24/0x44
[   62.628906] [] worker_thread+0x31c/0x3f4
[   62.628906] [] kthread+0x88/0x90
[   62.628906] [] kernel_thread_helper+0x10/0x18

Signed-off-by: Huacai Chen 
Signed-off-by: Binbin Zhou 
Reviewed-by: Michel Dänzer 
Acked-by: Paul Menzel 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: fix card_posted check for newer asics

2013-06-19T01:16:40+00:00

commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream.

Newer asics have variable numbers of crtcs.  Use that
rather than the asic family to determine which crtcs
to check.  This avoids checking non-existent crtcs or
missing crtcs on certain asics.

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

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