Hi, >Subject: RE: [PATCH 2/5] musb: use system DMA to fix Inventra DMA issue on > RTL-1.4 > > Felipe Balbi wrote: > > On Wed, May 12, 2010 at 05:19:36PM +0530, Ajay Kumar Gupta wrote: > > > MUSB RTL version 1.4 has a hardware issue when TX and RX DMA channels > are > > > simultaneously enabled which results in DMA lockup. > > > > I've seen it on rtl1.8 also if I remember correctly. > > > > I'm fairly certain that this is not the case with RTL1.8, and if it is I'm > very > much interested in getting to the bottom of it. Do you have a test case > that reproduces the lockup? Or a description of your use-case, or > a register dump at failure, or any other clues? > Felipe, I have also not seen lockup issue on rtl1.8. Can you provide more detail on your test case as Anand asked? > > > Use system DMA for all RX channels as a workaround of this issue as > this > > > will have minimal throughput overhead based on the fact that Rx > transfers > > > are done in DMA mode-0 on OMAP34x/35x platforms. > > > > > > Another approach to use PIO mode in opposite direction would increase > the > > > cpu loading and thus using system DMA is preferred workaround. > > > > > > Signed-off-by: Anand Gadiyar <gadiyar@xxxxxx> > > > Signed-off-by: Ajay Kumar Gupta <ajay.gupta@xxxxxx> > > > > I think falling back to pio is better than this patch. At the cost of cpu, which certainly is not preferred. >> It will most likely be only one transfer. How about host mode with multiple devices connected and doing transfers? Falling back to PIO would kill the cpu. >> Another approach is to allocate dma channels on a transfer basis. Can you elaborate this? >> This is way too big of a problem. If we think of the scenarios in host mode then certainly using system DMA is best approach. -Ajay > Which one is better depends on how many endpoints are doing, > transfers in parallel, I suppose. > > I did post the a patch for the other approach (to fall back to PIO). > I haven't received a response to that yet. I'm okay with either approach. > > > - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
