Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 10月, 2011 2 次提交
  3. 06 10月, 2011 1 次提交
    • K
      drm/i915: Correct eDP panel power sequencing delay computations · f01eca2e
      由 Keith Packard 提交于 
      Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.

From the eDP spec, we need the following numbers:

 T1 + T3	Power on to Aux Channel operation (panel_power_up_delay)

		This marks how long it takes the panel to boot up and
		get ready to receive aux channel communications.

 T8		Video signal to backlight on (backlight_on_delay)

		Once a valid video signal is being sent to the device,
		it can take a while before the panel is actuall
		showing useful data. This delay allows the panel
		to get something reasonable up before the backlight
		is turned on.

 T9		Backlight off to video off (backlight_off_delay)

		Turning the backlight off can take a moment, so
		this delay makes sure there is still valid video
		data on the screen.

 T10		Video off to power off (panel_power_down_delay)

		Presumably this delay allows the panel to perform
		an orderly shutdown of the display.

 T11 + T12	Power off to power on (panel_power_cycle_delay)

		So, once you turn the panel off, you have to wait a
		while before you can turn it back on. This delay is
		usually the longest in the entire sequence.

Neither the VBIOS source code nor the hardware documentation has a
clear mapping between the delay values they provide and those required
by the eDP spec. The VBIOS code actually uses two different labels for
the delay values in the five words of the relevant VBT table.

**** MORE LATER ***

Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware. Note that the BIOS just fetches
delays from the VBT table to place in the hardware registers, so we
should get the same values from both places, except for rounding.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

For the backlight delays, the eDP spec says T6 + T8 is the delay from the
end of link training to backlight on and T9 is the delay from
backlight off until video off. The hardware provides a 'backlight on'
delay, which I'm taking to be T6 + T8 while the VBT provides something
called 'T7', which I'm assuming is s

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: NKeith Packard <keithp@keithp.com>
      f01eca2e
  5. 01 10月, 2011 2 次提交
  7. 22 9月, 2011 2 次提交
    • B
      drm/i915: Dumb down the semaphore logic · c8c99b0f
      由 Ben Widawsky 提交于 
      While I think the previous code is correct, it was hard to follow and
hard to debug. Since we already have a ring abstraction, might as well
use it to handle the semaphore updates and compares.

I don't expect this code to make semaphores better or worse, but you
never know...

v2:
Remove magic per Keith's suggestions.
Ran Daniel's gem_ring_sync_loop test on this.

v3:
Ignored one of Keith's suggestions.

v4:
Removed some bloat per Daniel's recommendation.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      c8c99b0f
    • W
      drm/i915: pass ELD to HDMI/DP audio driver · e0dac65e
      由 Wu Fengguang 提交于 
      Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.

ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:

(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]

(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
    ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver

This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Test scheme: plug in the HDMI/DP monitor, and run

        cat /proc/asound/card0/eld*

to check if the monitor name, HDMI/DP type, etc. show up correctly.

Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.

Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.

CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      e0dac65e
  9. 20 9月, 2011 1 次提交
  11. 20 8月, 2011 1 次提交
  13. 09 8月, 2011 1 次提交
  15. 04 8月, 2011 2 次提交
  17. 30 7月, 2011 2 次提交
  19. 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
  21. 14 7月, 2011 1 次提交
  23. 09 7月, 2011 1 次提交
  25. 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
  27. 22 6月, 2011 1 次提交
  29. 14 5月, 2011 5 次提交
  31. 11 5月, 2011 1 次提交
  33. 11 3月, 2011 1 次提交
  35. 06 3月, 2011 1 次提交
  37. 02 3月, 2011 1 次提交
  39. 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
  41. 12 2月, 2011 1 次提交
  43. 08 2月, 2011 1 次提交
  45. 07 2月, 2011 1 次提交
  47. 02 2月, 2011 1 次提交
  49. 19 1月, 2011 5 次提交