1. 06 Sep, 2012 38 commits
    • Daniel Vetter's avatar
      drm/i915: extract intel_set_config_update_output_state · 2e431051
      Daniel Vetter authored
      Note that this function already clobbers the mode config state,
      so we have to clean things up if something fails.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2e431051
    • Daniel Vetter's avatar
      drm/i915: extract intel_set_config_compute_mode_changes · 5e2b584e
      Daniel Vetter authored
      This computes what exactly changed in the modeset configuration, i.e.
      whether a full modeset is required or only an update of the
      framebuffer base address or no change at all.
      
      In the future we might add more checks for e.g. when only the output
      mode changed, so that we could do a minimal modeset for outputs that
      support this. Like the lvds/eDP panels where we only need to update
      the panel fitter.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5e2b584e
    • Daniel Vetter's avatar
      drm/i915: extract modeset config save/restore code · 85f9eb71
      Daniel Vetter authored
      At the end this won't be of much use to us, but meanwhile just extract
      it to get a better overview of what exactly set_config does.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      85f9eb71
    • Daniel Vetter's avatar
      drm/i915: introduce struct intel_set_config · d9e55608
      Daniel Vetter authored
      intel_crtc_set_config is an unwidly beast and is in serious need of
      some function extraction. To facilitate that, introduce a struct to
      keep track of all the state involved. Atm it doesn't do much more than
      keep track of all the allocated memory.
      
      v2: Apply some bikeshed to intel_set_config_free, as suggested by
      Jesse Barnes.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d9e55608
    • Daniel Vetter's avatar
      drm/i915: ensure the force pipe A quirk is actually followed · 7fad798e
      Daniel Vetter authored
      Many BIOSen forget to turn on the pipe A after resume (because they
      actually don't turn on anything), so we have to do that ourselves when
      sanitizing the hw state.
      
      I've discovered this due to the recent addition of a pipe WARN that
      takes the force quirk into account.
      
      v2: Actually try to enable the pipe with a proper configuration instead
      of simpyl switching it on with whatever random state the bios left it
      in after resume.
      
      v3: Fixup rebase conflict - the load_detect functions have lost their
      encoder argument.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7fad798e
    • Daniel Vetter's avatar
      drm/i915: rip out intel_dp->dpms_mode · 24e804ba
      Daniel Vetter authored
      We now track the connector state in encoder->connectors_active, and
      because the DP output can't be cloned, that is sufficient to track the
      link state. Hence use this instead of adding yet another modeset state
      variable with dubious semantics at driver load and resume time.
      
      Also, connectors_active should only ever be set when the encoder is
      linked to a crtc, hence convert that crtc test into a WARN.
      
      v2: Rebase on top of struct intel_dp moving.
      
      v3: The rebase accidentally killed the newly-introduced intel_dp->port
      Noticed by Paulo Zanoni.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      24e804ba
    • Daniel Vetter's avatar
      drm/i915: rip out intel_crtc->dpms_mode · 84bb65bd
      Daniel Vetter authored
      Afaict this has been used for two things:
      - To prevent the crtc enable code from being run twice. We have now
        intel_crtc->active to track this in a more precise way.
      - To ensure the code copes correctly with the unknown hw state after
        boot and resume. Thanks to the hw state readout and sanitize code we
        have now a better way to handle this.
      
      The only thing it still does is complicate our modeset state space.
      
      Having outlived its usefullness, let it just die.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      84bb65bd
    • Daniel Vetter's avatar
      drm/i915: check connector hw/sw state · 0a91ca29
      Daniel Vetter authored
      Atm we can only check the connector state after a dpms call - while
      doing modeset with the copy&pasted crtc helper code things are too
      ill-defined for proper checking. But the idea is very much to call
      this check from the modeset code, too.
      
      v2: Fix dpms check and don't presume that if the hw isn't on that it
      must not be linked up with an encoder (it could simply be switched off
      with the dpms state).
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0a91ca29
    • Daniel Vetter's avatar
      drm/i915: read out the modeset hw state at load and resume time · 24929352
      Daniel Vetter authored
      ... instead of resetting a few things and hoping that this will work
      out.
      
      To properly disable the output pipelines at the initial modeset after
      resume or boot up we need to have an accurate picture of which outputs
      are enabled and connected to which crtcs. Otherwise we risk disabling
      things at the wrong time, which can lead to hangs (or at least royally
      confused panels), both requiring a walk to the reset button to fix.
      
      Hence read out the hw state with the freshly introduce get_hw_state
      functions and then sanitize it afterwards.
      
      For a full modeset readout (which would allow us to avoid the initial
      modeset at boot up) a few things are still missing:
      - Reading out the mode from the pipe, especially the dotclock
        computation is quite some fun.
      - Reading out the parameters for the stolen memory framebuffer and
        wrapping it up.
      - Reading out the pch pll connections - luckily the disable code
        simply bails out if the crtc doesn't have a pch pll attached (even
        for configurations that would need one).
      
      This patch here turned up tons of smelly stuff around resume: We
      restore tons of register in seemingly random way (well, not quite, but
      we're not too careful either), which leaves the hw in a rather
      ill-defined state: E.g. the port registers are sometimes
      unconditionally restore (lvds, crt), leaving us with an active
      encoder/connector but no active pipe connected to it. Luckily the hw
      state sanitizer detects this madness and fixes things up a bit.
      
      v2: When checking whether an encoder with active connectors has a crtc
      wire up to it, check for both the crtc _and_ it's active state.
      
      v3:
      - Extract intel_sanitize_encoder.
      - Manually disable active encoders without an active pipe.
      
      v4: Correclty fix up the pipe<->plane mapping on machines where we
      switch pipes/planes. Noticed by Chris Wilson, who also provided the
      fixup.
      
      v5: Spelling fix in a comment, noticed by Paulo Zanoni
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      24929352
    • Daniel Vetter's avatar
      drm/i915/dvo: implement get_hw_state · 732ce74f
      Daniel Vetter authored
      Similar to the sdvo code we poke the dvo encoder whether the output is
      active. Safe that dvo encoders are not standardized, so this requires
      a new callback into the dvo chip driver.
      
      Hence implement that for all 6 dvo drivers.
      
      v2: With the newly added ns2501 we now have 6 dvo drivers instead of
      just 5 ...
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      732ce74f
    • Daniel Vetter's avatar
      drm/i915/sdvo: implement get_hw_state · 4ac41f47
      Daniel Vetter authored
      SDVO is the first real special case - we support multiple outputs on
      the same encoder and the encoder dpms state isn't the same as when
      just disabling the outputs when the encoder is cloned.
      
      Hence we need a real connector get_hw_state function which inquires
      the sdvo encoder about its active outputs.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4ac41f47
    • Daniel Vetter's avatar
      drm/i915/crt: implement get_hw_state · e403fc94
      Daniel Vetter authored
      Note that even though this connector is cloneable we still can use the
      exact same test to check whether the connector is on or whether the
      encoder is enabled - both the dpms code and the encoder disable/enable
      frob the exact same hw state.
      
      For dvo/sdvo outputs, this will be different.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e403fc94
    • Daniel Vetter's avatar
      b1dc332c
    • Daniel Vetter's avatar
      9a8ee983
    • Daniel Vetter's avatar
      85234cdc
    • Daniel Vetter's avatar
      drm/i915/dp: implement get_hw_state · 19d8fe15
      Daniel Vetter authored
      Also add some macros to make the pipe computation a bit easier.
      
      v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      19d8fe15
    • Daniel Vetter's avatar
      drm/i915: Add interfaces to read out encoder/connector hw state · f0947c37
      Daniel Vetter authored
      It is all glorious if we try really hard to only enable/disable an
      entire display pipe to ensure that everyting happens in the right
      order. But if we don't know the output configuration when the driver
      takes over, this will all be for vain because we'll make the hw angry
      right on the first modeset - we don't know what outputs/ports are
      enabled and hence have to disable everything in a rather ad-hoc way.
      
      Hence we need to be able to read out the current hw state, so that we
      can properly tear down the current hw state on the first modeset.
      Obviously this is also a nice preparation for the fastboot work, where
      we try to avoid the modeset on driver load if it matches what the hw
      is currently using.
      
      Furthermore we'll be using these functions to cross-check the actual
      hw state with what we think it should be, to ensure that the modeset
      state machine actually works as advertised.
      
      This patch only contains the interface definitions and a little helper
      for the simple case where we have a 1:1 encoder to connector mapping.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f0947c37
    • Daniel Vetter's avatar
      drm/i915: WARN when trying to enabled an unused crtc · 08a48469
      Daniel Vetter authored
      This is the first tiny step towards cross-checking the entire modeset
      state machine with WARNs. A crtc can only be enabled when it's
      actually in use, i.e. crtc->active imlies crtc->enabled.
      
      Unfortunately we can't (yet) check this when disabling the crtc,
      because the crtc helpers are a bit slopy with updating state and
      unconditionally update crtc->enabled before changing the hw state.
      
      Fixing that requires quite some more work.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      08a48469
    • Daniel Vetter's avatar
      drm/i915: call crtc functions directly · dbf2b54e
      Daniel Vetter authored
      Instead of going through the crtc helper function tables.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dbf2b54e
    • Daniel Vetter's avatar
      drm/i915: rip out encoder->prepare/commit · c9deac97
      Daniel Vetter authored
      With the new infrastructure we're doing this when enabling/disabling
      the entire display pipe.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c9deac97
    • Daniel Vetter's avatar
      drm/i915: simplify intel_crtc_prepare_encoders · 821112aa
      Daniel Vetter authored
      - We don't have the ->get_crtc callback.
      - Call intel_encoder->disable directly.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      821112aa
    • Daniel Vetter's avatar
      drm/i915: copy&paste drm_crtc_helper_set_mode · a6778b3c
      Daniel Vetter authored
      Together with the static helper functions drm_crtc_prepare_encoders
      and drm_encoder_disable (which will be simplified in the next patch,
      but for now are 1:1 copies). Again, no changes beside new names for
      these functions.
      
      Also call our new set_mode instead of the crtc helper one now in all
      the places we've done so far.
      
      v2: Call the function just intel_set_mode to better differentia it
      from intel_crtc_mode_set which really only does the ->mode_set step of
      the entire modeset sequence on one crtc. Whereas this function does
      the global change.
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a6778b3c
    • Daniel Vetter's avatar
      drm/i915: inline intel_best_encoder · 6d832d18
      Daniel Vetter authored
      Also kill the error-path, we have a fixed connector->encoder mapping.
      
      Unfortunately we can't rip out all the ->best_encoder callbacks, these
      are all still used by the fb_helper. Neat helper layering violation there.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6d832d18
    • Daniel Vetter's avatar
      drm/i915: call set_base directly · 4f660f49
      Daniel Vetter authored
      And drop the check, we always have it.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4f660f49
    • Daniel Vetter's avatar
      drm/i915: copy&paste drm_crtc_helper_set_config · 50f56119
      Daniel Vetter authored
      And the following static functions required by it:
      drm_encoder_crtc_ok, drm_crtc_helper_disable
      
      No changes safe for the s/drm/intel prefix change.
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      50f56119
    • Daniel Vetter's avatar
      drm/i915: clean up encoder_prepare/commit · 61b77ddd
      Daniel Vetter authored
      We no longer need them. And now that all encoders are converted, we
      can finally move the cpt modeset check to the right place - at the end
      of the crtc_enable function.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      61b77ddd
    • Daniel Vetter's avatar
      drm/i915: rip out encoder->disable/enable checks · fa5c73b1
      Daniel Vetter authored
      All encoders are now converted so there's no need for these checks any
      more.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fa5c73b1
    • 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
    • Daniel Vetter's avatar
      drm/i915/dvo: convert to encoder disable/enable · 19c63fa8
      Daniel Vetter authored
      Similar to the sdvo conversion.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      19c63fa8
    • Daniel Vetter's avatar
      drm/i915/sdvo: convert to encoder disable/enable · ce22c320
      Daniel Vetter authored
      Similar to crt, this doesn't convert the dpms functions.
      Also similar to crt, we don't switch of the display pipe
      for the intermediate modes, only DPMS_OFF is truely off.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ce22c320
    • Daniel Vetter's avatar
      drm/i915/crt: convert to encoder disable/enable · 2124604b
      Daniel Vetter authored
      CRT is the first output which can be cloned, hence we cannot (yet)
      move the dpms handling over to disable/enable. This requires some more
      smarts in intel_crtc_dpms first to set the display pipe status
      depening upon encoder->connectors_active of all connected encoders.
      
      Because that will happen in a separate step, don't touch the dpms
      functions, yet.
      
      v2: Be careful about clearing the _DISABLE flags for intermediate dpms
      modes - otherwise we might clobber the crt state when another (cloned)
      connector gets enabled.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2124604b
    • Daniel Vetter's avatar
      drm/i915/dp: convert to encoder disable/enable · e8cb4558
      Daniel Vetter authored
      DP is the first encoder which isn't simple. As
      
      commit d240f20f
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Fri Aug 13 15:43:26 2010 -0700
      
          drm/i915: make sure eDP PLL is enabled at the right time
      
      discovered, we need to enable the eDP PLL for the cpu port _before_ we
      enable the pipes and planes. After a few more commits the current
      solution is to enable the PLL in the dp mode_set function (because
      this is the only encoder callback the crtc helper code calls before it
      calls the crtc's commit function).
      
      Now I suspect that we actually should enable/disable the entire cpu
      eDP port before/after planes, but thanks to how the crtc helper code
      assumes that you can disable an encoder without disabling it's crtc
      right away, this won't work.
      
      The result is that the current prepare/commit hooks don't touch the
      eDP PLL, but instead it get's frobbed in dp_mode_set and in the dp
      dpms function. Hence we need to keep things (at least for now)
      bug-for-bug compatible by using our own special dp dpms function and
      keep everything else more-or-less as-is (just using our own
      infrastrucutre now).
      
      This mess can only be cleaned up once we control the entire modeset
      sequence and can move things around freely.
      
      v2: Squash unsupported dpms modes to OFF at the beginning of the DP
      dpms function.
      
      v3: Need to set the dpms state to off in dp_disable, otherwise this
      breaks the newly added WARNs ...
      
      v4: Rebased against edp panel off sequence changes in 3.6-rc2
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e8cb4558
    • Daniel Vetter's avatar
      drm/i915/lvds: convert to encoder disable/enable · c22834ec
      Daniel Vetter authored
      With the previous patch LVDS is also a simple case. Treat it
      accordingly.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c22834ec
    • Daniel Vetter's avatar
      drm/i915/tv: convert to encoder enable/disable · 6b5756a0
      Daniel Vetter authored
      Like hdmi tv outputs are simple: They only have 2 states and can't be
      cloned. Hence give it the same treatment.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6b5756a0
    • Daniel Vetter's avatar
      drm/i915/hdmi: convert to encoder->disable/enable · 5ab432ef
      Daniel Vetter authored
      I've picked hdmi as the first encoder to convert because it's rather
      simple:
      - no cloning possible
      - no differences between prepare/commit and dpms off/on switching.
      
      A few changes are required to do so:
      - Split up the dpms code into an enable/disable function and wire it
        up with the intel encoder.
      - Noop out the existing encoder prepare/commit functions used by the
        crtc helper - our crtc enable/disable code now calls back into the
        encoder enable/disable code at the right spot.
      - Create new helper functions to handle dpms changes.
      - Add intel_encoder->connectors_active to better track dpms state. Atm
        this is unused, but it will be useful to correctly disable the
        entire display pipe for cloned configurations. Also note that for
        now this is only useful in the dpms code - thanks to the crtc
        helper's dpms confusion across a modeset operation we can't (yet)
        rely on this having a sensible value in all circumstances.
      - Rip out the encoder helper dpms callback, if this is still getting
        called somewhere we have a bug. The slight issue with that is that
        the crtc helper abuses dpms off to disable unused functions. Hence
        we also need to implement a default encoder disable function to do
        just that with the new encoder->disable callback.
      - Note that we drop the cpt modeset verification in the commit
        callback, too. The right place to do this would be in the crtc's
        enable function, _after_ all the encoders are set up. But because
        not all encoders are converted yet, we can't do that. Hence disable
        this check temporarily as a minor concession to bisectability.
      
      v2: Squash the dpms mode to only the supported values -
      connector->dpms is for internal tracking only, we can hence avoid
      needless state-changes a bit whithout causing harm.
      
      v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5ab432ef
    • Daniel Vetter's avatar
      drm/i915: add direct encoder disable/enable infrastructure · ef9c3aee
      Daniel Vetter authored
      Just prep work, not yet put to some use.
      
      Note that because we're still using the crtc helper to switch modes
      (and their complicated way to do partial modesets), we need to call
      the encoder's disable function unconditionally.
      
      But once this is cleaned up we shouldn't call the encoder's disable
      function unconditionally any more, because then we know that we'll
      only call it if the encoder is actually enabled. Also note that we
      then need to be careful about which crtc we're filtering the encoder
      list on: We want to filter on the crtc of the _current_ mode, not the
      one we're about to set up.
      
      For the enabling side we need to do the same trick. And again, we
      should be able to simplify this quite a bit when things have settled
      into place.
      
      Also note that this simply does not take cloning into account, so dpms
      needs to be handled specially for the few outputs where we even bother
      with it.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ef9c3aee
    • Daniel Vetter's avatar
      drm/i915: rip out crtc prepare/commit indirection · eae307a5
      Daniel Vetter authored
      Just impendance matching with the the crtc helper stuff.
      
      ... and somehow the design of this all ended up in this commit here,
      too ;-)
      
      The big plan is that this new set of crtc display_funcs take full
      responsibility of modeset operations for the entire display output
      pipeline (by calling down into object-specific callbacks and
      functions). The platform-specific callbacks simply know best what the
      proper order is.
      
      This has the drawback that we can't do minimal change-overs any more
      if a modeset just disables one encoder in a cloned configuration
      (because we will only expose a disable/enable action that takes
      down/sets up the entire crtc including all encoders). Imo that's the
      only sane way to do it though:
      - The use-case for this is pretty minimal, even when presenting (at
        least sane people) should use a dual-screen output so that you can
        see your notes on your panel. Clone mode is imo BS.
      - With all the clone mode constrains, shared resources, and special
        ordering requirements (which differ even on the same platform
        sometimes for different outputs) there's no way we'd get this right
        for all cases. Especially since this is a under-used feature.
      - And to top it off: On haswell even dp link re-training requires us
        to take down the entire display pipe - otherwise the chip dies.
      
      So the only sane way is to do a full modeset on every crtc where the
      output config changes in any way.
      
      To support global modeset (i.e. set the configuration for all crtcs at
      once) we'd then add one more function to allocate global and shared
      objects in the best ways (e.g. fdi links, pch plls, ...). The crtc
      functions would then simply use the pre-allocated stuff (and shouldn't
      be able to fail, ever). We could even do all the object pinning in
      there (and maybe try to defragment the global gtt if we fail)!
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      eae307a5
    • Daniel Vetter's avatar
      drm/i915: add crtc->enable/disable vfuncs insted of dpms · 76e5a89c
      Daniel Vetter authored
      Because that's what we're essentially calling. This is the first step
      in untangling the crtc_helper induced dpms handling mess we have - at
      the crtc level we only have 2 states and the magic is just in
      selecting which one (and atm there isn't even much magic, but on
      recent platforms where not even the crt output has more than 2 states
      we could do better).
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      76e5a89c
  2. 17 Aug, 2012 2 commits