Hi Guennadi-san,
2012/02/04 0:43, Guennadi Liakhovetski wrote:
The current renesas_usbhs driver triggers
BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102
with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from an atomic (tasklet) context, which is not supported by the shdma dmaengine driver. Fix it by switching to a work. Also simplify some list manipulations.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski@gmx.de
Shimoda-san, this is the problem, that you were observing. However, it exists with the present version of shdma just as well as with the new one
- on top of the simple DMA library. I marked it an RFC because (1) I only
lightly tested it with the gadget device on mackerel with the mass storage gadget, and (2) I am somewhat concerned about races. Currently the work function runs with no locking and there are no usual cancel_work_sync() points in the patch. However, it has also been like this before with the tasklet implementation, which is not much better, and it looks like there are no asynchronous operations on the same packets like timeouts. Only asynchronous events, that I can think about are things like unloading the driver or unplugging the cable, but these have been there before too. It would become worse on SMP, I think. Comments welcome.
Thank you for the patch and comments. I also tested this patch using the g_mass_storage and g_ether. About your points, I think so, too. So, I will write such a code.
Best regards, Yoshihiro Shimoda