On Mon, Mar 28, 2011 at 06:17, Felipe Balbi wrote: > On Mon, Mar 28, 2011 at 06:09:38AM -0400, Mike Frysinger wrote: >> On Mon, Mar 28, 2011 at 06:04, Felipe Balbi wrote: >> > On Mon, Mar 28, 2011 at 05:57:21AM -0400, Mike Frysinger wrote: >> >> On Mon, Mar 28, 2011 at 05:42, Felipe Balbi wrote: >> >> > On Mon, Mar 28, 2011 at 05:26:46AM -0400, Mike Frysinger wrote: >> >> >> >> any ideas on how to get this workaround merged ? Âanother idea i had >> >> >> >> was that we could add a hook to the top of dma_channel_program to let >> >> >> >> targets muck with the arguments ... the Blackfin code would just need >> >> >> >> to do something like this at the start of the func: >> >> >> >> + Â if (musb_channel->transmit && channel->desired_mode == 1) >> >> >> >> + Â Â Â len = len - (len % packet_sz); >> >> >> > >> >> >> > is that IP-related or Blackfin-only ? I mean, does this bug affects all >> >> >> > MUSB of a particular RTL version or only the Blackfin ones ? >> >> >> >> >> >> our understanding of the issue is that it is Blackfin specific. Âseems >> >> >> to be related to our internal bus/dma connections to the musb ip. >> >> > >> >> > ok. So we need a way to understand we need to apply that workaround only >> >> > on blackfin. There we go with another blackfin-only driver flag... >> >> >> >> seems a shame to add a flag that will always evaluate to false for >> >> non-Blackfin targets yet needs to be runtime checked for everyone ... >> > >> > I'm not keen in having ifdefs... Any other suggestions ? >> >> originally i was going to hijack the dma_channel_program pointer in >> the Blackfin init, but dma_controller_create gets called too late for >> that. >> >> so i was thinking a new func pointer in musb_platform_ops like >> "pre_channel_program" which the normal dma_channel_program function >> would check/call at the top. Âso i guess you might end up with the >> same overhead for the most part (a logic test must occur), but at >> least this way other people would be able to extend it if their own >> needs called for it ? > > Could be. MUSB has so many different bugs that most likely someone else > might need this anyway. since we seem to agree on this, i'll send a patch :) -mike -- 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
