1. 02 Oct, 2012 2 commits
  2. 20 Sep, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: add encoder->pre_enable/post_disable · bf49ec8c
      Daniel Vetter authored
      The cpu eDP encoder has some horrible hacks to set up the DP pll at
      the right time. To be able to move them to the right place, add some
      more encoder callbacks so that this can happen at the right time.
      LVDS has some similar funky hacks, but that would require more work
      (we need to move around the pll setup a bit). Hence for now only
      wire these new callbacks up for ilk+ - we only have cpu eDP on these
      v2: Bikeshed the vtable ordering, requested by Chris Wilson.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  3. 06 Sep, 2012 12 commits
    • Daniel Vetter's avatar
      drm/i915: improve modeset state checking after dpms calls · b980514c
      Daniel Vetter authored
      Now that we have solid modeset state tracking and checking code in
      place, we can do the Full Monty also after dpms calls.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • 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>
    • 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,
      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>
    • 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>
    • 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>
    • 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
      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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
  4. 05 Sep, 2012 10 commits
    • 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>
    • Daniel Vetter's avatar
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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
      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>
    • 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
      - 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>
    • 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>
  5. 03 Sep, 2012 1 commit
    • Ben Widawsky's avatar
      drm/i915: use cpu_relax() in wait_for_atomic · 0cc2764c
      Ben Widawsky authored
      As part of the advice given to us from the hardware designers regarding
      the maximum wait time on the forcewake handshake we need to move from us
      granularity to ms granularity. In earlier patches to do this, Jani
      noticed that wait_for_us was properly converted to use cpu_relax(), but
      wait_for was not.
      The issue has existed since the introduction of the macro:
      commit 913d8d11
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Sat Aug 7 11:01:35 2010 +0100
          drm/i915: Ensure that while(INREG()) are bounded (v2)
      CC: Jani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.oc.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  6. 17 Aug, 2012 2 commits
  7. 06 Aug, 2012 2 commits
  8. 26 Jul, 2012 1 commit
  9. 25 Jul, 2012 5 commits
    • Chris Wilson's avatar
      drm/i915: Avoid concurrent access when marking the device as idle/busy · f047e395
      Chris Wilson authored
      As suggested by Daniel, rip out the independent timers for device and
      crtc busyness and integrate the manual powermanagement of the display
      engine into the GEM core and its request tracking. The benefits are that
      the code is a lot smaller, fewer moving parts and should fit more neatly
      into the overall activity tracking of the driver.
      v2: Complete overhaul and removal of the racy timers and workers.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Paulo Zanoni's avatar
      drm/i915: add port field to struct intel_dp and use it · ab9d7c30
      Paulo Zanoni authored
      This will be needed for Haswell, but already has its uses here.
      This patch started as a small patch written patch by Shobhit Kumar,
      but it has changed so much that none of its original lines remain.
      Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: add port parameter to intel_hdmi_init · 08d644ad
      Daniel Vetter authored
      Instead of having a giant if cascade to figure this out according to
      the passed-in register. We could do quite a bit more cleaning up and
      all by using the port at more places, but I think this should be part
      of a bigger rework to introduce a struct intel_digital_port which
      would keep track of all these things. I guess this will be part of
      some haswell-DP-induced refactoring.
      For now this rips out the big cascade, which is what annoyed me so
      v2: Add port variable name back for the func decl (I've tried to trick
      myself below the 80 char limit).
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: simplify possible_clones computation · 66a9278e
      Daniel Vetter authored
      Intel hw only has one MUX for encoders, so outputs are either not
      cloneable or all in the same group of cloneable outputs. This neatly
      simplifies the code and allows us to ditch some ugly if cascades in
      the dp and hdmi init code (well, we need these if cascades for other
      stuff still, but that can be taken care of in follow-up patches).
      Note that this changes two things:
      - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is
        gen3+, so no problem. Note that the old code had a bug and didn't
        allow cloning crt with dvo (but only the other way round).
      - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't
        work, but the only reason I've found is that you can't use the
        panel-fitter (used for lvds upscaling) with anything else. But we
        don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is
        a) rather confusing b) mostly as a guideline to implementors (i.e.
        explicitly stating what is already implicit from the spec, without
        always going into the details of why). So I think we can ignore this
        - worst case we'll get a bug report from a user with with sdvo-lvds
        and sdvo-tmds and have to add that special case back in.
      Because sdvo lvds is a bit special explain in comments why sdvo LVDS
      outputs can be cloned, but native LVDS and eDP can't be cloned - we
      use the panel fitter for the later, but not for sdvo.
      Note that this also uncoditionally initializes the panel_vdd work used
      by eDP. Trying to be clever doesn't buy us anything (but strange bugs)
      and this way we can kill the is_edp check.
      v2: Incorporate review from Paulo
      - Add in a missing space.
      - Pimp comment message to address his concerns.
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Shobhit Kumar's avatar
      drm/i915: Move DP structs to shared location · 54d63ca6
      Shobhit Kumar authored
      Move the DP structure to shared location so that it can be used from
      within the ddi module.
      Changes from Paulo:
      - Move less code to intel_drv.h
      - Remove #include statement
      - Replace a tab with a space in train_set
      Signed-off-by: default avatarShobhit Kumar <shobhit.kumar@intel.com>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  10. 20 Jul, 2012 2 commits
  11. 05 Jul, 2012 2 commits
    • Daniel Vetter's avatar
      drm/i915: introduce crtc->dspaddr_offset · e506a0c6
      Daniel Vetter authored
      To avoid recomputing the display framebuffer offset on gen2/3
      pageflips. This is also prep work to do similar trickery on gen4+
      - kill "Start", such upper-case remnants from the ddx must surely die.
      - rename "Offset" to linear_offset, to make it clearer that on gen4+
        this is only used by the hw for linear buffers, for tiled buffers it
        uses the TILEOFF register.
      - call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because
        the documentation really renamed the register).
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: fix up ilk rc6 disabling confusion · 930ebb46
      Daniel Vetter authored
      While creating the new enable/disable_gt_powersave functions in
      commit 8090c6b9
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun Jun 24 16:42:32 2012 +0200
          drm/i915: wrap up gt powersave enabling functions
      I've botched up the handling of ironlake_disable_rc6. Fix this up by
      calling it at the right place. Note though that ironlake_disable_rc6
      does a bit more than just disabling rc6 - it also tears down all the
      allocated context objects.
      Hence we need to move intel_teardown_rc6 out and directly call it from
      Also properly mark ironlake_enable_rc6 as static and kill the un-used
      declaration in i915_drv.h.
      Note: In review a question popped out why disable_rc6 also tears down
      the backing object and why we should move that out - it's simply for
      consistency with gen6+ rps code, which does it that way.
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>