Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 6月, 2016 4 次提交
    • L
      drm: Fix comment making reference to non-existing function · 5c0be3f1
      由 Liviu Dudau 提交于 
      Documentation for drm_atomic_crtc_for_each_plane() makes reference to
a function called drm_crtc_for_each_pending_plane(). I've guessed that
the actual function name is drm_atomic_crtc_state_for_each_plane() as
that matches best the intent of the comment.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465571005-3877-1-git-send-email-Liviu.Dudau@arm.com
      5c0be3f1
    • D
      drm/atomic-helper: nonblocking commit support · 9f2a7950
      由 Daniel Vetter 提交于 
      Design ideas:

- split up the actual commit into different phases, and have
  completions for each of them. This will be useful for the future
  when we want to interleave phases much more aggressively, for e.g.
  queue depth > 1. For not it's just a minimal optimization compared
  to current common nonblocking implementation patterns from drivers,
  which all stall for the entire commit to complete, including vblank
  waits and cleanups.

- Extract a separate atomic_commit_hw hook since that's the part most
  drivers will need to overwrite, hopefully allowing even more shared
  code.

- Enforce EBUSY seamntics by attaching one of the completions to the
  flip_done vblank event. Side benefit of forcing atomic drivers using
  these helpers to implement event handlign at least semi-correct. I'm
  evil that way ;-)

- Ridiculously modular, as usual.

- The main tracking unit for a commit stays struct drm_atomic_state,
  and the ownership rules for that are unchanged. Ownership still
  gets transferred to the driver (and subsequently to the worker) on
  successful commits. What is added is a small, per-crtc, refcounted
  structure to track pending commits called struct drm_crtc_commit.
  No actual state is attached to that though, it's purely for ordering
  and waiting.

- Dependencies are implicitly handled by assuming that any CRTC part
  of &drm_atomic_state is a dependency, and that the current commit
  must wait for any commits to complete on those CRTC. This way
  drivers can easily add more depencies using
  drm_atomic_get_crtc_state(), which is very natural since in most
  case a dependency exists iff there's some bit of state that needs to
  be cross checked.

  Removing depencies is not possible, drivers simply need to be
  careful to not include every CRTC in a commit if that's not
  necessary. Which is a good idea anyway, since that also avoids
  ww_mutex lock contention.

- Queue depth > 1 sees some prep work in this patch by adding a stall
  paramater to drm_atomic_helper_swap_states(). To be able to push
  commits entirely free-standing and in a deeper queue through the
  back-end the driver must not access any obj->state pointers. This
  means we need to track the old state in drm_atomic_state (much
  easier with the consolidated arrays), and pass them all explicitly
  to driver backends (this will be serious amounts of churn).

  Once that's done stall can be set to false in swap_states.

v2: Dont ask for flip_done signalling when the CRTC is off and stays
off: Drivers don't handle events in that case. Instead complete right
away. This way future commits don't need to have special-case logic,
but can keep blocking for the flip_done completion.

v3: Tons of fixes:
- Stall for preceeding commit for real, not the current one by
  accident.
- Add WARN_ON in case drivers don't fire the drm event.
- Don't double-free drm events.

v4: Make legacy cursor not stall.

v5: Extend the helper hook to cover the entire commit tail. Some
drivers need special code for cleanup and vblank waiting, this makes
it a bit more useful. Inspired by the rockchip driver.

v6: Add WARN_ON to catch drivers who forget to send out the
drm event.

v7: Fixup the stalls in swap_state for real!!

v8:
- Fixup trailing whitespace, spotted by Maarten.
- Actually wait for flip_done in cleanup_done, like the comment says
  we should do. Thanks a lot for Tomeu for helping with debugging this
  on.

v9: Now with awesome kerneldoc!

v10: Split out drm_crtc_commit tracking infrastructure.

v:
- Add missing static (Gustavo).
- Split out the sync functions, only do the actual nonblocking
  logic in this patch (Maarten).

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Tested-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: igt/kms_flip/*
Testcase: igt/kms_cursor*
Testcase: igt/kms*plane*
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-10-git-send-email-daniel.vetter@ffwll.ch
      9f2a7950
    • D
      drm/atomic-helper: roll out commit synchronization · a095caa7
      由 Daniel Vetter 提交于 
      To facilitate easier reviewing this is split out from the overall
nonblocking commit rework. It just rolls out the helper functions
and uses them in the main drm_atomic_helper_commit() function
to make it clear where in the flow they're used.

The next patch will actually split drm_atomic_helper_commit() into
2 pieces, with the tail being run asynchronously from a worker.

v2: Improve kerneldocs (Maarten).

v3: Don't convert ERESTARTSYS to EINTR (Maarten). Also don't fail if
the wait succeed in stall_check - we need to convert that case (it
returns the remaining jiffies) to 0 for success.

v4: Switch to long for wait_for_completion_timeout return value
everywhere (Maarten).

v5: Fix miscaped function in kerneldoc (Maarten).
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tomeu Vizoso <tomeu.vizoso@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Tested-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465398936-22305-1-git-send-email-daniel.vetter@ffwll.ch
      a095caa7
    • D
      drm/atomic-helper: Massage swap_state signature somewhat · 5e84c269
      由 Daniel Vetter 提交于 
      - dev is redundant, we have state->atomic
- add stall parameter, which must be set when swapping needs to stall
  for preceeding commits to stop looking at ->state pointers. Currently
  all drivers need this to be, just prep work for a glorious future.

v2: Rebased on top of

commit e7cf0963
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue May 31 08:50:47 2016 +0200

    virtio-gpu: add atomic_commit function

Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465509992-19284-1-git-send-email-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-2-git-send-email-daniel.vetter@ffwll.ch
      5e84c269
  3. 07 6月, 2016 1 次提交
  5. 02 6月, 2016 1 次提交
  7. 17 5月, 2016 3 次提交
  9. 12 5月, 2016 1 次提交
  11. 02 5月, 2016 1 次提交
  13. 31 3月, 2016 1 次提交
  15. 08 3月, 2016 1 次提交
  17. 20 1月, 2016 1 次提交
  19. 05 1月, 2016 1 次提交
  21. 03 12月, 2015 1 次提交
  23. 30 11月, 2015 1 次提交
  25. 17 9月, 2015 1 次提交
  27. 08 9月, 2015 2 次提交
    • T
      drm/atomic-helper: Implement drm_atomic_helper_duplicate_state() · 397fd77c
      由 Thierry Reding 提交于 
      This function can be used to duplicate an atomic state object. This is
useful for example to implement suspend/resume, where the state before
suspend can be saved and restored upon resume.

v2: move locking to caller, be more explicit about prerequisites
v3: explicitly pass lock acquisition context, improve kerneldoc
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      397fd77c
    • D
      drm/atomic-helper: Add option to update planes only on active crtc · aef9dbb8
      由 Daniel Vetter 提交于 
      With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.

Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set this to
true.

v2: Check for NULL state->crtc before chasing the pointer. Also check
both old and new crtc if there's a switch. Finally just outright
disallow switching crtcs for a plane if the plane is in active use, on
most hardware that doesn't make sense.

v3: Since commit_planes(active_only = true) is for enabling things
only after all the crtc are on we should only look at the new crtc to
decide whether to call the plane hooks - if the current CRTC isn't on
then skip. If the old crtc (when moving a plane) went down then the
plane should have been disabled as part of the pipe shutdown work
already. For which there's currently no helper really unfortunately.
Also move the check for wether a plane gets a new CRTC assigned while
still in active use out of this patch.

v4: Rebase over exynos changes.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      aef9dbb8
  29. 27 7月, 2015 1 次提交
  31. 21 5月, 2015 1 次提交
  33. 13 5月, 2015 1 次提交
  35. 03 4月, 2015 1 次提交
    • T
      drm/atomic: Add helpers for state-subclassing drivers · f5e7840b
      由 Thierry Reding 提交于 
      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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      f5e7840b
  37. 24 2月, 2015 1 次提交
  39. 27 1月, 2015 2 次提交
    • T
      drm/plane: Add optional ->atomic_disable() callback · 407b8bd9
      由 Thierry Reding 提交于 
      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.htmlReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      407b8bd9
    • D
      drm/atomic-helper: add connector->dpms() implementation · b486e0e6
      由 Daniel Vetter 提交于 
      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: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b486e0e6
  41. 18 12月, 2014 1 次提交
  43. 27 11月, 2014 1 次提交
  45. 25 11月, 2014 1 次提交
  47. 12 11月, 2014 1 次提交
  49. 07 11月, 2014 4 次提交
    • D
      drm/atomic-helpers: functions for state duplicate/destroy/reset · d461701c
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d461701c
    • D
      drm/atomic-helper: implement ->page_flip · 8bc0f312
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8bc0f312
    • D
      drm/atomic-helper: implementatations for legacy interfaces · 042652ed
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      042652ed
    • D
      drm: Atomic crtc/connector updates using crtc/plane helper interfaces · 623369e5
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      623369e5
  51. 06 11月, 2014 1 次提交
    • D
      drm: Add atomic/plane helpers · c2fcd274
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c2fcd274
  53. 03 10月, 2012 2 次提交
    • B
      drm/nouveau/bios: pull in basic vbios subdev, more to come later · 70c0f263
      由 Ben Skeggs 提交于 
      v2: Ben Skeggs <bskeggs@redhat.com>
- use unaligned macros to access vbios image
- endianness fixes
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      70c0f263
    • B
      drm/nouveau/core: pull in most of the new core infrastructure · 9274f4a9
      由 Ben Skeggs 提交于 
      This commit provides most of the infrastructure to support a major overhaul
of Nouveau's internals coming in the following commits.  This work aims to
take all the things we've learned over the last several years, and turn that
into a cleaner architecture that's more maintainable going forward.

RAMHT and MM bits of the new core have been left out for the moment, and
will be pulled in as I go through the process of porting the code to
become either subdev or engine modules.

There are several main goals I wanted to achieve through this work:

-- Reduce complexity

The goal here was to make each component of the driver as independent as
possible, which will ease maintainability and readability, and provide a
good base for resetting locked up GPU units in the future.

-- Better tracking of GPU units that are required at any given time

This is for future PM work, we'll be able to tell exactly what parts of the
GPU we need powered at any given point (etc).

-- Expose all available NVIDIA GPUs to the client

In order to support things such as multi-GPU channels, we want to be able
to expose all the NVIDIA GPUs to the client over a single file descriptor
so it can send a single push buffer to multiple GPUs.

-- Untangle the core hardware support code from the DRM implementation

This happened initially as an unexpected side-effect of developing the
initial core infrastructure in userspace, but it turned into a goal of
the whole project.  Initial benefits will be the availablility of a
number of userspace tools and tests using the same code as the driver
itself, but will also be important as I look into some virtualisation
ideas.

v2: Ben Skeggs <bskeggs@redhat.com>
- fix duplicate assignments noticed by clang
- implement some forgotten yelling in error path
- ensure 64-bit engine mask is used everywhere

v3: Marcin Slusarz <marcin.slusarz@gmail.com>
- sparse fixes
- inline nv_printk into nv_assert to prevent recursive inlining issues

v4: Ben Skeggs <bskeggs@redhat.com>
- fixed minor memory leak on gpuobj destruction
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      9274f4a9
  55. 15 6月, 2009 1 次提交
    • J
      drm/radeon: introduce kernel modesetting for radeon hardware · 771fe6b9
      由 Jerome Glisse 提交于 
      Add kernel modesetting support to radeon driver, use the ttm memory
manager to manage memory and DRM/GEM to provide userspace API.
In order to avoid backward compatibility issue and to allow clean
design and code the radeon kernel modesetting use different code path
than old radeon/drm driver.

When kernel modesetting is enabled the IOCTL of radeon/drm
driver are considered as invalid and an error message is printed
in the log and they return failure.

KMS enabled userspace will use new API to talk with the radeon/drm
driver. The new API provide functions to create/destroy/share/mmap
buffer object which are then managed by the kernel memory manager
(here TTM). In order to submit command to the GPU the userspace
provide a buffer holding the command stream, along this buffer
userspace have to provide a list of buffer object used by the
command stream. The kernel radeon driver will then place buffer
in GPU accessible memory and will update command stream to reflect
the position of the different buffers.

The kernel will also perform security check on command stream
provided by the user, we want to catch and forbid any illegal use
of the GPU such as DMA into random system memory or into memory
not owned by the process supplying the command stream. This part
of the code is still incomplete and this why we propose that patch
as a staging driver addition, future security might forbid current
experimental userspace to run.

This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
(radeon up to X1950). Works is underway to provide support for R6XX,
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).

Authors:
    Jerome Glisse <jglisse@redhat.com>
    Dave Airlie <airlied@redhat.com>
    Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      771fe6b9
  57. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      由 Dave Airlie 提交于 
      With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.

This restructures the drm along the lines of other kernel components.

It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c0e09200