[PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 4 April 2018 13:50:43 EEST Tomi Valkeinen wrote:
> On 04/04/18 00:11, Laurent Pinchart wrote:
> >> +	dma_async_issue_pending(dmm->wa_dma_chan);
> >> +	status = dma_sync_wait(dmm->wa_dma_chan, cookie);
> > 
> > dma_sync_wait() has a 5s timeout. You're calling this function with a
> > spinlock held. The end result might be slightly better than a complete
> > system lock as caused by the bug described in i878, but only slightly.
> 
> When does the timeout trigger? I presume it only happens when things are
> badly broken on the HW or driver level, and when things work normally,
> the wait is very short.

It shouldn't happen when things go right, and I indeed expect the transfer to 
complete quite fast. I would however like to get real numbers there, we should 
measure how long the transfer typically takes.

> > Unless I'm mistaken the reason you can't sleep here is because of the need
> > to access registers in the interrupt handler. Could we use threaded IRQs
> > to solve this ?
> 
> Yes, I think that's the reason. Probably we could use threaded IRQs.
> 
> Also, I'm not sure if this is a big issue. If the dma_sync_wait
> timeouts, things are already rather broken. Then again, any wait in an
> irq context is not that nice. But if the wait is just a few loops long,
> it's not really even a wait...

-- 
Regards,

Laurent Pinchart