1. 10 10月, 2017 1 次提交
  2. 06 10月, 2017 1 次提交
  3. 05 10月, 2017 2 次提交
  4. 03 10月, 2017 1 次提交
    • I
      drm/i915: Fix DDI PHY init if it was already on · e19c1eb8
      Imre Deak 提交于
      The common lane power down flag of a DPIO PHY has a funky semantic:
      after the initial enabling of the PHY (so from a disabled state) this
      flag will be clear. It will be set only after the PHY will be used for
      the first time (for instance due to enabling the corresponding pipe) and
      then become unused (due to disabling the pipe). During the initial PHY
      enablement we don't know which of the above phases we are in, so move
      the check for the flag where this is known, the HW readout code. This is
      where the rest of lane power down status checks are done anyway.
      
      This fixes at least a problem on GLK where after module reloading, the
      common lane power down flag of PHY1 is set, but the PHY is actually
      powered-on and properly set up. The GRC readout code for other PHYs will
      hence think that PHY1 is not powered initially and disable it after the
      GRC readout. This will cause the AUX power well related to PHY1 to get
      disabled in a stuck state, timing out when we try to enable it later.
      
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Fixes: e93da0a0 ("drm/i915/bxt: Sanitiy check the PHY lane power down status")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171002135307.26117-1-imre.deak@intel.com
      e19c1eb8
  5. 20 9月, 2017 3 次提交
  6. 15 9月, 2017 1 次提交
  7. 01 9月, 2017 8 次提交
  8. 22 8月, 2017 6 次提交
  9. 15 8月, 2017 1 次提交
  10. 12 8月, 2017 1 次提交
  11. 28 7月, 2017 1 次提交
  12. 27 7月, 2017 2 次提交
  13. 11 7月, 2017 1 次提交
  14. 08 7月, 2017 1 次提交
  15. 26 6月, 2017 1 次提交
  16. 20 6月, 2017 1 次提交
  17. 13 6月, 2017 5 次提交
  18. 12 6月, 2017 1 次提交
  19. 01 6月, 2017 1 次提交
    • I
      drm/i915/ddi: Avoid long delays during system suspend / eDP disabling · 7618138d
      Imre Deak 提交于
      Atm disabling either DP or eDP outputs can generate a spurious short
      pulse interrupt. The reason is that after disabling the port the source
      will stop sending a valid stream data, while the sink expects either a
      valid stream or the idle pattern. Since neither of this is sent the sink
      assumes (after an arbitrary delay) that the link is lost and requests
      for link retraining with a short pulse.
      
      The spurious pulse is a real problem at least for eDP panels with long
      power-off / power-cycle delays: as part of disabling the output we
      disable the panel power. The subsequent spurious short pulse handling
      will have to turn the power back on, which means the driver has to do a
      redundant wait for the power-off and power-cycle delays. During system
      suspend this leads to an unnecessary delay up to ~1s on systems with
      such panels as reported by Rui.
      
      To fix this put the sink to DPMS D3 state before turning off the port.
      According to the DP spec in this state the sink should not request
      retraining. This is also what we do already on pre-ddi platforms.
      
      As an alternative I also tried configuring the port to send idle pattern
      - which is against BSPec - and leave the port in normal mode before
      turning off the port. Neither of these resolved the problem.
      
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: David Weinehall <david.weinehall@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reported-and-tested-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1496250335-7627-1-git-send-email-imre.deak@intel.com
      7618138d
  20. 31 3月, 2017 1 次提交