1. 20 Dec, 2011 1 commit
  2. 21 Oct, 2011 2 commits
  3. 20 Oct, 2011 5 commits
  4. 06 Oct, 2011 1 commit
    • Keith Packard's avatar
      drm/i915: Correct eDP panel power sequencing delay computations · f01eca2e
      Keith Packard authored
      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: default avatarKeith Packard <keithp@keithp.com>
  5. 30 Sep, 2011 2 commits
  6. 21 Sep, 2011 2 commits
    • Ben Widawsky's avatar
      drm/i915: Dumb down the semaphore logic · c8c99b0f
      Ben Widawsky authored
      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...
      Remove magic per Keith's suggestions.
      Ran Daniel's gem_ring_sync_loop test on this.
      Ignored one of Keith's suggestions.
      Removed some bloat per Daniel's recommendation.
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
    • Wu Fengguang's avatar
      drm/i915: pass ELD to HDMI/DP audio driver · e0dac65e
      Wu Fengguang authored
      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: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
  7. 19 Sep, 2011 1 commit
  8. 19 Aug, 2011 1 commit
  9. 08 Aug, 2011 1 commit
  10. 03 Aug, 2011 2 commits
  11. 29 Jul, 2011 2 commits
  12. 28 Jul, 2011 2 commits
    • Jesse Barnes's avatar
      drm/i915: apply timing generator bug workaround on CPT and PPT · 3bcf603f
      Jesse Barnes authored
      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: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
    • Keith Packard's avatar
      drm/i915: DP_PIPE_ENABLED must check transcoder on CPT · f0575e92
      Keith Packard authored
      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: default avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarAdam Jackson <ajax@redhat.com>
  13. 13 Jul, 2011 1 commit
  14. 08 Jul, 2011 1 commit
  15. 28 Jun, 2011 1 commit
    • Jesse Barnes's avatar
      drm/i915: load a ring frequency scaling table v3 · 23b2f8bb
      Jesse Barnes authored
      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.
        - 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)
        - fix comments & debug output
        - remove unneeded force wake get/put
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Tested-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
  16. 21 Jun, 2011 1 commit
  17. 13 May, 2011 5 commits
  18. 10 May, 2011 1 commit
  19. 10 Mar, 2011 1 commit
  20. 06 Mar, 2011 1 commit
  21. 01 Mar, 2011 1 commit
  22. 22 Feb, 2011 1 commit
  23. 21 Feb, 2011 1 commit
    • Indan Zupancic's avatar
      drm/i915: Do not handle backlight combination mode specially · 951f3512
      Indan Zupancic authored
      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:
      Signed-off-by: default avatarIndan Zupancic <indan@nul.nu>
      Tested-by: default avatarAlex Riesen <raa.lkml@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  24. 11 Feb, 2011 1 commit
  25. 07 Feb, 2011 2 commits