Skip to content

L
linux
Switch branch/tag
  1. 04 Sep, 2015 7 commits
  3. 02 Sep, 2015 30 commits
  5. 01 Sep, 2015 3 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7