On 01/09/2017 07:34 PM, Sergei Shtylyov wrote: > Hello! > > On 01/09/2017 07:39 PM, Alexandre Bailon wrote: > >> The dma may hung up if a teardown is initiated while an endpoint is still > > The DMA may hang up... > >> active (Advisory 2.3.27 of da8xx errata). >> To workaround this issue, add a delay before to initiate the teardown. >> >> Signed-off-by: Alexandre Bailon <abailon@xxxxxxxxxxxx> > [...] >> diff --git a/drivers/usb/musb/musb_cppi41.c >> b/drivers/usb/musb/musb_cppi41.c >> index 1636385..8fdbc17 100644 >> --- a/drivers/usb/musb/musb_cppi41.c >> +++ b/drivers/usb/musb/musb_cppi41.c >> @@ -547,6 +547,10 @@ static int cppi41_dma_channel_abort(struct >> dma_channel *channel) >> } >> } >> >> + /* DA8xx Advisory 2.3.27: wait 250 ms before to start the >> teardown */ >> + if (musb->io.quirks & MUSB_DA8XX) >> + mdelay(250); > > This is a horrible workaround, not even msleep()... Indeed, that's a bad workaround but have not found a better one. cppi41_dma_channel_abort() is called from atomic context, so we can't use msleep(). And update the musb driver to call cppi41_dma_channel_abort() from process context would require too many changes. Best Regards, Alexandre > > [...] > > MBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
