mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Sean Paul <seanpaul@google.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	"Stéphane Marchesin" <marcheu@google.com>,
	"Daniel Stone" <daniels@collabora.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"John Harrison" <John.C.Harrison@intel.com>,
	m.chehab@samsung.com
Subject: Re: [PATCH v3] drm/fence: allow fence waiting to be interrupted by userspace
Date: Mon, 12 Sep 2016 11:23:32 -0300	[thread overview]
Message-ID: <20160912142332.GB12271@joana> (raw)
In-Reply-To: <CAOw6vbLxyPOCoF4GQSyZEaM1z376grWp=PMRkP+Mv6_n_Jxdkw@mail.gmail.com>

Hi Sean,

2016-09-12 Sean Paul <seanpaul@google.com>:

> On Thu, Aug 25, 2016 at 12:47 PM, Gustavo Padovan <gustavo@padovan.org> wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > If userspace is running an synchronously atomic commit and interrupts the
> > atomic operation during fence_wait() it will hang until the timer expires,
> > so here we change the wait to be interruptible so it stop immediately when
> > userspace wants to quit.
> >
> > Also adds the necessary error checking for fence_wait().
> >
> > v2: Comment by Daniel Vetter
> >         - Add error checking for fence_wait()
> >
> > v3: Rebase on top of new atomic noblocking support
> >
> > v4: Comment by Maarten Lankhorst
> >         - remove 'swapped' bitfield as it was duplicating information
> >
> > v5: Comments by Maarten Lankhorst
> >         - assign plane->state to plane_state if !intr
> >         - squash previous patch into this one
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 42 +++++++++++++++++++++++++++++--------
> >  drivers/gpu/drm/msm/msm_atomic.c    |  2 +-
> >  include/drm/drm_atomic_helper.h     |  5 +++--
> >  3 files changed, 37 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index e1f5de2..f752f9c 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1007,29 +1007,47 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
> >   * drm_atomic_helper_wait_for_fences - wait for fences stashed in plane state
> >   * @dev: DRM device
> >   * @state: atomic state object with old state structures
> > + * @intr: if true, do an interruptible wait
> >   *
> >   * For implicit sync, driver should fish the exclusive fence out from the
> >   * incoming fb's and stash it in the drm_plane_state.  This is called after
> >   * drm_atomic_helper_swap_state() so it uses the current plane state (and
> >   * just uses the atomic state to find the changed planes)
> > + *
> > + * Returns zero if sucess or < 0 if fence_wait() fails.
> >   */
> > -void drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > -                           struct drm_atomic_state *state)
> > +int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > +                                      struct drm_atomic_state *state,
> > +                                      bool intr)
> >  {
> >         struct drm_plane *plane;
> >         struct drm_plane_state *plane_state;
> > -       int i;
> > +       int i, ret;
> >
> >         for_each_plane_in_state(state, plane, plane_state, i) {
> > -               if (!plane->state->fence)
> > +               /*
> > +                * If the caller asks for an interruptible wait it means
> > +                * that the state were not swapped yet and the operation
> > +                * can still be interrupted by userspace, so we need
> > +                * to look to plane_state instead.
> > +                */
> > +               if (!intr)
> > +                       plane_state = plane->state;
> 
> The "intr" name is tripping me up here, since it doesn't _really_ imply that the
> state hasn't been swapped yet (this is just an implementation detail
> of the caller(s).
> 
> Perhaps we could change the name to "pre_swap", and remove the comment
> above this conditonal. Below, above
> fence_wait, add a new comment to the effect of:
> 
> /*
>  * If waiting for fences pre-swap (ie: nonblock), userspace can still interrupt
>  * the operation. Instead of blocking until the timer expires, make the wait
>  * interruptible.
>  */

Indeed, that is much better naming. In this case specifically intr has
the same meaning as pre_swap, but as you said it is an implementation
detail and we need to avoid people to get it wrong.

I'll update it and send a v4.

Gustavo

      reply	other threads:[~2016-09-12 14:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 16:47 Gustavo Padovan
2016-09-12 13:32 ` Maarten Lankhorst
2016-09-12 14:13 ` Sean Paul
2016-09-12 14:23   ` Gustavo Padovan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160912142332.GB12271@joana \
    --to=gustavo@padovan.org \
    --cc=John.C.Harrison@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=marcheu@google.com \
    --cc=seanpaul@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®