On Thu, Oct 27, 2016 at 09:25:19AM -0200, Gustavo Padovan wrote: > 2016-10-27 Brian Starkey <brian.starkey at arm.com>: > > > On Wed, Oct 26, 2016 at 07:43:57PM -0200, Gustavo Padovan wrote: > > > 2016-10-26 Brian Starkey <brian.starkey at arm.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 at arm.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.
I guess we could reuse the drm_event stuff, but not sure that's too much overkill. It would at least be a consistent driver interface, and drivers could reuse stuff like arm_event and similar functions. Which might be rather beneficial. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
