On Thu, Apr 12, 2012 at 11:18:19AM +0000, Arnd Bergmann wrote: > On Thursday 12 April 2012, Marek Szyprowski wrote: > > Scatter lists were initially designed for the disk based block io operations, > > hence the presence of the in-page offsets and lengths for each chunk. For > > multimedia use cases providing an array of struct pages and asking dma-mapping > > to map them into contiguous memory is probably all we need. I wonder if > > introducing such new calls is a good idea. Anrd, what do think? It will > > definitely simplify the drivers and improve the code understanding. On the > > other hand it requires a significant amount of work in the dma-mapping > > framework for all architectures, but that's not a big issue for me. > > My feeling is that it's too much like the existing _sg version, so I wouldn't > add yet another variant. While having a simple page array is definitely > simpler and potentially faster, I think the API is already too complex > and we need to be very careful with new additions. I concur here. For VT-d support we wrestle the pages through an sg list in drm/i915, too. It's not beautiful, and because our gpu internal pagetables need 2 loops to walk the sg lists, one for the sg segments, one to loop over all pages in a segment. And additional a WARN_ON if the segment dma address isn't page-aligned. It's ugly, but imo adding some helpers to easier deal with this common case (like the drm_prime_pages_to_sg) function is better than creating an entirely new interface. -Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html