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]

 



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



[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