Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 30 7月, 2011 2 次提交
  3. 29 7月, 2011 2 次提交
    • J
      drm/i915: apply timing generator bug workaround on CPT and PPT · 3bcf603f
      由 Jesse Barnes 提交于 
      On CougarPoint and PantherPoint PCH chips, the timing generator may fail
to start after DP training completes.  This is due to a bug in the
FDI autotraining detect logic (which will stall the timing generator and
re-enable it once training completes), so disable it to avoid silent DP
mode setting failures.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      3bcf603f
    • K
      drm/i915: DP_PIPE_ENABLED must check transcoder on CPT · f0575e92
      由 Keith Packard 提交于 
      Display port pipe selection on CPT is not done with a bit in the
output register, rather it is controlled by a couple of bits in the
separate transcoder register which indicate which display port output
is connected to the transcoder.

This patch replaces the simplistic macro DP_PIPE_ENABLED with the
rather more complicated function dp_pipe_enabled which checks the
output register to see if that is enabled, and then goes on to either
check the output register pipe selection bit (on non-CPT) or the
transcoder DP selection bits (on CPT).

Before this patch, any time the mode of pipe A was changed, any
display port outputs on pipe B would get disabled as
intel_disable_pch_ports would ensure that the mode setting operation
could occur on pipe A without interference from other outputs
connected to that pch port
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
      f0575e92
  5. 22 6月, 2011 1 次提交
  7. 14 5月, 2011 5 次提交
  9. 11 5月, 2011 1 次提交
  11. 11 3月, 2011 1 次提交
  13. 06 3月, 2011 1 次提交
  15. 02 3月, 2011 1 次提交
  17. 22 2月, 2011 2 次提交
    • C
      drm/i915: Add support for limited color range of broadcast outputs · e953fd7b
      由 Chris Wilson 提交于 
      In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      e953fd7b
    • I
      drm/i915: Do not handle backlight combination mode specially · 951f3512
      由 Indan Zupancic 提交于 
      The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.

If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.

A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.

IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.

For more information see the below links. This fixes bugs:

  http://bugzilla.kernel.org/show_bug.cgi?id=23472
  http://bugzilla.kernel.org/show_bug.cgi?id=25072Signed-off-by: NIndan Zupancic <indan@nul.nu>
Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      951f3512
  19. 12 2月, 2011 1 次提交
  21. 08 2月, 2011 1 次提交
  23. 07 2月, 2011 1 次提交
  25. 02 2月, 2011 1 次提交
  27. 19 1月, 2011 6 次提交
  29. 18 1月, 2011 1 次提交
  31. 12 1月, 2011 6 次提交
  33. 23 12月, 2010 2 次提交
  35. 18 12月, 2010 1 次提交
  37. 17 12月, 2010 1 次提交
    • M
      drm/i915: Add support for precise vblank timestamping (v2) · 0af7e4df
      由 Mario Kleiner 提交于 
      v2: Change IS_IRONLAKE to IS_GEN5 to adapt to 2.6.37

This patch adds new functions for use by the drm core:

.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work.

.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().

The patch modifies the pageflip completion routine
to use these precise vblank timestamps as the timestamps
for pageflip completion events.

This code has been only tested on a HP-Mini Netbook with
Atom processor and Intel 945GME gpu. The codepath for
(IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
has not been tested so far due to lack of hardware.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      0af7e4df
  39. 15 12月, 2010 2 次提交
  41. 10 12月, 2010 1 次提交