Skip to content
  • Daniel Vetter's avatar
    drm/i915: convert dpms functions of dvo/sdvo/crt · b2cabb0e
    Daniel Vetter authored
    
    
    Yeah, big patch but I couldn't come up with a neat idea of how to
    split it up further, that wouldn't break dpms on cloned configs
    somehow. But the changes in dvo/sdvo/crt are all pretty much
    orthonogal, so it's not too bad a patch.
    
    These are the only encoders that support cloning, which requires a few
    special changes compared to the previous patches.
    - Compute the desired state of the display pipe by walking all
      connected encoders and checking whether any has active connectors.
      To make this clearer, drop the old mode parameter to the crtc dpms
      function and rename it to intel_crtc_update_dpms.
    - There's the curious case of intel_crtc->dpms_mode. With the previous
      patches to remove the overlay pipe A code and to rework the load
      detect pipe code, the big users are gone. We still keep it to avoid
      enabling the pipe twice, but we duplicate this logic with
      crtc->active, too. Still, leave this for now and just push a fake
      dpms mode into it that reflects the state of the display pipe.
    
    Changes in the encoder dpms functions:
    - We clamp the dpms state to the supported range right away. This is
      escpecially important for the VGA outputs, where only older hw
      supports the intermediate states. This (and the crt->adpa_reg patch)
      allows us to unify the crt dpms code again between all variants
      (gmch, vlv and pch).
    - We only enable/disable the output for dvo/sdvo and leave the encoder
      running. The encoder will be disabled/enabled when we switch the
      state of the entire output pipeline (which will happen right away
      for non-cloned setups). This way the duplication is reduced and
      strange interaction when disabling output ports at the wrong time
      avoided.
    
    The dpms code for all three types of connectors contains a bit of
    duplicated logic, but I think keeping these special cases separate is
    simpler: CRT is the only one that hanldes intermediate dpms state
    (which requires extra logic to enable/disable things in the right
    order), and introducing some abstraction just to share the code
    between dvo and sdvo smells like overkill. We can do that once someone
    bothers to implement cloning for the more modern outputs. But I doubt
    that this will ever happen.
    
    v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni.
    
    Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    b2cabb0e