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

drm/gma500: Increase max resolution for mode setting

2013-06-13T16:45:03+00:00

commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream.

By having a higher max resolution we can now set up a virtual
framebuffer that spans several monitors. 4096 should be ok since we're
gen 3 or higher and should be enough for most dual head setups.

Bugzilla:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Greg Kroah-Hartman

drm/i915: no lvds quirk for hp t5740

2013-06-13T16:45:02+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: Greg Kroah-Hartman

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

2013-06-13T16:45:02+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: Greg Kroah-Hartman

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

2013-06-13T16:45:02+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: Greg Kroah-Hartman

drm/radeon: don't allow audio on DCE6

2013-06-13T16:45:00+00:00

commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream.

It's not supported yet.  Fixes display issues when
users force it on.

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

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

2013-06-13T16:45:00+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

drm/radeon: fix card_posted check for newer asics

2013-06-07T19:49:31+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: Greg Kroah-Hartman

drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

2013-05-24T18:14:22+00:00

commit fc986034540102cd090237bf3f70262e1ae80d9c upstream.

Add ULL prefix to avoid overflow.

Signed-off-by: Niels Ole Salscheider 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: check incoming cliprects pointer

2013-05-19T17:54:50+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: Greg Kroah-Hartman

drm/mm: fix dump table BUG

2013-05-19T17:54:41+00:00

commit 3a359f0b21ab218c1bf7a6a1b638b6fd143d0b99 upstream.

In

commit 9e8944ab564f2e3dde90a518cd32048c58918608
Author: Chris Wilson 
Date:   Thu Nov 15 11:32:17 2012 +0000

    drm: Introduce an iterator over holes in the drm_mm range manager

helpers and iterators for hole handling have been introduced with some
debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper
which unconditionally tried to compute the size of the very first
hole.

While at it unify the code a bit with the hole dumping in the loop.

v2: Extract a hole dump helper.

Reported-by: Christopher Harvey 
Cc: Christopher Harvey 
Cc: Dave Airlie 
Cc: Chris Wilson 
Acked-by: Dave Airlie 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman