Messages in this thread | | | Date | Sun, 20 Jun 2004 11:25:51 -0700 | From | Deepak Saxena <> | Subject | Re: DMA API issues |
| |
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@arm.linux.org.uk> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |