[PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Fri, Jun 10, 2016 at 01:23:22PM +0000, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Thu, 2016-06-09 at 16:37 +0200, Daniel Vetter wrote:
> > On Thu, Jun 9, 2016 at 4:31 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > 
> > > On Thu, Jun 9, 2016 at 4:29 PM, Alexey Brodkin
> > > <Alexey.Brodkin at synopsys.com> wrote:
> > > > 
> > > > Hi Daniel,
> > > > 
> > > > On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
> > > > > 
> > > > > 
> > > > > The fake implementation is fundamentally racy, and I don't want to write
> > > > > helpers which can't be used correctly. Anyway I think without this patch
> > > > > (or something similar) arcpgu will stall badly with the new nonblocking
> > > > > helpers, because arcpgu didn't bother at all to implement nonblocking. Can
> > > > > you pls ack this, or even better, test the entire patch series? The
> > > > > helpers themselves should work, but in all 5 drivers tested thus far they
> > > > > discovered some bugs.
> > > > Sure I will happily test this series.
> > > > The only question then is what should I use as a proper base?
> > > It should apply on drm-next from Dave.
> >
> > And indeed it won't work at all because arcpgu doesn't call
> > drm_crtc_handle_vblank anywhere. So you need to add your patch to
> > enable vblank interrupts somewhere. Note that as long as you leave
> > max_vblank_counter as 0, the only bits you need is drm_vblank_init and
> > drm_crtc_handle_vblanke() from the irq handler.
> 
> So is there any sense in testing that series if vblank interrupt is not yet
> supported (I'm looking forward to implementing it sometime soon but definitely
> I'm not there yet)?

Well, it might break your driver, so yes. I'm ofc happy to help unbreak it,
but without someone who tests there's not much I can do, so will just go
ahead and apply and hope it works.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch