On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote: > There was a recent patch to remove the coherent memory interface from > the DMA API. > > I'd like to ask that this not happen - there are several users of this > code in the handhelds.org tree, which we hope will merge into mainline. > this code is _essential_ to allow support of these devices. > > Removing this from mainline will only increase the hh.org delta which we > are working hard to reduce, and there is no other realistic way to > support these devices. It's been three years since this API was introduced, and the only *merged* user is the one that James wrote. Now it's in the way of some performance improvements I want to make. I can't possibly go round every little platform tree looking for users -- you need to get your drivers into mainline. Yes, it's not necessarily a quick process, but equally, you've had three years. Now, what driver is it that's going to consume this coherent memory? Does it use the dma_pool interface, or does it use dma_alloc_coherent directly? If the latter, I can retain the dma_declare_coherent_memory interface. If the former, then we have to come to a decision between supporting some drivers that are so unimportant that they haven't been merged in three years and making a performance win for drivers that are used every day. Admittedly, I haven't finished the work to make dma_pool use slub, thus I don't know what the performance win will turn out to be. It may not be significant, so it would be an easy decision to keep the interface. But if the decision is going to be to keep the interface despite the lack of users and no matter what the performance win, then I don't need to finish this work. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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
