On Fri, Jan 23, 2009 at 01:47:35PM -0800, David Brownell wrote:
> On Friday 23 January 2009, Sergei Shtylyov wrote:
> > >>>+ cppi_ch->channel.actual_len = 0;
> >
> > Wait, Shouldn't that be set by the musb_{host|gadget}.c? It indeed is. But
> > musb_gadget doesn't do it...
> > To be consistent, we should now remove the duplicate setting in
> > mush_host.c as tusb6010_omap.c does set this field itself too.
>
> Actually I'd be all for initializing it in only one place ...
sure
> ... but that implies a substantial cleanup of the DMA paths,
> and I'll be content to defer such only-one-place cleanup until
> that happens.
for sure today's code is really messy. All those ifs and ifdefery to
check which dma we're using look awful...
>
> To summarize, musb_hdrc has four basic DMA paths today, the
> cross product of {RX, TX} and {host, gadget}, each of which
> looks more or less like
>
> if (cppi/davinci)
> do this
> else if (omap native/TUSB)
> do that
> else if (mentor's DMA)
> do something else
... I'm trying to move that to something like:
if (use_dma)
do_this();
else
do_pio();
So that it would be, on musb side, all be running the same code and the
dma-specific code should handle the peculiarities of itself. It's been a
hard work clean up all that code and so far I'm testing only on mentor
graphics dma, when I get mentor fully working with mode i'll check
tusb6010 and later davinci with cppi.
--
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
