[lkml]   [2004]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DMA API issues
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

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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:03    [W:0.096 / U:0.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site