- 06 Sep, 2012 40 commits
-
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
Reviewed-by:
-
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:
-
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:
-
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:
-
Daniel Vetter authored
Instead of going through the crtc helper function tables. Reviewed-by:
-
Daniel Vetter authored
With the new infrastructure we're doing this when enabling/disabling the entire display pipe. Reviewed-by:
-
Daniel Vetter authored
- We don't have the ->get_crtc callback. - Call intel_encoder->disable directly. Reviewed-by:
-
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:
-
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:
-
Daniel Vetter authored
And drop the check, we always have it. Reviewed-by:
-
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:
-
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:
-
Daniel Vetter authored
All encoders are now converted so there's no need for these checks any more. Reviewed-by:
-
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:
-
Daniel Vetter authored
Similar to the sdvo conversion. Reviewed-by:
-
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:
-
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:
-
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:
-
Daniel Vetter authored
With the previous patch LVDS is also a simple case. Treat it accordingly. Reviewed-by:
-
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:
-
