8 Commits

Author	SHA1	Message	Date
Rob Clark	dd275956aa	drm/atomic: add plane iterator macros ... Add helper macros to iterate the current, or incoming set of planes attached to a crtc. These helpers are only available for drivers converted to use atomic-helpers. Signed-off-by: Rob Clark <robdclark@gmail.com> [danvet: Squash in fixup from Rob to move the planemask iterator to drm_crtc.h and document it. That one is needed by the atomic ioctl so can't be in a helper library.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-27 15:39:09 +01:00
Thierry Reding	0254951d9c	drm: Make drm_atomic_helper.h standalone includible ... This header uses a bunch of declarations from the drm/drm_crtc.h header, so make sure to include that as well so that drm_atomic_helper.h can be included standalone. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-25 13:28:19 +01:00
Rob Clark	5ee3229c87	drm: export atomic wait_for_vblanks helper (v2) ... v1: original v2: danvet's kerneldoc nitpicks Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>	2014-11-12 17:55:44 +10:00
Daniel Vetter	d461701c55	drm/atomic-helpers: functions for state duplicate/destroy/reset ... The atomic users and helpers assume that there is always a obj->state structure around. Which means drivers need to somehow create that at driver load time. Also it should obviously reset hardware state, so needs to be reset upon resume. Finally the destroy/duplicate_state functions are an awful lot of boilerplate if the driver doesn't need anything beyond the default state objects. So add helper functions for all of this. v2: Somehow the plane/connector versions got lost in the first version. v3: Add kerneldoc. v4: Make duplicate_state functions a bit more robust, which is useful for debugging state tracking issues when transitioning to atomic. v5: Clear temporary variables in the crtc state when duplicating it, like ->mode_changed or ->planes_changed. If we don't do this stale values for these might pollute the next atomic modeset. v6: Also clear crtc_state->event in case the driver didn't (yet) clear this out. v7: Split out wrong squashed commit. Also improve the kerneldoc to mention that obj->state can be NULL and when. Both suggested by Daniel Thompson. Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-06 21:02:23 +01:00
Daniel Vetter	8bc0f3126c	drm/atomic-helper: implement ->page_flip ... Currently there is no way to implement async flips using atomic, that essentially requires us to be able to cancel pending requests mid-flight. To be able to do that (and I guess we want this since vblank synced updates which opportunistically cancel still pending updates seem to be wanted) we'd need to add a mandatory cancellation mode. Depending upon the exact semantics we decide upon that could mean that userspace will not get completion events, or will get them all stacked up. So reject async updates for now. Also async updates usually means not vblank synced at all, and I guess for drivers which want to support this they should simply add a special pageflip handler (since usually you need a special flip cmd to achieve this). That kind of async flip is pretty much exclusively just used for games and benchmarks where dropping just one frame means you'll get a headshot or something bad like that ... And so slight amounts of tearing is acceptable. v2: Fixup kerneldoc, reported by Paulo. v3: Use the set_crtc_for_plane function to assign the crtc, since otherwise the book-keeping is off. v4: Update crtc->primary->fb since ->page_flip is the only driver callback where the core won't do this itself. We might want to fix this inconsistency eventually. v5: Use set_crtc_for_connector as suggested by Sean. v6: Daniel Thompson noticed that my error handling is inconsistent and that in a few cases I didn't handle fatal errors (i.e. not -EDEADLK). Fix this by consolidate the ww mutex backoff handling into one check in the fail: block and flatten the error control flow everywhere else. v7: Fix spelling mistake in the commit message (Sean). Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-06 21:02:23 +01:00
Daniel Vetter	042652ed95	drm/atomic-helper: implementatations for legacy interfaces ... Well, except page_flip since that requires async commit, which isn't there yet. For the functions which changes planes there's a bit of trickery involved to keep the fb refcounting working. But otherwise fairly straight-forward atomic updates. The property setting functions are still a bit incomplete. Once we have generic properties (e.g. rotation, but also all the properties needed by the atomic ioctl) we need to filter those out and parse them in the helper. Preferrably with the same function as used by the real atomic ioctl implementation. v2: Fixup kerneldoc, reported by Paulo. v3: Add missing EXPORT_SYMBOL. v4: We need to look at the crtc of the modeset, not some random leftover one from a previous loop when udpating the connector->crtc routing. Also push some local variables into inner loops to avoid these kinds of bugs. v5: Adjust semantics - drivers now own the atomic state upon successfully synchronous commit. v6: Use the set_crtc_for_plane function to assign the crtc, since otherwise the book-keeping is off. v7: - Improve comments. - Filter out the crtc of the ->set_config call when recomputing crtc_state->enabled: We should compute the same state, but not doing so will give us a good chance to catch bugs and inconsistencies - the atomic helper's atomic_check function re-validates this again. - Fix the set_config implementation logic when disabling the crtc: We still need to update the output routing to disable all the connectors properly in the state. Caught by the atomic_check functions, so at least that part worked ;-) Also add some WARN_ONs to ensure ->set_config preconditions all apply. v8: Fixup an embarrassing h/vdisplay mixup. v9: Shuffled bad squash to the right patch, spotted by Daniel v10: Use set_crtc_for_connector as suggested by Sean. v11: Daniel Thompson noticed that my error handling is inconsistent and that in a few cases I didn't handle fatal errors (i.e. not -EDEADLK). Fix this by consolidate the ww mutex backoff handling into one check in the fail: block and flatten the error control flow everywhere else. v12: Review and discussion with Sean: - One spelling fix. - Correctly skip the crtc from the set_config set when recomputing ->enable state. That should allow us to catch any bugs in higher levels in computing that state (which is supplied to the ->set_config implementation). I've screwed this up and Sean spotted that the current code is pointless. Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-06 21:02:21 +01:00
Daniel Vetter	623369e533	drm: Atomic crtc/connector updates using crtc/plane helper interfaces ... So this is finally the integration of the crtc and plane helper interfaces into the atomic helper functions. In the check function we now have a few steps: - First we update the output routing and figure out which crtcs need a full mode set. Suitable encoders are selected using ->best_encoder, with the same semantics as the crtc helpers of implicitly disabling all connectors currently using the encoder. - Then we pull all other connectors into the state update which feed from a crtc which changes. This must be done do catch mode changes and similar updates - atomic updates are differences on top of the current state. - Then we call all the various ->mode_fixup to compute the adjusted mode. Note that here we have a slight semantic difference compared to the crtc helpers: We have not yet updated the encoder->crtc link when calling the encoder's ->mode_fixup function. But that's a requirement when converting to atomic since we want to prepare the entire state completely contained with the over drm_atomic_state structure. So this must be carefully checked when converting drivers over to atomic helpers. - Finally we do call the atomic_check functions on planes and crtcs. The commit function is also quite a beast: - The only step that can fail is done first, namely pinning the framebuffers. After that we cross the point of no return, an async commit would push all that into the worker thread. - The disabling of encoders and connectors is a bit tricky, since depending upon the final state we need to select different crtc helper functions. - Software tracking is a bit clarified compared to the crtc helpers: We commit the software state before starting to touch the hardware, like crtc helpers. But since we just swap them we still have the old state (i.e. the current hw state) around, which is really handy to write simple disable functions. So no more drm_crtc_helper_disable_all_unused_functions kind of fun because we're leaving unused crtcs/encoders behind. Everything gets shut down in-order now, which is one of the key differences of the i915 helpers compared to crtc helpers and a really nice additional guarantee. - Like with the plane helpers the atomic commit function waits for one vblank to pass before calling the framebuffer cleanup function. Compared to Rob's helper approach there's a bunch of upsides: - All the interfaces which can fail are called in the ->check hook (i.e. ->best_match and the various ->mode_fixup hooks). This means that drivers can just reuse those functions and don't need to move everything into ->atomic_check callbacks. If drivers have no need for additional constraint checking beyong their existing crtc helper callbacks they don't need to do anything. - The actual commit operation is properly stage: First we prepare framebuffers, which can potentially still fail (due to memory exhausting). This is important for the async case, where this must be done synchronously to correctly return errors. - The output configuration changes (done with crtc helper functions) and the plane update (using atomic plane helpers) are correctly interleaved: First we shut down any crtcs that need changing, then we update planes and finally we enable everything again. Hardware without GO bits must be more careful with ordering, which this sequence enables. - Also for hardware with shared output resources (like display PLLs) we first must shut down the old configuration before we can enable the new one. Otherwise we can hit an impossible intermediate state where there's not enough PLLs (which is the point behind atomic updates). v2: - Ensure that users of ->check update crtc_state->enable correctly. - Update the legacy state in crtc/plane structures. Eventually we want to remove that, but for now the drm core still expects this (especially the plane->fb pointer). v3: A few changes for better async handling: - Reorder the software side state commit so that it happens all before we touch the hardware. This way async support becomes very easy since we can punt all the actual hw touching to a worker thread. And as long as we synchronize with that thread (flushing or cancelling, depending upon what the driver can handle) before we commit the next software state there's no need for any locking in the worker thread at all. Which greatly simplifies things. And as long as we synchronize with all relevant threads we can have a lot of them (e.g. per-crtc for per-crtc updates) running in parallel. - Expose pre/post plane commit steps separately. We need to expose the actual hw commit step anyway for drivers to be able to implement asynchronous commit workers. But if we expose pre/post and plane commit steps individually we allow drivers to selectively use atomic helpers. - I've forgotten to call encoder/bridge ->mode_set functions, fix this. v4: Add debug output and fix a mixup between current and new state that resulted in crtcs not getting updated correctly. And in an Oops ... v5: - Be kind to driver writers in the vblank wait functions.. if thing aren't working yet, and vblank irq will never come, then let's not block forever.. especially under console-lock. - Correctly clear connector_state->best_encoder when disabling. Spotted while trying to understand a report from Rob Clark. - Only steal encoder if it actually changed, otherwise hilarity ensues if we steal from the current connector and so set the ->crtc pointer unexpectedly to NULL. Reported by Rob Clark. - Bail out in disable_outputs if an output currently doesn't have a best_encoder - this means it's already disabled. v6: Fixupe kerneldoc as reported by Paulo. And also fix up kerneldoc in drm_crtc.h. v7: Take ownership of the atomic state and clean it up with drm_atomic_state_free(). v8 Various improvements all over: - Polish code comments and kerneldoc. - Improve debug output to make sure all failure cases are logged. - Treat enabled crtc with no connectors as invalid input from userspace. - Don't ignore the return value from mode_fixup(). v9: - Improve debug output for crtc_state->mode_changed. v10: - Fixup the vblank waiting code to properly balance the vblank_get/put calls. - Better comments when checking/computing crtc->mode_changed v11: Fixup the encoder stealing logic: We can't look at encoder->crtc since that's not in the atomic state structures and might be updated asynchronously in and async commit. Instead we need to inspect all the connector states and check whether the encoder is currently in used and if so, on which crtc. v12: Review from Sean: - A few spelling fixes. - Flatten control flow indent by converting if blocks to early continue/return in 2 places. - Capture connectors_for_crtc return value in int num_connectors instead of bool has_connectors and do an explicit int->bool conversion with !!. I think the helper is more useful for drivers if it returns the number of connectors (e.g. to detect cloning configurations), so decided to keep that return value. Cc: Sean Paul <seanpaul@chromium.org> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-06 21:02:14 +01:00
Daniel Vetter	c2fcd274bc	drm: Add atomic/plane helpers ... This is the first cut of atomic helper code. As-is it's only useful to implement a pure atomic interface for plane updates. Later patches will integrate this with the crtc helpers so that full atomic updates are possible. We also need a pile of helpers to aid drivers in transitioning from the legacy world to the shiny new atomic age. Finally we need helpers to implement legacy ioctls on top of the atomic interface. The design of the overall helpers<->driver interaction is fairly simple, but has an unfortunate large interface: - We have ->atomic_check callbacks for crtcs and planes. The idea is that connectors don't need any checking, and if they do they can adjust the relevant crtc driver-private state. So no connector hooks should be needed. Also the crtc helpers integration will do the ->best_encoder checks, so no need for that. - Framebuffer pinning needs to be done before we can commit to the hw state. This is especially important for async updates where we must pin all buffers before returning to userspace, so that really only hw failures can happen in the asynchronous worker. Hence we add ->prepare_fb and ->cleanup_fb hooks for this resources management. - The actual atomic plane commit can't fail (except hw woes), so has void return type. It has three stages: 1. Prepare all affected crtcs with crtc->atomic_begin. Drivers can use this to unset the GO bit or similar latches to prevent plane updates. 2. Update plane state by looping over all changed planes and calling plane->atomic_update. Presuming the hardware is sane and has GO bits drivers can simply bash the state into the hardware in this function. Other drivers might use this to precompute hw state for the final step. 3. Finally latch the update for the next vblank with crtc->atomic_flush. Note that this function doesn't need to wait for the vblank to happen even for the synchronous case. v2: Clear drm_<obj>_state->state to NULL when swapping in state. v3: Add TODO that we don't short-circuit plane updates for now. Likely no one will care. v4: Squash in a bit of polish that somehow landed in the wrong (later) patche. v5: Integrate atomic functions into the drm docbook and fixup the kerneldoc. v6: Fixup fixup patch squashing fumble. v7: Don't touch the legacy plane state plane->fb and plane->crtc. This is only used by the legacy ioctl code in the drm core, and that code already takes care of updating the pointers in all relevant cases. This is in stark contrast to connector->encoder->crtc links on the modeset side, which we still need to set since the core doesn't touch them. Also some more kerneldoc polish. v8: Drop outdated comment. v9: Handle the state->state pointer correctly: Only clearing the ->state pointer when assigning the state to the kms object isn't good enough. We also need to re-link the swapped out state into the drm_atomic_state structure. v10: Shuffle the misplaced docbook template hunk around that Sean spotted. Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>	2014-11-05 18:07:01 +01:00