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 ? -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
