[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161027112519.GJ12629@joana>
Date: Thu, 27 Oct 2016 09:25:19 -0200
From: Gustavo Padovan <gustavo@...ovan.org>
To: Brian Starkey <brian.starkey@....com>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org
Subject: Re: [RFC PATCH v2 9/9] drm: mali-dp: Add writeback out-fence support
2016-10-27 Brian Starkey <brian.starkey@....com>:
> On Wed, Oct 26, 2016 at 07:43:57PM -0200, Gustavo Padovan wrote:
> > 2016-10-26 Brian Starkey <brian.starkey@....com>:
> >
> > > If userspace has asked for an out-fence for the writeback, we add a
> > > fence to malidp_mw_job, to be signaled when the writeback job has
> > > completed.
> > >
> > > Signed-off-by: Brian Starkey <brian.starkey@....com>
> > > ---
> > > drivers/gpu/drm/arm/malidp_hw.c | 5 ++++-
> > > drivers/gpu/drm/arm/malidp_mw.c | 18 +++++++++++++++++-
> > > drivers/gpu/drm/arm/malidp_mw.h | 3 +++
> > > 3 files changed, 24 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> > > index 1689547..3032226 100644
> > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > @@ -707,8 +707,11 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
> > > unsigned long irqflags;
> > > /*
> > > * We can't unreference the framebuffer here, so we queue it
> > > - * up on our threaded handler.
> > > + * up on our threaded handler. However, signal the fence
> > > + * as soon as possible
> > > */
> > > + malidp_mw_job_signal(drm, malidp->current_mw, 0);
> >
> > Drivers should not deal with fences directly. We need some sort of
> > drm_writeback_finished() that will do the signalling for you.
> >
>
> With a signature like this?
> drm_writeback_finished(struct drm_connector_state *state);
>
> I'll have to think about how to achieve that. The state isn't
> refcounted and the driver isn't in charge of it's lifetime. I'm not
> sure how/where to ensure the state doesn't get destroyed before its
> been signaled.
Maybe we should do something similar to the crtc vblank handlers and
even hide the connector_state. Those helpers only take the crtc.
They are able to hold ref to the event as well.
Gustavo
Powered by blists - more mailing lists