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. > 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... Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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
