On Tue, Oct 30, 2007 at 02:35:14PM -0600, Matthew Wilcox wrote: > On Tue, Oct 30, 2007 at 03:26:31PM -0500, James Bottomley wrote: > > Its design was basically to facilitate the use of bus remote memory. > > There's a long thread somewhere discussing this with the ARM people. > > They had some type of SoC implementation that needed to allocate local > > memory for device descriptors. The Q720 is pretty much the same way, so > > I used it to build the implementation when I created it for the ARM > > people. This is the original thread: > > > > http://marc.info/?t=108757862100001 > > > > They said they were implementing this system, so I've no idea what > > happened. > > It's been over three years, and it hasn't happened. > > > However, what are the problems the API is causing? it seems > > useful, so there should be a preference in its favour of existence > > unless it's causing a problem. > > What I'm currently looking at is the dmapool allocator. It's not > exactly fast (a spinlock for each allocation ... no concept of cpu > affinity, etc), and some drivers (eg qla2xxx) use it in the performance > path. > > One of the suggestions in the existing dmapool driver is to share the > guts of slab. Well, slab is probably going away, so I took a look > at slub. Slub really, *really* needs the struct page associated > with the page of memory allocated, so I'm currently working my way > through the architectures trying to turn dma_alloc_coherent into > dma_alloc_coherent_pages. > > The dma_coherent_mem API is one of the things which gets in the way of > doing this. So I deleted it, then sent the patch out for comments early. > We have some out-of-tree users for this on SH as well, particularly the SM501 MFD USB driver which needs to do 8051-local allocations. We have an in-tree hack for this now, I never bothered pushing the dma_declare_coherent_memory() bits due to the fact the driver hadn't been merged yet, but I had planned on merging both for 2.6.25. We can continue using the in-tree hack if there aren't going to be any other users of this API and it's causing problems elsewhere, but I do expect that we will continue to see devices with a need for this sort of API. I would imagine that the ARM case is similar, even if it's been a low priority item. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
