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

drm/nouveau: fix booting with plymouth + dumb support

2012-09-19T14:05:24+00:00

commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc upstream.

We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.

Acked-by: Ben Skeggs 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/radeon: rework pll selection (v3)

2012-09-19T14:05:23+00:00

commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 upstream.

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

drm/radeon: fix ordering in pll picking on dce4+

2012-09-19T14:05:23+00:00

commit ecd67955fd4c8e66e4df312098989d5fa7da624c upstream.

No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.

Noticed by kallisti5 on IRC.

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

drm/radeon: fix up pll selection on DCE5/6

2012-09-19T14:05:22+00:00

commit 26fe45a0a76f165425f332a5aaa298f149f9db22 upstream.

Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.

Signed-off-by: Alex Deucher 
Reviewed-by: Christian König 
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings

vmwgfx: add dumb ioctl support

2012-09-19T14:05:21+00:00

commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream.

Testing and works with the -modesetting driver,

Reviewed-by: Jakob Bornecrantz 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: only enable sdvo hotplug irq if needed

2012-09-19T14:05:05+00:00

commit fcbc50da7753b210b4442ca9abc4efbd4e481f6e upstream.

Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:

commit 768b107e4b3be0acf6f58e914afe4f337c00932b
Author: Daniel Vetter 
Date:   Fri May 4 11:29:56 2012 +0200

    drm/i915: disable sdvo hotplug on i945g/gm

v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Tested-by: Dominik Köppl 
Signed-off-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x

2012-09-19T14:05:04+00:00

commit 084b612ecf8e59973576b2f644e6949609c79375 upstream.

Note that gen3 is the only platform where we've got the bit
definitions right, hence the workaround of disabling sdvo hotplug
support on i945g/gm is not due to misdiagnosis of broken hotplug irq
handling ...

Signed-off-by: Chris Wilson 
[danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
wondered about while reviewing.]
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.2:
 - Adjust context
 - Handle all three cases in i915_driver_irq_postinstall() as there
   are not separate functions for gen3 and gen4+
 - Carry on using IS_SDVOB() in intel_sdvo_init()]
Signed-off-by: Ben Hutchings

drm/i915: Wait for all pending operations to the fb before disabling the pipe

2012-09-19T14:05:00+00:00

During modeset we have to disable the pipe to reconfigure its timings
and maybe its size. Userspace may have queued up command buffers that
depend upon the pipe running in a certain configuration and so the
commands may become confused across the modeset. At the moment, we use a
less than satisfactory kick-scanline-waits should the GPU hang during
the modeset. It should be more reliable to wait for the pending
operations to complete first, even though we still have a window for
userspace to submit a broken command buffer during the modeset.

Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
(cherry picked from commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a)

Signed-off-by: Timo Aaltonen

fixing dmi match for hp t5745 and hp st5747 thin client

2012-09-19T14:04:59+00:00

commit 62004978df3898649e152751eb6ac264a323ec36 upstream.

Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916

Signed-off-by: Marc Gariepy 
Reviewed-by: Adam Jackson 
Signed-Off-by: Daniel Vetter 
Signed-off-by: Ben Hutchings

drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

2012-09-19T14:04:45+00:00

commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings