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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
