Felipe Balbi wrote: > Subbrathnam, Swaminathan wrote: > > This issue is specific to Blackfin architecture. Platforms like > > DaVinci, OMAP etc. do not have this restriction or have not > > observed any hangs in double buffering mode. > > > > I do not see the change implemented specific Blackfin context. > > Pl. modify the patch accordingly. > > NAK. I have observed data corruption when using double buffering on > tusb6010, omap3430 and omap3630. > Sorry, I did not catch this earlier before this patch was merged. Bringing this issue back up, do you have details on the data corruption seen? Did you have both TX and RC double-buffering enabled, or only one at a time? It could be that only one direction is problematic and this patch prevents us from even attempting double-buffering on the other direction. tusb6010 and the OMAPs have dynamic fifo, so the problem can be taken care of simply by choosing the correct fifo table. Default tables don't use double buffering, so they should not be affected. In blackfin's case, maybe it makes more sense to use the newly register bits that explicitly disable double buffering. I believe these were added specifically to take care of the scenario blackfin faces - not having dynamic fifo. Would anyone with a blackfin system care to test such a patch? I can post it in a bit. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
