Linux/OMAP-L138: Long delay in cppi41_dma_channel_abort causing application level errors

Part Number:OMAP-L138

Tool/software: Linux

I am working with a custom board designed around the OMAP-L138, running linux. Upon experiencing application level issues (CPU starvation) during  USB disconnects, I traced the cause down to cppi41_dma_channel_abort (in drivers/usb/musb/musb_cppi41.c). This function is being run in atomic context with all irqs blocked and there is a long mdelay:

	/* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
	if (musb->io.quirks & MUSB_DA8XX)
		mdelay(250);

It seems like a bad idea to have such a long delay run in this context. I have tried searching around to find more information on the origins or necessity of this delay, but there was little information in the referenced advisory and the comments accompanying the commit to linux-davinci (593bc4622a98c172dbb939103aef917d1800a663)  don't provide much detail.  I would like to know:

How necessary is this delay, and what are the risks run in removing it? I ask because this is causing my applications to experience CPU starvation, and if this is only in place to catch an edge-case issue that is only seen during a very specific use case, the best option might be to do without. 

I am hoping someone here has more knowledge of this driver than I do, and I would appreciate any additional information or suggestions.

Thank you,

Note: If this is not the correct forum for such a question, please correct me. This is my first post.