Messages in this thread | | | Date | Fri, 18 Jun 2004 12:21:12 -0700 | From | Matt Porter <> | Subject | Re: DMA API issues |
| |
On Fri, Jun 18, 2004 at 02:33:18PM -0400, Jamey Hicks wrote: > Matt Porter wrote: > >On Fri, Jun 18, 2004 at 05:59:02PM +0100, Ian Molton wrote: > >>1) The DMA API provides no methods to set up a mapping between the host > >> memory map and the devices view of the space > >> example: > >> the OHCI controller above would see its 32K of SRAM as > >> mapped from 0x10000 - 0x1ffff and not 0xXXX10000 - 0xXXX1ffff > >> which is the address the CPU sees. > >>2) The DMA API assumes the device can access SDRAM > >> example: > >> the OHCI controller base is mapped at 0x10000000 on my platform. > >> this is NOT is SDRAM, its in IO space. > > > >Can't you just implement an arch-specific allocator for your 32KB > >SRAM, then implement the DMA API streaming and dma_alloc/free APIs > >on top of that? Since this architecture is obviously not designed > >for performance, it doesn't seem to be a big deal to have the streaming > >APIs copy to/from the kmalloced (or whatever) buffer to/from the SRAM > >allocated memory and then have those APIs return the proper dma_addr_t > >for the embedded OHCI's address space view of the SRAM. Same thing > >goes for implementing dma_alloc/free (used by dma_pool*). I don't > >have the knowledge of USB subsystem buffer usage to know how quickly > >that little 32KB of SRAM is going to run out. But at a DMA API level, > >this seems doable, albeit with the greater possibility of negative > >retvals from these calls. > > > Your analysis of what is needed is correct. However, we would prefer to > fit this into the DMA API in a generic way, rather than having a > specialized API that is not acceptable upstream. I'm more concerned > with finding the best way to address this problem than with whether this > is a 2.6 or 2.7 issue. > > We do need a memory allocator for the pool of SRAM. If we're not going > to have to build customized versions of the OHCI driver, we need that > pool hooked into the dma_pool and dma_alloc_coherent interfaces. We > could do that with a platform specific implementation of > dma_alloc_coherent, but a pointer to dma_{alloc,free} from struct device > seems like a cleaner solution. We also will need bounce buffers, as you
Yes, it can be cleaner, but it's not something I would say is completely broken with the DMA API. It does provide a way to make your device specific implementation, regardless of whether it's managed ideally via a struct device pointer. Migrating to dev->dma* sounds suspiciously like a 2.7ism.
> described, but there is already a good start towards that support in > 2.6. The other thing that might be needed is passing device to
Where's that code?
> page_to_dma so that device specific dma addresses can be constructed.
A struct device argument to page_to_dma seems like a no brainer to be included.
> Deepak Saxena wrote a pretty good summary as part if the discussion > about this issue on the linux-arm-kernel mailing list: > > http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022796.html
Ahh, ok. Deepak and I have discussed this idea F2F on a several occassions, I recall he needed it for the small floating PCI window he has to manage on the IXP* ports. It may help in some embedded PPC areas as well.
> I think I'm looking for something like the PARISC hppa_dma_ops but more > generic: > > http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022813.html
I see that's somewhat like what David Brownell suggested before...a single pointer to a set of dma ops from struct device. hppa_dma_ops translated into a generic dma_ops entity with fields corresponding to existing DMA API calls would be a good starting point. We can get rid of some address translation hacks in a lot of custom embedded PPC drivers with something like this.
-Matt - 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/
| |