Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 8月, 2011 1 次提交
  3. 04 8月, 2011 2 次提交
  5. 30 7月, 2011 2 次提交
  7. 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
  9. 14 7月, 2011 1 次提交
  11. 09 7月, 2011 1 次提交
  13. 29 6月, 2011 1 次提交
    • J
      drm/i915: load a ring frequency scaling table v3 · 23b2f8bb
      由 Jesse Barnes 提交于 
      The ring frequency scaling table tells the PCU to treat certain GPU
frequencies as if they were a given CPU frequency for purposes of
scaling the ring frequency.  Normally the PCU will scale the ring
frequency based on the CPU P-state, but with the table present, it will
also take the GPU frequency into account.

The main downside of keeping the ring frequency high while the CPU is
at a low frequency (or asleep altogether) is increased power
consumption.  But then if you're keeping your GPU busy, you probably
want the extra performance.

v2:
  - add units to debug table header (from Eric)
  - use tsc_khz as a fallback if the cpufreq driver doesn't give us a freq
    (from Chris)
v3:
  - fix comments & debug output
  - remove unneeded force wake get/put
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      23b2f8bb
  15. 22 6月, 2011 1 次提交
  17. 14 5月, 2011 5 次提交
  19. 11 5月, 2011 1 次提交
  21. 11 3月, 2011 1 次提交
  23. 06 3月, 2011 1 次提交
  25. 02 3月, 2011 1 次提交
  27. 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
  29. 12 2月, 2011 1 次提交
  31. 08 2月, 2011 1 次提交
  33. 07 2月, 2011 1 次提交
  35. 02 2月, 2011 1 次提交
  37. 19 1月, 2011 6 次提交
  39. 18 1月, 2011 1 次提交
  41. 12 1月, 2011 6 次提交
  43. 23 12月, 2010 1 次提交