From: Gustavo Padovan <gustavo@padovan.org>
To: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Daniel Stone" <daniels@collabora.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Riley Andrews" <riandrews@android.com>,
"Rob Clark" <robdclark@gmail.com>,
"Greg Hackmann" <ghackmann@google.com>,
"John Harrison" <John.C.Harrison@Intel.com>,
laurent.pinchart@ideasonboard.com, seanpaul@google.com,
marcheu@google.com, m.chehab@samsung.com,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [RFC 5/8] drm/fence: add fence to drm_pending_event
Date: Fri, 15 Apr 2016 11:59:00 -0700 [thread overview]
Message-ID: <20160415185900.GD23954@joana> (raw)
In-Reply-To: <20160415080948.GS2510@phenom.ffwll.local>
2016-04-15 Daniel Vetter <daniel@ffwll.ch>:
> On Thu, Apr 14, 2016 at 06:29:38PM -0700, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Now a drm_pending_event can either send a real drm_event or signal a
> > fence, or both. It allow us to signal via fences when the buffer is
> > displayed on the screen. Which in turn means that the previous buffer
> > is not in use anymore and can be freed or sent back to another driver
> > for processing.
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Do you have atomic igt testcase that exercise all the combinations of
> drm_event and in/out-fences and make sure it all keeps working? Tomeu
> already converted that over to be a generic testcase.
Not yet. I'll check for test cases.
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 19 +++++++++++++------
> > drivers/gpu/drm/drm_fops.c | 5 +++--
> > drivers/gpu/drm/drm_irq.c | 7 +++++++
> > include/drm/drmP.h | 1 +
> > 4 files changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 6702502..0b95526 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1431,7 +1431,8 @@ EXPORT_SYMBOL(drm_atomic_async_commit);
> > */
> >
> > static struct drm_pending_vblank_event *create_vblank_event(
> > - struct drm_device *dev, struct drm_file *file_priv, uint64_t user_data)
> > + struct drm_device *dev, struct drm_file *file_priv,
> > + struct fence *fence, uint64_t user_data)
> > {
> > struct drm_pending_vblank_event *e = NULL;
> > int ret;
> > @@ -1444,12 +1445,17 @@ static struct drm_pending_vblank_event *create_vblank_event(
> > e->event.base.length = sizeof(e->event);
> > e->event.user_data = user_data;
> >
> > - ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base);
> > - if (ret) {
> > - kfree(e);
> > - return NULL;
> > + if (file_priv) {
> > + ret = drm_event_reserve_init(dev, file_priv, &e->base,
> > + &e->event.base);
> > + if (ret) {
> > + kfree(e);
> > + return NULL;
> > + }
> > }
> >
> > + e->base.fence = fence;
> > +
> > return e;
> > }
> >
> > @@ -1676,7 +1682,8 @@ retry:
> > for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > struct drm_pending_vblank_event *e;
> >
> > - e = create_vblank_event(dev, file_priv, arg->user_data);
> > + e = create_vblank_event(dev, file_priv, NULL,
> > + arg->user_data);
> > if (!e) {
> > ret = -ENOMEM;
> > goto out;
> > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> > index aeef58e..38def49 100644
> > --- a/drivers/gpu/drm/drm_fops.c
> > +++ b/drivers/gpu/drm/drm_fops.c
> > @@ -801,8 +801,9 @@ void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e)
> > {
> > assert_spin_locked(&dev->event_lock);
> >
> > - if (!e->file_priv) {
> > - e->destroy(e);
> > + if (!e->file_priv || !e->event) {
>
> This would be a bug: e->file_priv != NULL iff e->event != NULL. How did
> this happen?
Not sure now. But I needed this to prevent a crash, I don't have logs of
it anymore, I'll check this again.
>
> > + if (e->destroy)
> > + e->destroy(e);
> > return;
> > }
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 3c1a6f1..0c5d7cb 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -41,6 +41,7 @@
> >
> > #include <linux/vgaarb.h>
> > #include <linux/export.h>
> > +#include <linux/fence.h>
> >
> > /* Access macro for slots in vblank timestamp ringbuffer. */
> > #define vblanktimestamp(dev, pipe, count) \
> > @@ -1124,6 +1125,12 @@ void drm_send_vblank_event(struct drm_device *dev, unsigned int pipe,
> > now = get_drm_timestamp();
> > }
> > e->pipe = pipe;
> > +
> > + if (e->base.fence) {
> > + fence_signal(e->base.fence);
> > + fence_put(e->base.fence);
> > + }
>
> I'd put this into drm_send_event_locked even. In case we send out fences
> for other events too (e.g. exynos uses drm_event for rendering ...).
Okay. Looking into that.
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Gustavo Padovan <gustavo@padovan.org>
To: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Daniel Stone" <daniels@collabora.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Riley Andrews" <riandrews@android.com>,
"Rob Clark" <robdclark@gmail.com>,
"Greg Hackmann" <ghackmann@google.com>,
"John Harrison" <John.C.Harrison@Intel.com>,
laurent.pinchart@ideasonboard.com, seanpaul@google.com,
marcheu@google.com, m.chehab@samsung.com,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [RFC 5/8] drm/fence: add fence to drm_pending_event
Date: Fri, 15 Apr 2016 11:59:00 -0700 [thread overview]
Message-ID: <20160415185900.GD23954@joana> (raw)
In-Reply-To: <20160415080948.GS2510@phenom.ffwll.local>
2016-04-15 Daniel Vetter <daniel@ffwll.ch>:
> On Thu, Apr 14, 2016 at 06:29:38PM -0700, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Now a drm_pending_event can either send a real drm_event or signal a
> > fence, or both. It allow us to signal via fences when the buffer is
> > displayed on the screen. Which in turn means that the previous buffer
> > is not in use anymore and can be freed or sent back to another driver
> > for processing.
> >
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Do you have atomic igt testcase that exercise all the combinations of
> drm_event and in/out-fences and make sure it all keeps working? Tomeu
> already converted that over to be a generic testcase.
Not yet. I'll check for test cases.
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 19 +++++++++++++------
> > drivers/gpu/drm/drm_fops.c | 5 +++--
> > drivers/gpu/drm/drm_irq.c | 7 +++++++
> > include/drm/drmP.h | 1 +
> > 4 files changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 6702502..0b95526 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1431,7 +1431,8 @@ EXPORT_SYMBOL(drm_atomic_async_commit);
> > */
> >
> > static struct drm_pending_vblank_event *create_vblank_event(
> > - struct drm_device *dev, struct drm_file *file_priv, uint64_t user_data)
> > + struct drm_device *dev, struct drm_file *file_priv,
> > + struct fence *fence, uint64_t user_data)
> > {
> > struct drm_pending_vblank_event *e = NULL;
> > int ret;
> > @@ -1444,12 +1445,17 @@ static struct drm_pending_vblank_event *create_vblank_event(
> > e->event.base.length = sizeof(e->event);
> > e->event.user_data = user_data;
> >
> > - ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base);
> > - if (ret) {
> > - kfree(e);
> > - return NULL;
> > + if (file_priv) {
> > + ret = drm_event_reserve_init(dev, file_priv, &e->base,
> > + &e->event.base);
> > + if (ret) {
> > + kfree(e);
> > + return NULL;
> > + }
> > }
> >
> > + e->base.fence = fence;
> > +
> > return e;
> > }
> >
> > @@ -1676,7 +1682,8 @@ retry:
> > for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > struct drm_pending_vblank_event *e;
> >
> > - e = create_vblank_event(dev, file_priv, arg->user_data);
> > + e = create_vblank_event(dev, file_priv, NULL,
> > + arg->user_data);
> > if (!e) {
> > ret = -ENOMEM;
> > goto out;
> > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> > index aeef58e..38def49 100644
> > --- a/drivers/gpu/drm/drm_fops.c
> > +++ b/drivers/gpu/drm/drm_fops.c
> > @@ -801,8 +801,9 @@ void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e)
> > {
> > assert_spin_locked(&dev->event_lock);
> >
> > - if (!e->file_priv) {
> > - e->destroy(e);
> > + if (!e->file_priv || !e->event) {
>
> This would be a bug: e->file_priv != NULL iff e->event != NULL. How did
> this happen?
Not sure now. But I needed this to prevent a crash, I don't have logs of
it anymore, I'll check this again.
>
> > + if (e->destroy)
> > + e->destroy(e);
> > return;
> > }
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 3c1a6f1..0c5d7cb 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -41,6 +41,7 @@
> >
> > #include <linux/vgaarb.h>
> > #include <linux/export.h>
> > +#include <linux/fence.h>
> >
> > /* Access macro for slots in vblank timestamp ringbuffer. */
> > #define vblanktimestamp(dev, pipe, count) \
> > @@ -1124,6 +1125,12 @@ void drm_send_vblank_event(struct drm_device *dev, unsigned int pipe,
> > now = get_drm_timestamp();
> > }
> > e->pipe = pipe;
> > +
> > + if (e->base.fence) {
> > + fence_signal(e->base.fence);
> > + fence_put(e->base.fence);
> > + }
>
> I'd put this into drm_send_event_locked even. In case we send out fences
> for other events too (e.g. exynos uses drm_event for rendering ...).
Okay. Looking into that.
Gustavo
next prev parent reply other threads:[~2016-04-15 18:59 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 1:29 [RFC 0/8] drm: explicit fencing support Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 1:29 ` [RFC 1/8] dma-buf/fence: add fence_collection fences Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 8:02 ` Daniel Vetter
2016-04-15 8:02 ` Daniel Vetter
2016-04-15 9:03 ` Christian König
2016-04-15 9:03 ` Christian König
2016-04-15 11:44 ` Daniel Vetter
2016-04-15 11:44 ` Daniel Vetter
2016-04-15 18:29 ` Gustavo Padovan
2016-04-15 18:29 ` Gustavo Padovan
2016-04-15 19:23 ` Daniel Vetter
2016-04-15 19:23 ` Daniel Vetter
2016-04-15 18:27 ` Gustavo Padovan
2016-04-15 18:27 ` Gustavo Padovan
2016-04-15 19:25 ` Daniel Vetter
2016-04-15 19:25 ` Daniel Vetter
2016-05-18 7:07 ` Christian König
2016-05-18 7:07 ` Christian König
2016-05-18 14:30 ` Gustavo Padovan
2016-04-15 1:29 ` [RFC 2/8] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 7:56 ` Daniel Vetter
2016-04-15 7:56 ` Daniel Vetter
2016-04-15 1:29 ` [RFC 3/8] drm/fence: allow fence waiting to be interrupted by userspace Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 7:47 ` Daniel Vetter
2016-04-15 7:47 ` Daniel Vetter
2016-04-15 1:29 ` [RFC 4/8] drm/fence: add in-fences support Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 8:05 ` Daniel Vetter
2016-04-15 8:05 ` Daniel Vetter
2016-04-15 18:40 ` Gustavo Padovan
2016-04-15 18:40 ` Gustavo Padovan
2016-04-15 8:11 ` Daniel Vetter
2016-04-15 8:11 ` Daniel Vetter
2016-04-15 1:29 ` [RFC 5/8] drm/fence: add fence to drm_pending_event Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 8:09 ` Daniel Vetter
2016-04-15 8:09 ` Daniel Vetter
2016-04-15 18:59 ` Gustavo Padovan [this message]
2016-04-15 18:59 ` Gustavo Padovan
2016-04-15 19:31 ` Daniel Vetter
2016-04-15 19:31 ` Daniel Vetter
2016-04-15 1:29 ` [RFC 6/8] drm/fence: create DRM_MODE_ATOMIC_OUT_FENCE flag Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 1:40 ` Rob Clark
2016-04-15 1:40 ` Rob Clark
2016-04-15 19:05 ` Gustavo Padovan
2016-04-15 19:05 ` Gustavo Padovan
2016-04-15 1:29 ` [RFC 7/8] drm/fence: create per-crtc sync_timeline Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 1:29 ` [RFC 8/8] drm/fence: add out-fences support Gustavo Padovan
2016-04-15 1:29 ` Gustavo Padovan
2016-04-15 8:18 ` Daniel Vetter
2016-04-15 8:18 ` Daniel Vetter
2016-04-15 19:15 ` Gustavo Padovan
2016-04-15 19:15 ` Gustavo Padovan
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=20160415185900.GD23954@joana \
--to=gustavo@padovan.org \
--cc=John.C.Harrison@Intel.com \
--cc=arve@android.com \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ghackmann@google.com \
--cc=gustavo.padovan@collabora.co.uk \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marcheu@google.com \
--cc=riandrews@android.com \
--cc=robdclark@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.