1. 01 Sep, 2015 6 commits
    • Ville Syrjälä's avatar
      drm/i915: Add CHV PHY LDO power sanity checks · 30142273
      Ville Syrjälä authored
      At various points when changing the DPIO lane/phy power states,
      construct an expected value of the DISPLAY_PHY_STATUS register
      and compare it with the real thing.
      
      To construct the expected value we look at our shadow PHY_CONTROL
      register value (which should match what we've just written to the
      hardware), and we also need to look at the actual state of the cmn
      power wells as a disabled power well causes the relevant LDO status
      to be reported as 'on' in DISPLAY_PHY_STATUS.
      
      When initially powering up the PHY it performs various internal
      calibrations for which it fully powers up. That means that if we check
      for the expetected power state immediately upon releasing cmnreset we
      would get the occasional false positive. But we can of course
      poll until the expected value appears. It shouldn't be too long so
      this shouldn't make modesets substantially longer.
      
      One extra complication is introduced when we cross the streams, ie.
      drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
      into life by temporaily powering up the lanes in the second channel,
      and once the pipe is up and runnign we release the lane power override.
      At that point the power state of CL2 has somehow gotten entangled with
      the power state of the first channel. That means that constructing the
      expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
      lane power states in the second channel, CL2 should also be powered
      down. But we can use the DPLL enable bit to determine when CL2 should
      be alive even if the lanes are powered down. However the power state
      of CL2 isn't actually tied in with the DPLL state, but to the state
      of the lanes in first channel, so we have to avoid checking the
      expected state between shutting down the DPLL and powering down
      the lanes in the first channel. So no calling assert_chv_phy_status()
      before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
      but after the write is a safe time to check.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      30142273
    • Ville Syrjälä's avatar
      drm/i915: Add some CHV DPIO lane power state asserts · 6669e39f
      Ville Syrjälä authored
      Add some checks that the state of the DPIO lanes is more or less what we
      expect based on the overrides.
      
      The hardware only provides two bits per channel indicating whether all
      or some of the lanes are powered down, so we can't do an exact check.
      
      Additionally, CL2 powering down before we can check it adds another
      twist. To work around this we simply check for the 0 value of the
      CL2 register (which is what we get when it's powered down) and
      adjust our expectations.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6669e39f
    • Ville Syrjälä's avatar
      drm/i915: Clean up CHV lane soft reset programming · a8f327fb
      Ville Syrjälä authored
      Currently we release the lane soft reset before lane stagger settings
      have been programmed. I believe that means we don't actually do lane
      staggering. So move the soft reset deassert to happen after lane
      staggering has been programmed.
      
      The one confusing thing in this is that when we remove the power down
      override from the lanes, they power up with defaul register values,
      which do not have the soft reset overrides enabled. And according to
      some docs by default the data lane resets are tied to cmnreset. So that
      would mean that lanes would come out of reset without staggering as
      soon as the power down overrides are removed. But since we can't access
      either the lane stagger register nor the soft reset override registers
      until the lanes are powered on, we can't really do anything about it.
      So let's just set the soft reset overrides as soon as the lane is
      powered on and hope for the best.
      
      v2: Fix typos in commit message (Daniel)
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a8f327fb
    • Francisco Jerez's avatar
      drm/i915: Bump command parser version number. · 2bbe6bbb
      Francisco Jerez authored
      This was forgotten in
      
      commit d351f6d9
      Author: Francisco Jerez <currojerez@riseup.net>
      Date:   Fri May 29 16:44:15 2015 +0300
      
          drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.
      Signed-off-by: default avatarFrancisco Jerez <currojerez@riseup.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2bbe6bbb
    • Jani Nikula's avatar
      drm/i915/dp: use the drm dp helper for determining sink tps3 support · caa860d9
      Jani Nikula authored
      No functional changes.
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: s/intel_dp_tps/drm_dp_tps/.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      caa860d9
    • Jani Nikula's avatar
      drm/dp: add drm_dp_tps3_supported helper · 7cc53cf0
      Jani Nikula authored
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7cc53cf0
  2. 28 Aug, 2015 1 commit
  3. 26 Aug, 2015 33 commits