On Sat, Jan 9, 2016 at 4:55 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, Jan 08, 2016 at 03:31:29PM -0800, Doug Anderson wrote: >> Ah, that makes so much more sense now! :) So you were suggesting >> something like DMA_ATTR_SMALL_PAGES_OK. Then you if we wanted all >> possible states you'd have 0 vs. DMA_ATTR_SMALL_PAGES_OK vs. >> DMA_ATTR_HUGE_PAGE? That would avoid the double-negative but does >> have the downside that it's less obvious that DMA_ATTR_SMALL_PAGES_OK >> is the opposite of DMA_ATTR_HUGE_PAGE. > > or DMA_ATTR_4K_PAGES if that's what you want. Or maybe just DMA_ATTR_USE_SMALL_PAGES? > We have at least 4k, 8k, > 16k and 64k page support in the kernel, not sure if 32k and 256k ever > made it mainline. What does your hardware actually require? The hardware in question doesn't require any specific page size - the IOMMU can map anything in granularity of 4KiB, which I believe corresponds to the small page size on its platform (4KiB, ARM). Also basically this attribute would translate into alloc_pages() with zero order, so I guess that means small pages. (or we could perhaps make it DMA_ATTR_ALLOC_SINGLE_PAGES...) > > This needs to be documented properly and hpefully also reflected in the > name of the fag. Otherwise we'll end up with a giant desaster like > GFP_DMA that means something slightly different on every architecture. Agreed. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
