Re: musb: handling Blackfin anomaly 05000450

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux