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...