Re: DMA API issues

[Deepak Saxena]

On Jun 19 2004, at 00:20, Ian Molton was caught saying:
> On Fri, 18 Jun 2004 22:20:14 +0100
> Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> wrote:
> 
> > > Yes, we do this on parisc too.  We actually have a hidden method
> > > pointer(per platform) and cache the iommu (we have more than one)
> > > accessors in platform_data.
> > 
> > Except that platform_data already has multiple other uses, especially
> > for platform devices.
> 
> In the case of the SOC devices I described, its actually appropriate to
> make the allocator system tied to the bus - as several devices end up
> sharing the same 32K pool in the device. at the device level the
> allocator would be useless in these cases.

I've followed the whole thread and I still think what you are trying
to do can be currently accomplished with the existing API by simply 
overriding the generic ARM implementation and providing one specific
to your platform. All the dma_* APIs take a dev structure as a
parameter, so you simply have to look at that and if it's your OHCI
device, call your specific allocator/deallocator/mapping function/etc.
Your dma_alloc_coherent() would simply ioremap() and return the
ioremap'd address as the virtual address and the OHCI-bus address 
as the DMA_ADDR. Your dma_map_single() simply bounces data between
the SRAM and system memory.  Having per-bus or per-device allocators 
as you are proposing is very possibly the correct way to go, but I don't 
think it's a simple enough change that we want to do it on 2.6.

~Deepak

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6
-
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/