linux-toradex.git/drivers, 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

USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer

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

commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream.

Pointers should not be compared to plain integers.
Quiets the sparse warning:
warning: Using plain integer as NULL pointer

Signed-off-by: Ying Xue 
Cc: Lotfi Manseur 
Signed-off-by: Greg Kroah-Hartman

xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

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

commit 51ac8893a7a51b196501164e645583bf78138699 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
Reviewed-by: Konrad Rzeszutek Wilk 
[stable tree: Added two extra #include files]
Signed-off-by: Konrad Rzeszutek Wilk 
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

hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617

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

commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.

On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
Also improve detection for ADM1021.

Modeled after chip detection code in sensors-detect command.

Signed-off-by: Guenter Roeck 
Tested-by: Jean Delvare 
Acked-by: Jean Delvare 
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

ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6

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

commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.

This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from
BIOS.

References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
Signed-off-by: Ash Willis 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman