Commit Graph

15 Commits

Author SHA1 Message Date
Dave Airlie 1ddd36eda1 drm/tegra: Changes for v4.1-rc1
Perhaps the most noteworthy change in this set is the implementation of
 a hardware VBLANK counter using host1x syncpoints. The SOR registers can
 now be dumped via debugfs, which can be useful while debugging. The IOVA
 address space maintained by the driver can also be dumped via debugfs.
 
 Other than than, these changes are mostly cleanup work, such as making
 register names more consistent or removing unused code (that was left
 over after the atomic mode-setting conversion). There's also a fix for
 eDP that makes the driver cope with firmware that already initialized
 the display (such as the firmware on the Tegra-based Chromebooks).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJVHXUKAAoJEN0jrNd/PrOhjSUQAL9QJZBZmQmit1mroVWmWAx8
 1m4/lj0bP3s1uOLzkQUwXJes0/niVie6lGmdZ9WCa3lThPErfvgYqKNpVJOYknMR
 iFg3HbEHgqz9T5zGNxp43g2hQrxssGEPAJXg4vE06nyS9YTOe0PZi27z9ynwapNZ
 Z+Gl2787mmnQE+PyQUQjT96OJv2ahnTgHtcDNMU0SWh5Dr6tI/vo5l/mHnqFOKnQ
 Kt/CCf+eNZ1jWCKqN5WYjxUT8kCMsMPPcnKzwhvrCXf6RqMDhr/rc47PGeak/qKR
 0poIA47XlN6lPwul1P2gtyJaMiE7790aPKcgUDdpHJItPxbC9D/A8o8M+TcUqryw
 NHdKKEDxoo/yg+2x6ZgFk202UbVevp6cBtP+3nrfUAefPCrrkDX31ej6rWAUs7Zm
 POzugFON7q+85kF/yO1IEg1lov3zLIl4tCXNtprXUPFHbaBJJpMYK8joNyg2YZVh
 pYrV6AaKEwiVpi2h/kfhk/B32fx/KsufBR7fEPFOcJFQ6Gmi/l6GB+li00+LbrI4
 8mDN6ngw7KASj03/RWXKSwGXdHqoMx2vtQPgjlNuGhHSgGzk3hZqapC7X+5WhoAw
 bOelbtzFABv8EA+vQN5IXd8SKdMPt4AFVGhk4B9HbZUyQLHln187p1tE1q9jSe/V
 D9bxrB3Wlf4Ks6Kl8OqU
 =HZO1
 -----END PGP SIGNATURE-----

Merge tag 'drm/tegra/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next

drm/tegra: Changes for v4.1-rc1

Perhaps the most noteworthy change in this set is the implementation of
a hardware VBLANK counter using host1x syncpoints. The SOR registers can
now be dumped via debugfs, which can be useful while debugging. The IOVA
address space maintained by the driver can also be dumped via debugfs.

Other than than, these changes are mostly cleanup work, such as making
register names more consistent or removing unused code (that was left
over after the atomic mode-setting conversion). There's also a fix for
eDP that makes the driver cope with firmware that already initialized
the display (such as the firmware on the Tegra-based Chromebooks).

* tag 'drm/tegra/for-4.1-rc1' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: sor: Reset during initialization
  drm/tegra: gem: Return 64-bit offset for mmap(2)
  drm/tegra: hdmi: Name register fields consistently
  drm/tegra: hdmi: Resets are synchronous
  drm/tegra: dc: Document tegra_dc_state_setup_clock()
  drm/tegra: dc: Remove unused callbacks
  drm/tegra: dc: Remove unused function
  drm/tegra: dc: Use base atomic state helpers
  drm/atomic: Add helpers for state-subclassing drivers
  drm/tegra: dc: Implement hardware VBLANK counter
  gpu: host1x: Export host1x_syncpt_read()
  drm/tegra: sor: Dump registers via debugfs
  drm/tegra: sor: Registers are 32-bit
  drm/tegra: Provide debugfs file for the IOVA space
  drm/tegra: dc: Check for valid parent clock
2015-04-08 11:13:06 +10:00
Thierry Reding f5e7840b0c drm/atomic: Add helpers for state-subclassing drivers
Drivers that subclass CRTC, plane or connector state need to carefully
duplicate the code that the atomic helpers have. This is bound to cause
breakage eventually because it requires auditing all drivers and update
them when code is added to the helpers.

In order to avoid that, implement new helpers that perform the required
steps when copying and destroying state. These new helpers are exported
so that state-subclassing drivers can use them. The default helpers are
implemented using them as well, providing a single location that needs
to be changed when adding to base atomic states.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-04-02 18:48:32 +02:00
Daniel Vetter 1af434a928 drm/atomic-helper: Rename commmit_post/pre_planes
These names only make sense because of backwards compatability with
the order used by the crtc helper library. There's not really any real
requirement in the ordering here.

So rename them to something more descriptive and update the kerneldoc
a bit. Motivated in a discussion with Laurent about how to restore
plane state for dpms for drivers with runtime pm.

v2: Squash in fixup from Stephen Rothwell to fix a conflict with
tegra.

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-02-24 01:57:46 +01:00
Dave Airlie 21773f16f2 Merge tag 'topic/atomic-core-2015-01-27' of git://anongit.freedesktop.org/drm-intel into drm-next
* tag 'topic/atomic-core-2015-01-27' of git://anongit.freedesktop.org/drm-intel:
  drm/atomic: Fix potential use of state after free
  drm/atomic-helper: debug output for modesets
  drm/atomic-helpers: Saner encoder/crtc callbacks
  drm/atomic-helpers: Recover full cursor plane behaviour
  drm/atomic-helper: add connector->dpms() implementation
  drm/atomic: Add drm_crtc_state->active
  drm: Add standardized boolean props
  drm/plane-helper: Fix transitional helper kerneldocs
  drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb

Conflicts:
	include/drm/drm_crtc_helper.h
2015-01-28 09:34:27 +10:00
Thierry Reding 407b8bd9f5 drm/plane: Add optional ->atomic_disable() callback
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.

v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled planes, remove redundant comment (Daniel Vetter)

v3: rename helper to drm_atomic_plane_disabling() to clarify that it is
checking for transitions, move helper to drm_atomic_helper.h, clarify
check for !old_state and its relation to transitional helpers

Here's an extract from some discussion rationalizing the behaviour (for
a full version, see the reference below):

    > > Hm, thinking about this some more this will result in a slight difference
    > > in behaviour, at least when drivers just use the helper ->reset functions
    > > but don't disable everything:
    > > - With transitional helpers we assume we know nothing and call
    > >   ->atomic_disable.
    > > - With atomic old_state->crtc == NULL in the same situation right after
    > >   boot-up, but we asssume the plane is really off and _dont_ call
    > >   ->atomic_disable.
    > >
    > > Should we instead check for (old_state && old_state->crtc) and state that
    > > drivers need to make sure they don't have stuff hanging around?
    >
    > I don't think we can check for old_state because otherwise this will
    > always return false, whereas we really want it to force-disable planes
    > that could be on (lacking any more accurate information). For
    > transitional helpers anyway.
    >
    > For the atomic helpers, old_state will never be NULL, but I'd assume
    > that the driver would reconstruct the current state in ->reset().

    By the way, the reason for why old_state can be NULL with transitional
    helpers is the ordering of the steps in the atomic transition. Currently
    the Tegra patches do this (based on your blog post and the Exynos proto-
    type):

        1) atomic conversion, phase 1:
           - implement ->atomic_{check,update,disable}()
           - use drm_plane_helper_{update,disable}()

        2) atomic conversion, phase 2:
           - call drm_mode_config_reset() from ->load()
           - implement ->reset()

    That's only a partial list of what's done in these steps, but that's the
    only relevant pieces for why old_state is NULL.

    What happens is that without ->reset() implemented there won't be any
    initial state, hence plane->state (the old_state here) will be NULL the
    first time atomic state is applied.

    We could of course reorder the sequence such that drivers are required
    to hook up ->reset() before they can (or at the same as they) hook up
    the transitional helpers. We could add an appropriate WARN_ON to this
    helper to make that more obvious.

    However, that will not solve the problem because it only gets rid of the
    special case. We still don't know whether old_state->crtc == NULL is the
    current state or just the initial default.

    So no matter which way we do this, I don't see a way to get away without
    requiring specific semantics from drivers. They would be that:

        - drivers recreate the correct state in ->reset() so that
          old_state->crtc != NULL if the plane is really enabled

    or

        - drivers have to ensure that the real state in fact mirrors the
          initial default as encoded in the state (plane disabled)

References: http://lists.freedesktop.org/archives/dri-devel/2015-January/075578.html
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-27 10:14:42 +01:00
Daniel Vetter b486e0e6d5 drm/atomic-helper: add connector->dpms() implementation
This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.

Of course it also clamps everything that's not ON to OFF.

v2: Fix spelling in one comment.

v3: Don't do an async commit (Thierry)

v4: Dan Carpenter noticed missing error case handling.

Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-27 10:02:29 +01:00
Daniel Vetter d9b13620fa drm/atomic-helper: Export both plane and modeset check helpers
The default call sequence for these two parts won't fit for all
drivers. So export the two pieces and explain with a bit of kerneldoc
when each should be called.

v2: Squash in fixup from Rob to actually add the newly exported
functions to headers

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-17 20:23:22 +01:00
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