- 10 Nov, 2014 1 commit
-
-
Dave Airlie authored
These two didn't get documented properly, do so. Pointed out by Daniel. v1.1: add missing boilerplate (Daniel) Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 09 Nov, 2014 1 commit
-
-
Dave Airlie authored
Merge tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel into drm-next So here's my atomic series, finally all debugged&reviewed. Sean Paul has done a full detailed pass over it all, and a lot of other people have commented and provided feedback on some parts. Rob Clark also converted msm over the w/e and seems happy. The only small thing is that Rob wants to export the wait_for_vblank, which imo makes sense. Since there's other stuff still to do I think we should apply Rob's patch (once it has grown appropriate kerneldoc) later on top of this. This is just the core<->driver interface plus a big pile of helpers. Short recap of the main ideas: - There are essentially three helper libraries in this patch set: * Transitional helpers to use the new plane callbacks for legacy plane updates and in the crtc helper's ->mode_set callback. These helpers are only temporarily used to convert drivers to atomic, but they allow a nice separation between changing the driver backend and switching to the atomic commit logic. * Legacy helpers to implement all the legacy driver entry points (page_flip, set_config, plane vfuncs) on top of the new atomic driver interface. These are completely driver agnostic. The reason for having the legacy support as helpers is that drivers can switch step-by-step. And they could e.g. even keep the legacy page_flip code around for some old platforms where converting to full-blown atomic isn't worth it. * Atomic helpers which implement the various new ->atomic_* driver interfaces in terms of the revised crtc helper and new plane helper hooks. - The revised crtc helper implemenation essentially implements all the lessons learned in the i915 modeset rework (when using the atomic helpers only): * Enable/disable sequence for a given config are always the same and callbacks are always called in the same order. This contrast starkly with the crtc helpers, where the sequence of operations is heavily dependent on the previous config. One corollary of this is that if the configuration of a crtc only partially changes (e.g. a connector moves in a cloned config) the helper code will still disable/enable the full display pipeline. This is the only way to ensure that the enable/disable sequence is always the same. * It won't call disable or enable hooks more than once any more because it lost track of state, thanks to the atomic state tracking. And if drivers implement the ->reset hook properly (by either resetting the hw or reading out the hw state into the atomic structures) this even extends to the hardware state. So no more disable-me-harder kind of nonsense. * The only thing missing is the hw state readout/cross-check support, but if drivers have hw state readout support in their ->reset handlers it's simple to extend that to cross-check the hw state. * The crtc->mode_set callback is gone and its replacement only sets crtc timings and no longer updates the primary plane state. This way we can finally implement primary planes properly. - The new plane helpers should be suitable enough for pretty much everything, and a perfect fit for hardware with GO bits. Even if they don't fit the atomic helper library is rather flexible and exports all the functions for the individual steps to drivers. So drivers can pick what matches and implement their own magic for everything else. - A big difference compared to all previous atomic series is that this one doesn't implement async commit in a generic way. Imo driver requirements for that are too diverse to create anything reasonable sane which would actually work on a reasonable amount of different drivers. Also, we've never had a helper library for page_flips even, so it's really hard to know what might work and what's stupid without a bit of experience in the form of a few driver implementations. I think with the current flexibility for drivers to pick individual stages and existing helpers like drm_flip_queue it's rather easy though to implement proper async commit. - There's a few other differences of minor importance to earlier atomic series: * Common/generic properties are parsed in the callers/core and not in drivers, and passed to drivers by directly setting the right members in atomic state structures. That greatly simplifies all the transitional and legacy helpers an removes a lot of boilerplate code. * There's no crazy trylock mode used for the async commit since these helpers don't do async commit. A simple ordered flip queue of atomic state updates should be sufficient for preventing concurrent hw access anyway, as long as synchronous updates stall correctly with e.g. flush_work_queue or similar function. Abusing locks to enforce ordering isn't a good idea imo anyway. * These helpers reuse the existing ->mode_fixup hooks in the atomic_check callback. Which means that drivers need to adapat and move a lot less code into their atomic_check callbacks. Now this isn't everything needed in the drm core and helpers for full atomic support. But it's enough to start with converting drivers, and except for actually testing multiplane and multicrtc updates also enough to implement full atomic updates. Still missing are: - Per-plane locking. Since these helpers here encapsulate the locking completely this should be fairly easy to implement. - fbdev support for atomic_check/commit, so that multi-pipe finally works sanely in fbcon. - Adding and decoding shared/core properties. That just needs to be rebased from Rob's latest patch series, with minor adjustments so that the decoding happens in the core instead of in drivers. - Actually adding the atomic ioctl. Again just rebasing Rob's latest patch should be all that's needed. - Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up the crazy semantics dpms currently has. I'm floating an RFC about this topic already. - Finally I couldn't test connector/encoder stealing properly since my test vehicle here doesn't allow a connector on different crtcs. So drivers which support this might see some surprises in that area. There is no semantic change though in how encoder stealing and assignment works (or at least no intended one), so I think the risk is minimal. As just mentioned I've done a fake conversion of an existing driver using crtc helpers to debug the helper code and validate the smooth transition approach. And that smooth transition was the really big motivation for this. It seems to actually work and consists of 3 phases: Phase 1: Rework driver backend for crtc/plane helpers The requirement here is that universal plane support is already implement. If universal plane support isn't implement yet it might be better though to just do it as part of this phase, directly using the new plane helpers. There are two big things to do: - Split up the existing ->update/disable_plane hooks into check/commit hooks and extract the crtc-wide prep/flush parts (like setting/clearing GO bits). - The other big change is to split the crtc->mode_set hook into the plane update (done using the plane helpers) and the crtc setup in a new ->mode_set_nofb hook. When phase 1 is complete the driver implements all the new callbacks which push the software state into hardware, but still using all the legacy entry points and crtc helpers. The transitional helpers serve as impendance mismatch here. Phase 2: Rework state handling This consists of rolling out the state handling helpers for planes, crtcs and connectors and reviewing all ->mode_fixup and similar hooks to make sure they don't depend upon implicit global state which might change in the atomic world. Any such code must be moved into ->atomic_check functions which just rely on the free-standing atomic state update structures. This phase also adds a few small pieces of fixup code to make sure the atomic state doesn't get out of sync in the legacy driver callbacks. Phase 3: Roll out atomic support Now it's just about replacing vfuncs with the ones provided by the helper and filling out the small missing pieces (like atomic_check logic or async commit support needed for page_flips). Due to the prep work in phase 1 no changes to the driver backend functions should be required, and because of the prep work in phase 2 atomic implementations can be rolled out step-by-step. So if async commit ins't implemented yet page_flip can be implemented with the legacy functions without wreaking havoc in the other operations. * tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel: drm/atomic: Refcounting for plane_state->fb drm: Docbook integration and over sections for all the new helpers drm/atomic-helpers: functions for state duplicate/destroy/reset drm/atomic-helper: implement ->page_flip drm/atomic-helpers: document how to implement async commit drm/atomic: Integrate fence support drm/atomic-helper: implementatations for legacy interfaces drm: Atomic crtc/connector updates using crtc/plane helper interfaces drm/crtc-helper: Transitional functions using atomic plane helpers drm/plane-helper: transitional atomic plane helpers drm: Add atomic/plane helpers drm: Global atomic state handling drm: Add atomic driver interface definitions for objects drm/modeset_lock: document trylock_only in kerneldoc drm: fixup kerneldoc in drm_crtc.h drm: Pull drm_crtc.h into the kerneldoc template drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
-
- 07 Nov, 2014 2 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Just various stuff all over from a bunch of people. Shortlog gives a beter overview, it's really all misc drm patches. * tag 'topic/core-stuff-2014-11-05' of git://anongit.freedesktop.org/drm-intel: drm/edid: add #defines and helpers for ELD drm/dp: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs drm: Remove compiler BUG_ON() test drm: Fix DRM_FORCE_ON_DIGITAL use drm/gma500: Don't destroy DRM properties in the driver drm/i915: Don't destroy DRM properties in the driver drm: Add a note to drm_property_create() about property lifetime gpu: drm: Fix warning caused by a parameter description in drm_crtc.c drm/dp-helper: Move the legacy helpers to gma500 drm/crtc: Remove duplicated ioctl code drm/crtc: Fix two typos gpu:drm: Fix typo in Documentation/DocBook/drm.xml gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat drm: drm_err: Remove unnecessary __func__ argument drm: Implement O_NONBLOCK support on /dev/dri/cardN
-
Dave Airlie authored
This stuff is ancient, we have docs now in the kernel, lets just drop it. Pointed out by Glenn Reviewed-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 06 Nov, 2014 8 commits
-
-
Daniel Vetter authored
So my original plan was that the drm core refcounts framebuffers like with the legacy ioctls. But that doesn't work for a bunch of reasons: - State objects might live longer than until the next fb change happens for a plane. For example delayed cleanup work only happens _after_ the pageflip ioctl has completed. So this definitely doesn't work without the plane state holding its own references. - The other issue is transition from legacy to atomic implementations, where the driver works under a mix of both worlds. Which means legacy paths might not properly update the ->fb pointer under plane->state->fb. Which is a bit a problem when then someone comes around and _does_ try to clean it up when it's long gone. The second issue is just a bit a transition bug, since drivers should update plane->state->fb in all the paths that aren't converted yet. But a bit more robustness for the transition can't hurt - we pull similar tricks with cleaning up the old fb in the transitional helpers already. The pattern for drivers that transition is if (plane->state) drm_atomic_set_fb_for_plane(plane->state, plane->fb); inserted after the fb update has logically completed at the end of ->set_config (or ->set_base/mode_set if using the crtc helpers), ->page_flip, ->update_plane or any other entry point which updates plane->fb. v2: Update kerneldoc - copypasta fail. v3: Fix spelling in the commit message (Sean). Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
In all cases the text requires that new drivers are converted to the atomic interfaces. v2: Add overview for state handling. v3: Review from Sean: Some spelling fixes and drop the misguided hunk to remove rgba8888 from the plane helpers compat list. Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
No helper function to do it all yet provided since no driver has support for driver core fences yet. Which we'd need to make the implementation really generic. v2: Clarify async howto a bit per the discussion With Rob Clark. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Daniel Vetter authored
This patch is for enabling async commits. It replaces an earlier approach which added an async boolean paramter to the ->prepare_fb callbacks. The idea is that prepare_fb picks up the right fence to synchronize against, which is then used by the synchronous commit helper. For async commits drivers can either register a callback to the fence or simply do the synchronous wait in their async work queue. v2: Remove unused variable. v3: Only wait for fences after the point of no return in the part of the commit function which can be run asynchronously. This is after the atomic state has been swapped in, hence now check plane->state->fence. Also add a WARN_ON to make sure we don't try to wait on a fence when there's no fb, just as a sanity check. Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
- 05 Nov, 2014 8 commits
-
-
Daniel Vetter authored
These two functions allow drivers to reuse their atomic plane helpers functions for the primary plane to implement the interfaces required by the crtc helpers for the legacy ->set_config callback. This is purely transitional and won't be used once the driver is fully converted. But it allows partial conversions to the atomic plane helpers which are functional. v2: - Use ->atomic_duplicate_state if available. - Don't forget to run crtc_funcs->atomic_check. v3: Shift source coordinates correctly for 16.16 fixed point. v4: Don't forget to call ->atomic_destroy_state if available. v5: Fixup kerneldoc. v6: Reuse the plane_commit function from the transitional plane helpers to avoid too much duplication. v7: - Remove some stale comment. - Correctly handle the lack of plane->state object, necessary for transitional use. v8: Fixup an embarrassing h/vdisplay mixup. Reviewed-by:
-
Daniel Vetter authored
Converting a driver to the atomic interface can be a daunting undertaking. One of the prerequisites is to have full universal planes support. To make that transition a bit easier this patch provides plane helpers which use the new atomic helper callbacks just only for the plane changes. This way the plane update functionality can be tested without being forced to convert everything at once. Of course a real atomic update capable driver will implement the all plane properties through the atomic interface, so these helpers are mostly transitional. But they can be used to enable proper universal plane support, especially once the crtc helpers have also been adapted. v2: Use ->atomic_duplicate_state if available. v3: Don't forget to call ->atomic_destroy_state if available. v4: Fixup kerneldoc, reported by Paulo. v5: Extract a common plane_commit helper and fix some bugs in the plane_state setup of the plane_disable implementation. v6: Fix issues with the cleanup of the old fb. Since transitional helpers can be mixed we need to assume that the old fb has been set up by a legacy path (e.g. set_config or page_flip when the primary plane is converted to use these functions already). Hence pass an additional old_fb parameter to plane_commit to do that cleanup work correctly. v7: - Fix spurious WARNING (crtc helpers really love to disable stuff harder) and fix array index bonghits. - Correctly handle the lack of plane->state object, necessary for transitional use. - Don't indicate failure if drm_vblank_get doesn't work - that's expected when the pipe is in dpms off mode. v8: Review from Sean: - s/fail/out/ to make the meaning of a label more clear. - spelling fix in the commit message. Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Daniel Vetter authored
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: -
Daniel Vetter authored
Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww mutex deadlock avoidance (and so either reinvents a new deadlock avoidance wheel or like the current code just deadlocks). - State for connectors needed to be added, since now they have a full-blown drm_connector_state (so that drivers have something to attach their own stuff to). - Refcounting is gone. I plane to solve async updates differently, since the lock-passing scheme doesn't cut it (since it abuses ww mutexes). Essentially what we need for async is a simple ownership transfer from the caller to the driver. That doesn't need full-blown refcounting. - The acquire ctx is a pointer. Real atomic callers should have that on their stack, legacy entry points need to put the right one (obtained by drm_modeset_legacy_acuire_ctx) in there. - I've dropped all hooks except check/commit. All the begin/end handling is done by core functions and is the same. - commit/check are just thin wrappers that ensure that ->check is always called. - To help out with locking in the legacy implementations I've added a helper to just grab all locks in the backoff case. v2: Add notices that check/commit can fail with EDEADLK. v3: - More consistent naming for state_alloc. - Add state_clear which is needed for backoff and retry. v4: Planes/connectors can switch between crtcs, and we need to be careful that we grab the state (and locks) for both the old and new crtc. Improve the interface functions to ensure this. v5: Add functions to grab affected connectors for a crtc and to recompute the crtc->enable state. This is useful for both helper and atomic ioctl code when e.g. removing a connector. v6: Squash in fixup from Fengguang to use ERR_CAST. v7: Add debug output. v8: Make checkpatch happy about kcalloc argument ordering. v9: Improve kerneldoc in drm_crtc.h v10: - Fix another kcalloc argument misorder I've missed. - More polish for kerneldoc. v11: Clarify the ownership rules for the state object. The new rule is that a successful drm_atomic_commit (whether synchronous or asnyc) always inherits the state and is responsible for the clean-up. That way async and sync ->commit functions are more similar. v12: A few bugfixes: - Assign state->state pointers correctly when grabbing state objects - we need to link them up with the global state. - Handle a NULL crtc in set_crtc_for_plane to simplify code flow a bit for the callers of this function. v13: Review from Sean: - kerneldoc spelling fixes - Don't overallocate states->planes. - Handle NULL crtc in set_crtc_for_connector. v14: Sprinkle __must_check over all functions which do wait/wound locking to make sure callers don't forget this. Since I have ;-) v15: Be more explicit in the kerneldoc when functions can return -EDEADLK what to do. And that every other -errno is fatal. v16: Indent with tabs instead of space, spotted by Ander. v17: Review from Thierry, small kerneldoc and other naming polish. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Daniel Vetter authored
Heavily based upon Rob Clark's atomic series. - Dropped the connector state from the crtc state, instead opting for a full-blown connector state. The only thing it has is the desired crtc, but drivers which have connector properties have now a data-structure to subclass. - Rename create_state to duplicate_state. Especially for legacy ioctls we want updates on top of existing state, so we need a way to get at the current state. We need to be careful to clear the backpointers to the global state correctly though. - Drop property values. Drivers with properties simply need to subclass the datastructures and track the decoded values in there. I also think that common properties (like rotation) should be decoded and stored in the core structures. - Create a new set of ->atomic_set_prop functions, for smoother transitions from legacy to atomic operations. - Pass the ->atomic_set_prop ioctl the right structure to avoid chasing pointers in drivers. - Drop temporary boolean state for now until we resurrect them with the helper functions. - Drop invert_dimensions. For now we don't need any checking since that's done by the higher-level legacy ioctls. But even then we should also add rotation/flip tracking to the core drm_crtc_state, not just whether the dimensions are inverted. - Track crtc state with an enable/disable. That's equivalent to mode_valid, but a bit clearer that it means the entire crtc. The global interface will follow in subsequent patches. v2: We need to allow drivers to somehow set up the initial state and clear it on resume. So add a plane->reset callback for that. Helpers will be provided with default behaviour for all these. v3: Split out the plane->reset into a separate patch. v4: Improve kerneldoc in drm_crtc.h v5: Remove unused inline functions for handling state objects, those callbacks are now mandatory for full atomic support. v6: Fix commit message nit Sean noticed. Reviewed-by:
-
Daniel Vetter authored
I've forgotten to do this in: commit cb597bb3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 27 19:09:33 2014 +0200 drm: trylock modest locking for fbdev panics Oops, fix this asap. In my defense kerneldoc is really awful and there's no way it can pick up structured comments per struct member. Which means we need both since people won't scroll up even a few lines. Reviewed-by:
-
Jani Nikula authored
In the interest of reducing magic numbers and having to cross check with the specs all the time. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Todd Previte authored
These counters are used for Displayort compliance testing to detect error conditions when executing tests 4.2.2.4 and 4.2.2.5 in the Displayport Link CTS specificaiton. They determine whether to use the preferred/requested mode or the failsafe mode during these tests. V2: - Addressed previous review feedback - Updated commit message - Changed from uint8_t to uint32_t Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Todd Previte <tprevite@gmail.com> [danvet: s/uint32_t/unsigned/ for clearer intent. Also drop the i915 from the subject, it's all core stuff.] Signed-off-by:
-
- 04 Nov, 2014 5 commits
-
-
Daniel Vetter authored
I've tried to cc all the people who have recently added new stuff but forgotten to update documentation. I've also decided not to bother documenting the massive property list in struct drm_mode_config. If that beast keeps on growing we might want to extract it into a separate structure which we won't document. Cc: Thomas Wood <thomas.wood@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by:
-
Daniel Vetter authored
While writing atomic docs I've noticed that I don't get any errors for my screw-ups in drm_crtc.h. Fix this immediately. This just does the bare minimum to get starts, lots of stuff isn't properly documented yet unfortunately. v2: Fix adjacent spelling error Sean noticed. Reviewed-by:
-
Daniel Vetter authored
Just a bit of OCD cleanup on headers - this function isn't the core interface any more but just a helper for drivers who haven't yet transitioned to universal planes. Put the declaration at the right spot and sprinkle necessary #includes over all drivers. Maybe this helps to encourage driver maintainers to do the switch. v2: Fix #include ordering for tegra, reported by 0-day builder. v3: Include required headers, reported by Thierry. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Peter Hurley authored
modeset->num_connectors must be 0 to reach the BUG_ON() which tests for non-zero modeset->num_connectors; remove BUG_ON(). Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Peter Hurley authored
A connector may be forced on from the command line via video= command line setting. The digital output of dual-mode connectors can also be specifically selected and forced on; eg., 'video=DVI-I-2:D'. However, in this case, the connector->status will be mistakenly set to connector_status_disconnected, and the connector will not be mode set. Fix the connector->status when connector->force is DRM_FORCE_ON_DIGITAL. Note that this seems to have been broken ever since the introduction of the connector forcing support in commit d50ba256 Author: Dave Airlie <airlied@linux.ie> Date: Wed Sep 23 14:44:08 2009 +1000 drm/kms: start adding command line interface using fb. Signed-off-by:
-
- 03 Nov, 2014 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- suspend/resume/freeze/thaw unification from Imre - wa list improvements from Mika&Arun - display pll precomputation from Ander Conselvan, this removed the last ->mode_set callbacks, a big step towards implementing atomic modesets - more kerneldoc for the interrupt code - 180 rotation for cursors (Ville&Sonika) - ULT/ULX feature check macros cleaned up thanks to Damien - piles and piles of fixes all over, bug team seems to work! * tag 'drm-intel-next-2014-10-24' of git://anongit.freedesktop.org/drm-intel: (61 commits) drm/i915: Update DRIVER_DATE to 20141024 drm/i915: add comments on what stage a given PM handler is called drm/i915: unify switcheroo and legacy suspend/resume handlers drm/i915: add poweroff_late handler drm/i915: sanitize suspend/resume helper function names drm/i915: unify S3 and S4 suspend/resume handlers drm/i915: disable/re-enable PCI device around S4 freeze/thaw drm/i915: enable output polling during S4 thaw drm/i915: check for GT faults in all resume handlers and driver load time drm/i915: remove unused restore_gtt_mappings optimization during suspend drm/i915: fix S4 suspend while switcheroo state is off drm/i915: vlv: fix switcheroo/legacy suspend/resume drm/i915: propagate error from legacy resume handler drm/i915: unify legacy S3 suspend and S4 freeze handlers drm/i915: factor out i915_drm_suspend_late drm/i915: Emit even number of dwords when emitting LRIs drm/i915: Add rotation support for cursor plane (v5) drm/i915: Correctly reject invalid flags for wait_ioctl drm/i915: use macros to assign mmio access functions drm/i915: only run hsw_power_well_post_enable when really needed ...
-
- 31 Oct, 2014 3 commits
-
-
Damien Lespiau authored
When drm properties are created, they are added to mode_config.property_list which is then used in drm_mode_config_cleanup() to destroy every single property created by the driver. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
When drm properties are created, they are added to mode_config.property_list, which is then used in drm_mode_config_cleanup() to destroy every single property created by the driver. Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Damien Lespiau authored
Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
- 28 Oct, 2014 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2014-10-03-no-ppgtt' of git://anongit.freedesktop.org/drm-intel into drm-next Ok, new attempt, this time around with full ppgtt disabled again. drm-intel-next-2014-10-03: - first batch of skl stage 1 enabling - fixes from Rodrigo to the PSR, fbc and sink crc code - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic interrupt enable/disable functions - smaller stuff all over drm-intel-next-2014-09-19: - bunch more i830M fixes from Ville - full ppgtt now again enabled by default - more ppgtt fixes from Michel Thierry and Chris Wilson - plane config work from Gustavo Padovan - spinlock clarifications - piles of smaller improvements all over, as usual * tag 'drm-intel-next-2014-10-03-no-ppgtt' of git://anongit.freedesktop.org/drm-intel: (114 commits) Revert "drm/i915: Enable full PPGTT on gen7" drm/i915: Update DRIVER_DATE to 20141003 drm/i915: Remove the duplicated logic between the two shrink phases drm/i915: kerneldoc for interrupt enable/disable functions drm/i915: Use dev_priv instead of dev in irq setup functions drm/i915: s/pm._irqs_disabled/pm.irqs_enabled/ drm/i915: Clear TX FIFO reset master override bits on chv drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv drm/i915: make sink_crc return -EIO on aux read/write failure drm/i915: Constify send buffer for intel_dp_aux_ch drm/i915: De-magic the PSR AUX message drm/i915: Reinstate error level message for non-simulated gpu hangs drm/i915: Kerneldoc for intel_runtime_pm.c drm/i915: Call runtime_pm_disable directly drm/i915: Move intel_display_set_init_power to intel_runtime_pm.c drm/i915: Bikeshed rpm functions name a bit. drm/i915: Extract intel_runtime_pm.c drm/i915: Remove intel_modeset_suspend_hw drm/i915: spelling fixes for frontbuffer tracking kerneldoc drm/i915: Tighting frontbuffer tracking around flips ...
-
- 26 Oct, 2014 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "Another week, another small batch of fixes. Most of these make zynq, socfpga and sunxi platforms work a bit better: - due to new requirements for regulators, DWMMC on socfpga broke past v3.17 - SMP spinup fix for socfpga - a few DT fixes for zynq - another option (FIXED_REGULATOR) for sunxi is needed that used to be selected by other options but no longer is. - a couple of small DT fixes for at91 - ...and a couple for i.MX" * tag 'armsoc-for-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: dts: imx28-evk: Let i2c0 run at 100kHz ARM: i.MX6: Fix "emi" clock name typo ARM: multi_v7_defconfig: enable CONFIG_MMC_DW_ROCKCHIP ARM: sunxi_defconfig: enable CONFIG_REGULATOR_FIXED_VOLTAGE ARM: dts: socfpga: Add a 3.3V fixed regulator node ARM: dts: socfpga: Fix SD card detect ARM: dts: socfpga: rename gpio nodes ARM: at91/dt: sam9263: fix PLLB frequencies power: reset: at91-reset: fix power down register MAINTAINERS: add atmel ssc driver maintainer entry arm: socfpga: fix fetching cpu1start_addr for SMP ARM: zynq: DT: trivial: Fix mc node ARM: zynq: DT: Add cadence watchdog node ARM: zynq: DT: Add missing reference for memory-controller ARM: zynq: DT: Add missing reference for ADC ARM: zynq: DT: Add missing address for L2 pl310 ARM: zynq: DT: Remove 222 MHz OPP ARM: zynq: DT: Fix GEM register area size -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs updates from Al Viro: "overlayfs merge + leak fix for d_splice_alias() failure exits" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: overlayfs: embed middle into overlay_readdir_data overlayfs: embed root into overlay_readdir_data overlayfs: make ovl_cache_entry->name an array instead of pointer overlayfs: don't hold ->i_mutex over opening the real directory fix inode leaks on d_splice_alias() failure exits fs: limit filesystem stacking depth overlay: overlay filesystem documentation overlayfs: implement show_options overlayfs: add statfs support overlay filesystem shmem: support RENAME_WHITEOUT ext4: support RENAME_WHITEOUT vfs: add RENAME_WHITEOUT vfs: add whiteout support vfs: export check_sticky() vfs: introduce clone_private_mount() vfs: export __inode_permission() to modules vfs: export do_splice_direct() to modules vfs: add i_op->dentry_open()
-
Olof Johansson authored
Merge tag 'imx-fixes-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Merge "ARM: imx: fixes for 3.18" from Shawn Guo: The i.MX fixes for 3.18: - Revert one patch which increases I2C bus frequency on imx28-evk - Fix a typo on imx6q EIM clock name * tag 'imx-fixes-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx28-evk: Let i2c0 run at 100kHz ARM: i.MX6: Fix "emi" clock name typo Signed-off-by:
Olof Johansson <olof@lixom.net>
-
- 25 Oct, 2014 6 commits
-
-
Fabio Estevam authored
Commit 78b81f46 ("ARM: dts: imx28-evk: Run I2C0 at 400kHz") caused issues when doing the following sequence in loop: - Boot the kernel - Perform audio playback - Reboot the system via 'reboot' command In many times the audio card cannot be probed, which causes playback to fail. After restoring to the original i2c0 frequency of 100kHz there is no such problem anymore. This reverts commit 78b81f46. Cc: <stable@vger.kernel.org> # 3.16+ Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org>
-
Steve Longerbeam authored
Fix a typo error, the "emi" names refer to the eim clocks. The change fixes typo in EIM and EIM_SLOW pre-output dividers and selectors clock names. Notably EIM_SLOW clock itself is named correctly. Signed-off-by:
Steve Longerbeam <steve_longerbeam@mentor.com> [vladimir_zapolskiy@mentor.com: ported to v3.17] Signed-off-by:
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Sascha Hauer <kernel@pengutronix.de> Signed-off-by:
-
Al Viro authored
same story... Signed-off-by:Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
no sense having it a pointer - all instances have it pointing to local variable in the same stack frame Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
just use it to serialize the assignment Signed-off-by:
-
