david-b@pacbell.net said:
> - Implementation-wise, I'm rather surprised that the generic
> version doesn't just add new bus driver methods rather than
> still insisting everything be PCI underneath.
You mean dma-mapping.h in asm-generic? The reason for that is to provide an
implementation that functions now for non x86 (and non-parisc) archs without
having to write specific code for them all. Since all the other arch's now
function in terms of the pci_ API, that was the only way of sliding the dma_
API in without breaking them all.
Bus driver methods have been advocated before, but it's not clear to me that
they should be exposed in the *generic* API.
> It's not clear to me how I'd make, for example, a USB device
> or interface work with dma_map_sg() ... those "generic" calls
> are going to fail (except on x86, where all memory is DMA-able)
> since USB != PCI.
Actually, they should work on parisc out of the box as well because of the way
its DMA implementation is built in terms of the generic dma_ API.
As far as implementing this generically, just adding a case for the
usb_bus_type in asm-generic/dma-mapping.h will probably get you where you need
to be. (the asm-generic is, after all, only intended as a stopgap. Fully
coherent platforms with no IOMMUs will probably take the x86 route to
implementing the dma_ API, platforms with IOMMUs will probably (eventually) do
similar things to parisc).
> (The second indirection: the usb controller hardware does the
> mapping, not the device or hcd. That's usually PCI.)
Could you clarify this a little. I tend to think of "mapping" as something
done by the IO MMU managing the bus. I think you mean that the usb controller
will mark a region of memory to be accessed by the device. If such a region
were also "mapped" by an IOMMU, it would be done outside the control of the
USB controller, correct? (the IOMMU would translate between the address the
processor sees and the address the USB controller thinks it's responding to)
Is the problem actually that the USB controller needs to be able to allocate
coherent memory in a range much more narrowly defined than the current
dma_mask allows?
> - There's no analogue to pci_pool, and there's nothing like
> "kmalloc" (likely built from N dma-coherent pools).
I didn't want to build another memory pool re-implementation. The mempool API
seems to me to be flexible enough for this, is there some reason it won't work?
I did consider wrappering mempool to make it easier, but I couldn't really
find a simplifying wrapper that wouldn't lose flexibility.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:11 EST