linux-toradex.git/drivers/gpu, branch v2.6.32.4

drm/i915: remove render reclock support

2010-01-18T18:19:48+00:00

commit cda9d05c499093c67b4a376a15009923acc2127a upstream.

This code generally fails to adjust the render clock, and when it does,
it conflicts with some other register settings and can cause problems.

So remove this code altogether.  I'm reworking it now to do the right
thing, but the only bit it will share is the VBT check for whether
reclocking is supported, so I'm leaving that bit.

Reverts most of 652c393a3368af84359da37c45afc35a91144960 ("add dynamic
clock frequency control"), though for many the regressions showed up
in the later 181a5336d6cc836f05507410d66988c483ad0154 ("Fix render
reclock availability detection").

Signed-off-by: Jesse Barnes 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix unused var

2010-01-18T18:19:28+00:00

commit 29bd0ae25f8cb96b63560c2cbccec77b425e1603 upstream.

drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function

Partly this is because gcc isn't smart enough.  But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.

Cc: Jesse Barnes 
Cc: Eric Anholt 
Cc: Dave Airlie 
Signed-off-by: Andrew Morton 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Select the correct BPC for LVDS on Ironlake

2010-01-18T18:19:27+00:00

commit e5a95eb778690bc864eb330202d2c1b974caaeb4 upstream.

Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel,
the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8.
At the same time the BPC will be 8 when the output device is CRT/HDMI/DP.

Signed-off-by: Zhao Yakui 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake

2010-01-18T18:19:25+00:00

commit 8faf3b317471179c02db339aa80955a2e88c036d upstream.

Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake.

Signed-off-by: Zhao Yakui 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Enable/disable the dithering for LVDS based on VBT setting

2010-01-18T18:19:24+00:00

commit 898822ce9561ab9b58a7eb60580a162a83dadecd upstream.

Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x
platform the dithering flag is defined in LVDS register. And on the ironlake
the dithering flag is defined in pipeconf register.

Signed-off-by: Zhao Yakui 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm: remove address mask param for drm_pci_alloc()

2010-01-18T18:19:23+00:00

commit e6be8d9d17bd44061116f601fe2609b3ace7aa69 upstream.

drm_pci_alloc() has input of address mask for setting pci dma
mask on the device, which should be properly setup by drm driver.
And leave it as a param for drm_pci_alloc() would cause confusion
or mistake would corrupt the correct dma mask setting, as seen on
intel hw which set wrong dma mask for hw status page. So remove
it from drm_pci_alloc() function.

Signed-off-by: Zhenyu Wang 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Permit pinning whilst the device is 'suspended'

2010-01-18T18:19:23+00:00

commit e3d8affb0d2d95f2da61e30ce86b33177feb91e8 upstream.

As pinning (allocating and binding GTT memory) does not actually invoke
GPU commands, it is safe, and indeed is attempted, during resumption
from suspension:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16

Signed-off-by: Chris Wilson 
Reported-by: Hugh Dickins 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix order of fence release wrt flushing

2010-01-18T18:19:23+00:00

commit 96b47b65594fe2365f73aede060cb5203561fed3 upstream.

i915_gem_object_unbind had the ordering wrong. The other user,
i915_gem_object_put_fence_reg already has the correct ordering.

Results was usually corrupted pixmaps, especially garbled font glyphs
after a suspend/resume (because this evicts everything).

I'm still waiting for the feedback from the bug-reporters, but
because this obviously fixes a bug (at least for me) I'm already
submitting it.

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Daniel Vetter 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Update LVDS connector status when receiving ACPI LID event

2010-01-18T18:19:22+00:00

commit a2565377a5c31e25c77c7cabaf6752abe9a2d83a upstream.

Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
close/reopen the LID. And I also reproduce this issue on another laptop.
After some tests and debug, it seems that it is related with that the
LVDS status is not updated in time in course of suspend/resume.

Now the LID state is used to check whether the LVDS is connected or
disconnected. And when the LID is closed, it means that the LVDS is
disconnected. When it is reopened, it means that the LVDS is connected.
At the same time on some distributions the LID event is also used to put
the system into suspend state. When the LID is closed, the system will enter
the suspend state. When the LID is reopened, the system will be resumed.

In such case when the LID is closed, user-space script will receive the LID
notification event and  detect the LVDS as disconnected. Then the system will
enter the suspended state. When the LID is reopened, the system will be
resumed. As the LVDS status is not updated in course of resume, it will cause
that the LVDS connector is marked as unused and disabled. After the resume is
finished,user-space script will try to configure the display mode for LVDS.
But unfortunately as the LVDS status is not updated in time and it is still
marked as disconnected, the LVDS and its corresponding CRTC will be disabled
again in the function of drm_helper_disable_unused_functions after changing
mode for LVDS.

So we had better check and update the status of LVDS connector after receiving
the LID notication event. Then after the system is resumed from suspended
state, we can set the display mode for LVDS correctly.

Signed-off-by: Zhao Yakui 
Reported-by:  Dirk Hohndel 
Reviewed-by: Jesse Barnes 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

drm: disable all the possible outputs/crtcs before entering KMS mode

2010-01-06T23:04:53+00:00

commit b16d9acbdb97452d1418420e069acf7381ef10bb upstream.

Sometimes we will use a crtc for integerated LVDS, which is different with
that assigned by BIOS. If we want to get flicker-free transitions,
then we could read out the current state for it and set our current state
accordingly.

But it is true that if we aren't reading current state out, we do need
to turn everything off before modesetting.  Otherwise the clocks can get very
angry and we get things worse than a flicker at boot.
In fact we also do the similar thing in UMS mode. We will disable all the
possible outputs/crtcs for the first modesetting.

So we disable all the possible outputs/crtcs before entering the KMS mode.
Before we configure connector/encoder/crtc, the function of
drm_helper_disable_unused_function can disable all the possible outputs/crtcs.

Signed-off-by: Zhao Yakui 
Reviewed-by: Eric Anholt 
Reviewed-by: Rafal Milecki 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman