1. 06 Sep, 2012 40 commits
    • Daniel Vetter's avatar
      drm/i915: disable all crtcs at suspend time · a261b246
      Daniel Vetter authored
      We need this to avoid confusing the hw state readout code with the cpt
      pch plls at resume time: We'd read the new pipe state (which is
      disabled), but still believe that we have a life pll connected to that
      pipe (from before the suspend). Hence properly disable pipes to clear
      out all the residual state.
      
      This has the neat side-effect that we don't enable ports prematurely
      by restoring bogus state from the saved register values.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a261b246
    • Daniel Vetter's avatar
      drm/i915: push commit_output_state past the crtc/encoder preparing · ea9d758d
      Daniel Vetter authored
      With this change we can (finally!) rip out a few of the temporary hacks
      and clean up a few other things:
      - Kill intel_crtc_prepare_encoders, now unused.
      - Kill the hacks in the crtc_disable/enable functions to always call the
        encoder callbacks, we now always call the crtc functions with the right
        encoder -> crtc links.
      - Also push down the crtc->enable, encoder and connector dpms state
        updates. Unfortunately we can't add a WARN in the crtc_disable
        callbacks to ensure that the crtc is always still enabled when
        disabling an output pipe - the crtc sanitizer of the hw readout path
        can hit this when it needs to disable an active pipe without any
        enabled outputs.
      - Only call crtc->disable if the pipe is already enabled - again avoids
        running afoul of the new WARN.
      
      v2: Copy&paste our own version of crtc_in_use, too.
      
      v3: We need to update the dpms an encoder->connectors_active states,
      too.
      
      v4: I've forgotten to kill the unconditional encoder->disable calls in
      the crtc_disable functions.
      
      v5: Rip out leftover debug printk.
      
      v6: Properly clear intel_encoder->connectors_active. This wasn't
      properly cleared when disabling an encoder because it was no longer on
      the new connector list, but the crtc was still enabled (i.e. switching
      the encoder of an active crtc). Reported by Jani Nikula.
      
      v7: Don't clobber the encoder->connectors_active state of untouched
      encoders. Since X likes to first disable all outputs with dpms off
      before setting a new framebuffer, this hit a few warnings. Reported by
      Paulo Zanoni.
      
      v8: Kill the now stale comment warning that intel_crtc->active is not
      always updated at the right times.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ea9d758d
    • Daniel Vetter's avatar
      drm/i915: switch the load detect code to the staged modeset config · fc303101
      Daniel Vetter authored
      Now that set_mode also disables crtcs and expects it's new
      configuration in the staged output links we need to adjust the load
      detect code a bit.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fc303101
    • Daniel Vetter's avatar
      drm/i915: WARN if the pipe won't turn off · 284637d9
      Daniel Vetter authored
      This seems to be the symptom of a few neat bugs, hence be more
      obnoxious when this fails.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      284637d9
    • Daniel Vetter's avatar
      drm/i915: s/intel_encoder_disable/intel_encoder_noop · 1f703855
      Daniel Vetter authored
      Because that's what it is. Unfortunately we can't rip this out because
      the fb helper has an incetious relationship with the crtc helper - it
      likes to call disable_unused_functions, among other things.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1f703855
    • Daniel Vetter's avatar
      drm/i915: push commit_output_state past crtc disabling · 976f8a20
      Daniel Vetter authored
      This requires a few changes
      - We still need a noop function for crtc->disable, becuase the fb
        helper is a bit too intimate with the crtc helper.
      - We need to clear crtc->fb ourselves in intel_crtc_disable now that
        we no longer rely on the helper's disable_unused_functions to do
        that.
      - We need to split out the sare update code, becuase the crtc code
        can't call update_dpms any more, it needs to disable the crtc
        unconditionally. This is because we now keep onto the encoder ->
        crtc mapping of the (still) active output pipe configuration.
      - To check that we really disable a crtc that still has encoders,
        insert a WARN_ON(!enabled) in the crtc disable function.
      - Lastly, we need to walk over all crtcs to update their enabled state
        after having called commit_output_state - for all disabled crtcs the
        crtc helper code has done that for us previously.
      
      v2: Update connector dpms and encoder->connectors_active after
      disabling the crtc, too.
      
      v3: Noop-out intel_encoder_disable. Similarly to the crtc disable
      callback used by the crtc helper code we can't simply remove all these
      encoder callbacks: The fb helper (which we still use) has a rather
      incetious relationship with the crtc helper code ...
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      976f8a20
    • Daniel Vetter's avatar
      drm/i915: implement new set_mode code flow · 25c5b266
      Daniel Vetter authored
      ... using the pipe masks from the previous patch.
      
      Well, not quite:
      - We still need to call the disable_unused_functions helper, until
        we've moved the call to commit_output_state further down and
        adjusted intel_crtc_disable a bit. The next patch will do that.
      - Because we don't support (yet) mode changes on more than one crtc at
        a time, some of the modeset_pipes checks are a bit hackish - but
        that only needs fixing once we incorporate global modeset support.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      25c5b266
    • Daniel Vetter's avatar
      drm/i915: compute masks of crtcs affected in set_mode · e2e1ed41
      Daniel Vetter authored
      This is definetely a bit more generic than currently required, but if
      we keep track of all crtcs that need to be disabled/enable (because
      they loose an encoder or something similar), crtcs that get completely
      disabled and those that we need to do an actual mode change nicely
      prepares us for global modeset operations on multiple crtcs.
      
      The only big thing missing here would be a global resource allocation
      step (for e.g. pch plls), which would equally frob these bitmasks if
      e.g. a crtc only needs a new pll. Or if we need to enable dithering on
      an another pipe due to bandwidth constrains somewhere.
      
      These masks aren't yet put to use in this patch, this will follow in the
      next one.
      
      v2-v5: Fix up the computations for good (hopefully).
      
      v6: Fixup a confusion reported by Damien Lespiau: I've conserved the
      (imo braindead) behaviour of the crtc helper to disable _any_
      disconnected outputs if we do a modeset, even when that newly disabled
      connector isn't connected to the crtc being changed by the modeset.
      
      The effect of that is that we could disable an arbitrary number of
      unrelated crtcs, which I haven't taken into account when writing this
      code. Fix this up.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e2e1ed41
    • Daniel Vetter's avatar
      drm/i915: use staged outuput config in lvds->mode_fixup · e24c5c29
      Daniel Vetter authored
      - Use the check_cloned helper from the previous patch.
      - Use encoder->new_crtc to check crtc properties.
      
      v2: Kill the double negation with s/!non_cloned/is_cloned, suggested
      by Jesse Barnes.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e24c5c29
    • Daniel Vetter's avatar
      drm/i915: use staged outuput config in tv->mode_fixup · 6ed0f796
      Daniel Vetter authored
      The "is this encoder cloned" check will be reused by the lvds encoder,
      hence exract it.
      
      v2: Be a bit more careful about that we need to check the new, staged
      ouput configuration in the check_non_cloned helper ...
      
      v3: Kill the double negation with s/!non_cloned/is_cloned/, suggested
      by Jesse Barnes.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6ed0f796
    • Daniel Vetter's avatar
      drm/i915: extract adjusted mode computation · 7758a113
      Daniel Vetter authored
      While at it, adjust a few things:
      - Only assigng the new mode to crtc->mode right before calling the
        mode_set callbacks - none of the previous callbacks depend upon
        this, they all use the mode argument (as they should).
      - Check encoder->new_crtc instead of the current crtc to check whether
        the encoder will be used. This prepares for moving the staged output
        committing further down in the sequence. Follow-on patches will fix
        up individual ->mode_fixup callbacks (only tv and lvds are affected
        though).
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7758a113
    • Daniel Vetter's avatar
      drm/i915: move output commit and crtc disabling into set_mode · 87f1faa6
      Daniel Vetter authored
      It's rather pointless to compute crtc->enabled twice right away ;-)
      
      The only thing we really have to be careful about is that we frob the
      dpms state only after a successful modeset and when we've actually
      haven't just disabled the crtc.
      
      Hooray for convoluted interfaces ...
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      87f1faa6
    • Daniel Vetter's avatar
      drm/i915: remove crtc disabling special case · ba1c28c9
      Daniel Vetter authored
      Originally this has been introduced in
      
      commit 6eebd6bb
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Nov 28 21:10:05 2011 +0000
      
          drm: Fix lack of CRTC disable for drm_crtc_helper_set_config(.fb=NULL)
      
      With the improvements of the output state staging and no longer
      overwriting crtc->fb before the hw state is updated we can now handle
      crtc disabling as part of the normal modeset sequence.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ba1c28c9
    • Daniel Vetter's avatar
      drm/i915: push crtc->fb update into pipe_set_base · 94352cf9
      Daniel Vetter authored
      Passing in the old fb, having overwritten the current fb, leads to
      some neatly convoluted code. It's much simpler if we defer the
      crtc->fb update to the place that updates the hw, in pipe_set_base.
      This way we also don't need to restore anything in case something
      fails - we only update crtc->fb once things have succeeded.
      
      The real reason for this change is that now we keep the old fb
      assigned to crtc->fb, which allows us to finally move the crtc disable
      case into the common low-level set_mode function in the next patch.
      
      Also don't clobber crtc->x and crtc->y, we neatly pass these down the
      callchain already. Unfortunately we can't do the same with crtc->mode,
      because that one is being used in the mode_set callbacks.
      
      v2: Don't restore the drm_crtc object any more on failed modesets,
      since we've lose an fb reference otherwise. Also (and this is the
      reason this has been found), this totally confused the modeset state
      tracking, since it clobbers crtc->enabled. Issue reported by Paulo
      Zanoni.
      
      v3: Rip out the entire crtc saving into struct intel_set_config, not
      just the restoring part.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      94352cf9
    • Daniel Vetter's avatar
      drm/i915: stage modeset output changes · 9a935856
      Daniel Vetter authored
      This is the core of the new modeset logic.
      
      The current code which is based upon the crtc helper code first
      updates all the link of the new display pipeline and then calls the
      lower-level set_mode function to execute the required callbacks to get
      there. The issue with this approach is that for disabling we need to
      know the _current_ display pipe state, not the new one.
      
      Hence we need to stage the new state of the display pipe and only
      update it once we have disabled the current configuration and before we
      start to update the hw registers with the new configuration.
      
      This patch here just prepares the ground by switching the new output
      state computation to these staging pointers. To make it clearer,
      rename the old update_output_state function to stage_output_state.
      
      A few peculiarities:
      - We're also calling the set_mode function at various places to update
        properties. Hence after a successfule modeset we need to stage the
        current configuration (for otherwise we might fall back again). This
        happens automatically because as part of the (successful) modeset we
        need to copy the staged state to the real one. But for the hw
        readout code we need to make sure that this happens, too.
      - Teach the new staged output state computation code the required
        smarts to handle the disabling of outputs. The current code handles
        this in a special case, but to better handle global modeset changes
        covering more than one crtc, we want to do this all in the same
        low-level modeset code.
      - The actual modeset code is still a bit ugly and wants to know the new
        crtc->enabled state a bit early. Follow-on patches will clean that
        up, for now we have to apply the staged output configuration early,
        outside of the set_mode functions.
      - Improve/add comments in stage_output_state.
      
      Essentially all that is left to do now is move the disabling code into
      set_mode and then move the staged state update code also into
      set_mode, at the right place between disabling things and calling the
      mode_set callbacks for the new configuration.
      
      v2: Disabling a crtc works by passing in a NULL mode or fb, userspace
      doesn't hand in the list of connectors. We therefore need to detect
      this case manually and tear down all the output links.
      
      v3: Properly update the output staging pointers after having read out
      the hw state.
      
      v4: Simplify the code, add more DRM_DEBUG_KMS output and check a few
      assumptions with WARN_ON. Essentially all things that I've noticed
      while debugging issues in other places of the code.
      
      v4: Correctly disable the old set of connectors when enabling an
      already enabled crtc on a new set of crtc. Reported by Paulo Zanoni.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9a935856
    • Daniel Vetter's avatar
      drm/i915: don't save all the encoder/crtc state in set_config · 1aa4b628
      Daniel Vetter authored
      We actually only touch the connector -> encoder and encoder -> crtc
      linking. So it's enough to just save/restore that.
      
      While at it, also switch to kcalloc to allocate these arrays (omission
      in the commit message spotted by Jesse Barnes).
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1aa4b628
    • Daniel Vetter's avatar
      drm/i915: convert pointless error checks in set_config to BUGs · 8d3e375e
      Daniel Vetter authored
      Because they all are, the ioctl command never calls us with any of
      these violated. Also drop a equally pointless empty debug message (and
      also in set_cursor, while we're at it).
      
      With all these changes, intel_crtc_set_config is neatly condensed down
      to it's essence, the actual modeset code (or fb update calling code)
      
      v2: The fb helper code is actually stretching ->set_config semantics a bit,
      it calls it with set->mode == NULL but set->fb != NULL.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8d3e375e
    • Daniel Vetter's avatar
      drm/i915: don't update the fb base if there is no fb · 835c5873
      Daniel Vetter authored
      Otherwise we'll set_fb complains pretty loudly if we the crtc is off
      and userspace moves the NULL fb around a bit. Yeah, this actually
      happens in the wild ...
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      835c5873
    • Daniel Vetter's avatar
      drm/i915: implement crtc helper semantics relied upon by the fb helper · 431e50f7
      Daniel Vetter authored
      Yikes!
      
      But yeah, we have to do this until someone volunteers to clean up the
      fb helper and rid it of its incetious relationship with the crtc
      helper code.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      431e50f7
    • 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