1. 05 10月, 2017 2 次提交
  2. 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
  3. 20 9月, 2017 3 次提交
  4. 15 9月, 2017 1 次提交
  5. 01 9月, 2017 8 次提交
  6. 22 8月, 2017 6 次提交
  7. 15 8月, 2017 1 次提交
  8. 12 8月, 2017 1 次提交
  9. 28 7月, 2017 1 次提交
  10. 27 7月, 2017 2 次提交
  11. 11 7月, 2017 1 次提交
  12. 08 7月, 2017 1 次提交
  13. 26 6月, 2017 1 次提交
  14. 20 6月, 2017 1 次提交
  15. 13 6月, 2017 5 次提交
  16. 12 6月, 2017 1 次提交
  17. 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
  18. 31 3月, 2017 1 次提交
  19. 28 3月, 2017 2 次提交
    • S
      drm/i915: enable scrambling · 15953637
      Shashank Sharma 提交于
      Geminilake platform sports a native HDMI 2.0 controller, and is
      capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
      mendates scrambling for these higher clocks, for reduced RF footprint.
      
      This patch checks if the monitor supports scrambling, and if required,
      enables it during the modeset.
      
      V2: Addressed review comments from Ville:
       - Do not track scrambling status in DRM layer, track somewhere in
         driver like in intel_crtc_state.
       - Don't talk to monitor at such a low layer, set monitor scrambling
         in intel_enable_ddi() before enabling the port.
      
      V3: Addressed review comments from Jani
       - In comments, function names, use "sink" instead of "monitor",
         so that the implementation could be close to the language of
         HDMI spec.
      
      V4: Addressed review comment from Maarten
       - scrambling -> hdmi_scrambling
       - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
      
      V5: Addressed review comments from Ville and Ander
       - Do not modifiy the crtc_state after compute_config. Move all
         scrambling and tmds_clock_ratio calcutations to compute_config.
       - While setting scrambling for source/sink, do not check the
         conditions again, just go by the crtc_state flags. This will
         simplyfy the condition checks.
      
      V6: Addressed review comments from Ville
       - Do not add IS_GLK check in disable/enable function, instead add it
         in compute_config, while setting state flags.
       - Remove unnecessary paranthesis.
       - Simplyfy handle_sink_scrambling function as suggested.
       - Add readout code for scrambling status in get_ddi_config and add a
         check for the same in pipe_config_compare.
      
      V7: Addressed review comments from Ander/Ville
       - No separate function for source scrambling, make it inline
       - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
       - Do not add platform check while setting source scrambling
       - Use pipe_config instead of crtc->config to set sink scrambling
       - To readout scrambling status, Compare with SCRAMBLING_MASK
         not any of its bits
       - Remove platform check in intel_pipe_config_compare while checking
         scrambling status
      
      V8: Fixed mege conflict, Addressed review comments from Ander
       - Remove the desciption/comment about scrambling fom the caller, move
         it to the function
       - Move the IS_GLK check into scrambling function
       - Fix alignment
      
      V9: Fixed review comments from Ville, Ander
       - Pass the scrambling state variables as bool input to the sink_scrambling
         function and let the disable call be unconditional.
       - Fix alignments in function calls and debug messages.
       - Add kernel doc for function intel_hdmi_handle_sink_scrambling
      
      V10: Rebase
      Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
      15953637
    • P
      drm/i915: kill intel_ddi_pll_select() · 44a126ba
      Paulo Zanoni 提交于
      All it does is pick the encoder and call intel_get_shared_dpll(). We
      can just do this in the caller. One less indirection level during code
      reading.
      
      As another plus, now the two callers of intel_get_shared_dpll() are
      {ironlake,haswell}_crtc_compute_clock().
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1490209125-20046-2-git-send-email-paulo.r.zanoni@intel.com
      44a126ba