Re: [PATCH][1/4] usb: dma bounce buffer support using HCD_BOUNCE flag

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

On Jan 15, 2008 4:35 PM, David Brownell <david-b@xxxxxxxxxxx> wrote:
> On Monday 14 January 2008, Magnus Damm wrote:
> > On Jan 14, 2008 1:03 PM, David Brownell <david-b@xxxxxxxxxxx> wrote:
> > > Could you talk a bit more about why that approach isn't appropriate
> > > here?  My first guess would be that it just costs too much, and
> > > this is used on systems without manny spare resources.  Including
> > > for example ones where the memcpy overheads would hurt battery
> > > lifetimes, even if there were spare CPU cycles.
> >
> > The sm501 chip can be hooked up to several different architectures,
> > and it can be attached to the system in multiple ways.
>
> ... so it needs something not specific to the ARM or SH support.

Right. I think that's the right way forward at least. =)

> > I have some pci
> > cards here that are equipped with sm501/sm502 using pci. I use them on
> > x86. Then I have some embedded sh boards from renesas where the sm501
> > is hooked up using a local bus (just a CS bank I think). The sm501 is
> > equipped with local memory in both cases,
>
> That is, a private bank of DRAM rather than a block of SRAM
> integrated onto that chip?  That's a slightly different model
> than I've usually seen with USB, but not uncommon otherwise.

Actually, I'm not sure if it's on-chip or not. I've been trying to
locate the ram chips on my pci board, but I can't find any.

According to some text written on the pcb it should be possible to
have 16-256 MB of external SDRAM. WIthout finding any ram chips I
still seem to have 8 MB memory for frame buffer and usb host data. On
top of that there should be 16k of on-chip SRAM attached to some 8051
microcontroller block.

> And there are advantages to having a DRAM controller and using
> external RAM, instead of what's usually a way-too-small block
> of expensive SRAM.  (Unless board real estate is very tight,
> or the system is designed for _very_ low power operation.)
>
>
> >                                    and the device is unable to
> > do dma to other parts of the system memory - at least that's true when
> > it's hooked up on the local bus.
>
> If it's just hooked up as a slave CS bank, rather than through some
> symmetric interface supporting bus mastering, that'd make sense.

Right. One of the ways to hook up the sm501 chip seems to be "slave
mode". Good luck trying to do any dma there. =)

> > I think that applies for the pci
> > configuration as well, but I there may be some magic pci bus mastering
> > mode that i'm unaware of.
>
> The SM502 seems to have a DMA controller that can be a PCI bus master,
> or use local memory (DRAM possibly shared with the framebuffer).  I'd
> expect it to just use standard PCI bus mastering ... though you might
> need special PCI bus glue if its OHCI isn't presented the normal way.

I've tested the ohci-sm501 driver using both pci interface on x86 and
in "slave mode" on sh4. Both work just fine. Maybe it's possible to
optimize by copying data using the sm501 dma controller in pci mode,
but I wonder if standard pci bus mastering will work - the sm501 ohci
controller seems to expect a local memory offset instead of physical
address for dma. This regardless of bus type. I have not tried playing
around with bus mastering and pci though.

> I'm not surprised they didn't _also_ do the work needed to sync up with
> some external DMA engine.  The sort where a peripheral raises its DMA
> request line to load/unload its data, and then gives Linux fits because
> the drivers/dma/* code doesn't (yet) believe such engines exist.  ;)
>
>
> > So using architecture specific DMA mapping operations is of course
> > always an option, but since the chip can be hooked up to all sorts of
> > architectures i think it makes more sense to make it architecture
> > independent. The only requirement for the architecture would be to
> > have dma_declare_coherent_memory() support, and that interface seems
> > to fit perfectly for our needs in this case.
>
> Although I don't think there's necessarily a requirement that such
> memory be given a dma-coherent mapping in kernel address space.
> It's really no different than any other chunk of DRAM.  (Right?
> The SM50x chip acts as a bridge to that local memory bank.)

I may read Documentation/DMA-mapping.txt wrong, but I think this
coherent mapping means that the sm501 sees the same data as the cpu
and no cache flush is required.

> The relevant points here being that there is current infrastructure
> to declare device-local memory that's suitable for DMA ... and that
> it may be the only memory suitable for such DMA, depending on the
> board architecture.  So to use it, we have to go through the dma
> coherent allocators.

Right. The term dma is a bit fuzzy in my mind since it is used to
describe both pci bus mastering dma and good old "manual" dma with dma
channels and various alignment, location and size restrictions for the
memory. The DMA-mapping.txt document says that all physically
contiguous buffers that are allocated using kmalloc() or
__get_free_page() are ok for DMA. That may be true for the PCI type of
bus mastering dma (which the document describes), but it's certainly
not true for the sm501 in slave mode. To use the usb host in sm501 we
need dma, and all data needs to be allocated from the local memory for
that dma to work. Basically, the usb core code seems to be designed
with pci bus mastering dma in mind.

> > I also suspect that other usb host controllers exist with similar
> > requirements, so having host controller and architecture independent
> > support may be a good idea for other devices as well.
>
> The example I gave was the NXP/Philips ISP chips targetted at
> embedded systems ... which seem to require all DMA to be from
> their own (tiny) SRAMs.  There are other embedded HCs I've seen
> on discrete add-on chips which adopt that same model.  When the
> HC is better integrated (part of an SOC) it tends to get rid
> of such restrictions and have access to the same address space
> everything else does.  (IOMMUs there are uncommon.)

Exactly.

> > Any comments? Can I just change the name of the flag to HCD_LOCAL_MEM
> > and repost?
>
> OK by me.  Maybe a few other folk have opinions though ... Alan?

Great, thanks. I'll repost later this week unless there are any objections.

/ magnus

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel