Re: usb and no bus_dma(9)

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

On Tue, Mar 15, 2011 at 12:15:47AM +0900, Izumi Tsutsui wrote:
> > > > > > Our usb driver demands bus_dma(9) without fail.  However, slhci(4)
> > > > > > doesn't use DMA.  Moreover, some ports is not supporting bus_dma(9)
> > > > > > now.
> > > > > Isn't it easy to provide a bus_dma implementation that does not realy
> > > > > do dma?
> > > > > That would be far preferable to crippling lots of other code with MD 
> > > > > hacks,
> > > > > IMHO.
> > > > 
> > > > I think that it is strange to implement bus_dma(9) for port that doesn't
> > > > use DMA.
> > > 
> > > For compromise, how about:
> > >  - use "#if NUHCI > 0 || NOHCI > 0 || NEHCI > 0" (or so) in *.c sources
> > 
> > That's not as bad as the original #ifdef mmeye stuff, but still, ew...
> > If your point is to avoid including some DMA code when usb is not included,
> 
> The point is "usb* at slhci?" is usb but it doesn't use DMA,
> unlike uhci/ohci/ehci.

That seems like a rather poor reason for causing all usb devices to know about
slhci or the architecture it runs on then.  You already have a rather unwieldy
set of conditions in the #if statement, and it'll break if anyone ever adds
another usb controller driver.

> > can that be done with config attributes instead?
> > i.e. in arch/mmeye/conf/files.mmeye do:
> > file common/bus_dma/bus_dmamem_common.c   usb
> What does it solve??

Sorry, I thought you were saying that the #ifdef N?HCI lines would go in the
bus_dma code.

> 
> > Perhaps you're focusing too much on the literal "dma" part of "bus_dma".
> > The man page for bus_dma_alloc says it 'Allocates memory that is "DMA 
> > safe"...'
> > but if the hardward doesn't do DMA, it seems reasonable to declare that 
> > any memory allocated with malloc() is "safe".
> 
> That's what Kiyohara's patch does, isn't it?
> I'm suggesting to use #ifdef N?HCI instead of #ifdef mmeye.

The problem is that it does it in a rather ugly way.  
My understanding of bus_dma is that it is supposed to be the abstraction that
allows you to avoid having machine specific hacks in code that doesn't need it.
Does the idea of "put data in a memory region to have the hardware access it"
still apply with the slhci driver?  If yes, then the fact that the hardware
isn't doing literal "DMA" is irrelevant.  If no, then there's probably a lot
more re-writing that needs to be done to get any individual usb device drive
to work with it.

eric