Re: DMA API issues

[James Bottomley]

On Fri, 2004-06-18 at 14:22, Jamey Hicks wrote:
> It's really not a question of laziness.  The ASICs we are interested in 
> implement OHCI, so I think the core OHCI driver should work unmodified.  
> OHCI driver allocates dma_pools for managing endpoint descriptors (ED) 
> and transaction descriptors (TD).  I expect that the driver wrapper that 
> initializes the OHCI controller driver will create dma_pools drawing 
> from the ASIC's private SRAM.  The OHCI driver uses 
> dma_{alloc,free}_coherent to manage the space used for the top level 
> control structure shared between the driver and the controller 
> hardware.  This also needs to be allocated in the SRAM.  Finally, in 
> drivers/usb/core/usb.c, the USB drivers call dma_map_single and 
> dma_unmap_single given pointers to transfer buffers allocated by the USB 
> device drivers.  If the USB device is a network device (as it is on the 
> iPAQ), the transfer buffers are allocated via dev_alloc_skb. 

Well, I thought it was something like that.  So the problem could be
solved simply by rejigging ohci to export td_alloc and td_free as
overrideable methods?

Your map and unmap single could also be handled this way: with usb
specific overrides that default to dma_map_single.  None of this would
cause much perturbation in usb, and it would give you everthing you
need.

I assume your implementation of dma_map_single is simply to copy the
memory into the on chip area?

> I really think this is a DMA API implementation issue.  The problem 
> touches more than the USB drivers.  I say implementation because the DMA 
> API already takes struct device, so the public interface would not have 
> to change or would not have to change much.  However, we would like to 
> be able to provide device-specific implementations of the dma 
> operations.  One way to implement this would be a pointer to 
> dma_operations from struct device.

The DMA API is highly platform specific.  It basically embodies a
contract between the platform and its attached busses.  It wasn't
designed to embody a contract between two busses (or in this case, a bus
and its implementing driver).

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/