1. 04 Sep, 2015 5 commits
  2. 02 Sep, 2015 30 commits
  3. 01 Sep, 2015 5 commits
    • Ville Syrjälä's avatar
      drm/i915: Factor out intel_crtc_has_encoders() · 02e93c35
      Ville Syrjälä authored
      Make the code mode readable by pulling the "does this crtc have any
      encoders?" deduction into a separate function.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      02e93c35
    • Ville Syrjälä's avatar
      drm/i915: Fix clock readout when pipes are enabled w/o ports · 0f64614d
      Ville Syrjälä authored
      The BIOS sometimes likes to enable pipes w/o any ports, at least on
      older machines. Currently we fail to assign anything sensible to
      crtc->hwmode.crtc_clock which leads to complaints from the vblank code.
      Deal with active pipes w/o ports and assign something sensible to
      crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will
      override this if the port is enabled.
      
      Gets rid of rest of these on my gen4:
      [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate constants, dotclock = 0!
      [drm:i915_get_vblank_timestamp] crtc 1 is disabled
      
      v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten)
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0f64614d
    • 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