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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux