- 06 Sep, 2012 28 commits
-
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
-
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:
-
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:
-
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:
-
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:
-
- 17 Aug, 2012 12 commits
-
-
Wang Xingchao authored
Added new haswell_write_eld() to initialize Haswell HDMI audio registers to generate an unsolicited response to the audio controller driver to indicate that the controller sequence should start. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Wang Xingchao <xingchao.wang@intel.com> Signed-off-by:
-
Dave Airlie authored
We need to call these before we transfer the damaged areas to the device not before/after we setup the long lived vmaps. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
In order for udl vmap to work properly, we need to push the object into the CPU domain before we start copying the data to the USB device. This along with the udl change avoids userspace explicit mapping to be used. v2: add a flag for userspace to query to know if Intel kernel driver can deal with the vmap flushing properly. In theory udl would need a flag also, but I intend to push the patches very close to each other and other drivers should do the right thing from the start. I've added a test to my intel-gpu-tools prime branch, however testing this is a bit messy since the only way to get udl to vmap is to rendering something. I've tested this with real code as well to make sure it works. Signed-off-by:
-
Keith Packard authored
This is left over from the old PLL sharing code and isn't useful now that PLLs are shared when possible. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Damien Lespiau authored
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the for_each_pipe() macro and make struct intel_display_error_state is big enough. V2: Also add the number of pipes emitted (Chris Wilson) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder->crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way anyway. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder->crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Acked-by:
Dave Airlie <airlied@gmail.com> Signed-Off-by:
-
Wang Xingchao authored
Use _PIPE macro to get correct register definition for IBX/CPT, discard old variable "i" way. Signed-off-by:
-
Wang Xingchao authored
HDMI audio related registers will be configured in write_eld callback. Signed-off-by:
-
Wang Xingchao authored
Add hsw audio registers definition Signed-off-by:
-
Daniel Vetter authored
Simply to make the ilk+ crtc disable path clearer and more symmetric with the enable function. Also switch to intel_crtc for the enable function. Reviewed-by:
-
Daniel Vetter authored
... and move a few others only used by i915_dma.c into the dri1 dungeon. Reviewed-by:
-
Daniel Vetter authored
All dvo drivers only support 2 dpms states, and our dvo driver even switches of the dvo port for anything else than DPMS_ON. Hence ditch this complexity and simply use bool enable. While reading through this code I've noticed that the mode_set function of ch7017 is a bit peculiar - it disable the lvds again, even though the crtc helper code should have done that ... This might be to work around an issue at driver load, we pretty much ignore the hw state when taking over. v2: Also do the conversion for the new ns2501 driver. Reviewed-by:
-
