* minimum guaranteed alignment of dma_alloc_coherent? @ 2011-02-05 0:14 Timur Tabi 2011-02-05 1:09 ` Dan Malek 0 siblings, 1 reply; 6+ messages in thread From: Timur Tabi @ 2011-02-05 0:14 UTC (permalink / raw) To: linuxppc-dev Is there any official statement on what the minimum alignment is for memory returned by dma_alloc_coherent? I know that since it uses a page allocator to do the actual allocation, that the memory is page aligned (at least on PowerPC). Is this something I can rely on? Would anyone have a complaint if I did this: vaddr = dma_alloc_coherent(dev, ssize, &paddr, GFP_DMA | __GFP_ZERO); BUG_ON(paddr & (alignment - 1)); 'alignment' will always be 32 or less. The reason I ask is that I currently have code that ensures an alignment, but it does so by allocating extra memory, and that seems wasteful. On a side note, do I really need to pass GFP_DMA when calling dma_alloc_coherent? That seems redundant, but I don't see the code force it to be set. Should it be forced on? -- Timur Tabi Linux kernel developer at Freescale ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: minimum guaranteed alignment of dma_alloc_coherent? 2011-02-05 0:14 minimum guaranteed alignment of dma_alloc_coherent? Timur Tabi @ 2011-02-05 1:09 ` Dan Malek 2011-02-05 2:04 ` Tabi Timur-B04825 0 siblings, 1 reply; 6+ messages in thread From: Dan Malek @ 2011-02-05 1:09 UTC (permalink / raw) To: Timur Tabi; +Cc: linuxppc-dev On Feb 4, 2011, at 4:14 PM, Timur Tabi wrote: > Is there any official statement on what the minimum alignment is for > memory returned by dma_alloc_coherent? This is dependent upon the particular implementation. There have been several over the history of this API, and some would work out of a DMA pool that would only provide word alignment. > Would anyone have a complaint if I did this: > > vaddr = dma_alloc_coherent(dev, ssize, &paddr, GFP_DMA | __GFP_ZERO); > BUG_ON(paddr & (alignment - 1)); Well, the usual design for anything that requires alignment is that you never assume you get it unless it can be specified, so over allocate as you are doing currently, and then adjust the base address. Or, you could allocate exactly what you want, if it aligns properly you are good to go, and if not release, over allocate, and adjust. The problem with the suggested implementation is the results aren't predictable. Even if the API doesn't guarantee your alignment, you may get it most of the time, but once in a while this may fail. You could test and all looks good, ship something and it fails. Today, this may work fine, but it would be nice to ensure it continues to work in the future. :-) > On a side note, do I really need to pass GFP_DMA .... The GFP_DMA is architecture dependent. Are you writing a driver to be used across multiple architectures? If it's necessary, I'd document why you are using it (an ISA device on x86 for example) and then let other architectures determine if it's necessary for them. Thanks. -- Dan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: minimum guaranteed alignment of dma_alloc_coherent? 2011-02-05 1:09 ` Dan Malek @ 2011-02-05 2:04 ` Tabi Timur-B04825 2011-02-05 2:56 ` Dan Malek 0 siblings, 1 reply; 6+ messages in thread From: Tabi Timur-B04825 @ 2011-02-05 2:04 UTC (permalink / raw) To: Dan Malek; +Cc: linuxppc-dev@lists.ozlabs.org Dan Malek wrote: > > >> On a side note, do I really need to pass GFP_DMA .... > > The GFP_DMA is architecture dependent. Are you writing > a driver to be used across multiple architectures? It's conceivable that the driver could work on PowerPC and ARM. > If it's > necessary, I'd document why you are using it (an ISA device > on x86 for example) and then let other architectures > determine if it's necessary for them. I guess I'm not clear. I was wondering why an API called "dma_alloc_cohere= nt" (that has the word "dma" in it) needs to be told to allocate DMA-safe m= emory. When would it make sense to call dma_alloc_cohernet without GFP_DMA= ? If you don't want DMA-able memory, then you shouldn't be calling dma_all= oc_anything. --=20 Timur Tabi Linux kernel developer= ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: minimum guaranteed alignment of dma_alloc_coherent? 2011-02-05 2:04 ` Tabi Timur-B04825 @ 2011-02-05 2:56 ` Dan Malek 2011-02-07 15:13 ` Timur Tabi 0 siblings, 1 reply; 6+ messages in thread From: Dan Malek @ 2011-02-05 2:56 UTC (permalink / raw) To: Tabi Timur-B04825; +Cc: linuxppc-dev@lists.ozlabs.org On Feb 4, 2011, at 6:04 PM, Tabi Timur-B04825 wrote: > I guess I'm not clear. I was wondering why an API called > "dma_alloc_coherent" (that has the word "dma" in it) needs to be > told to allocate DMA-safe memory. I understood your question, and I indicated this is used in a platform specific manner. > When would it make sense to call dma_alloc_cohernet without > GFP_DMA? If you don't want DMA-able memory, then you shouldn't be > calling dma_alloc_anything. So, I did a little research. It appears in the case of PowerPC, the GFP_DMA can change the way the allocation operates. Since the coherent allocator works with pages of memory, in the case of a system with highmem, not using GFP_DMA could hand you a physical page out of the highmem pool. If your device is capable of doing a DMA to that physical location, all is good. If your device has some addressing restriction to low memory buffers, you should specify GFP_DMA. I think for all architectures, GFP_DMA will guarantee a DMA buffer for any device in a system. If your device can relax that constraint, you can elect to not use this flag and conserve the DMA pool for those devices that require the restrictions. This behavior is modified if you specify a restricted DMA mask for the device. In this case, dma_alloc_coherent will force GFP_DMA on your behalf (on PowerPC). Thanks. -- Dan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: minimum guaranteed alignment of dma_alloc_coherent? 2011-02-05 2:56 ` Dan Malek @ 2011-02-07 15:13 ` Timur Tabi 2011-03-29 0:32 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 6+ messages in thread From: Timur Tabi @ 2011-02-07 15:13 UTC (permalink / raw) To: Dan Malek; +Cc: linuxppc-dev@lists.ozlabs.org Dan Malek wrote: > So, I did a little research. It appears in the case of PowerPC, > the GFP_DMA can change the way the allocation operates. > Since the coherent allocator works with pages of memory, > in the case of a system with highmem, not using GFP_DMA > could hand you a physical page out of the highmem pool. I think that's true only if SWIOTLB is enabled. dma_direct_alloc_coherent() does this: /* ignore region specifiers */ flag &= ~(__GFP_HIGHMEM); > This behavior is modified if you specify a restricted DMA > mask for the device. In this case, dma_alloc_coherent > will force GFP_DMA on your behalf (on PowerPC). Isn't it required for all callers of dma_alloc_coherent to specify a mask (via dma_set_mask) first? -- Timur Tabi Linux kernel developer at Freescale -- Timur Tabi Linux kernel developer at Freescale ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: minimum guaranteed alignment of dma_alloc_coherent? 2011-02-07 15:13 ` Timur Tabi @ 2011-03-29 0:32 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 6+ messages in thread From: Benjamin Herrenschmidt @ 2011-03-29 0:32 UTC (permalink / raw) To: Timur Tabi; +Cc: Dan Malek, linuxppc-dev@lists.ozlabs.org On Mon, 2011-02-07 at 09:13 -0600, Timur Tabi wrote: > > This behavior is modified if you specify a restricted DMA > > mask for the device. In this case, dma_alloc_coherent > > will force GFP_DMA on your behalf (on PowerPC). > > Isn't it required for all callers of dma_alloc_coherent to specify a > mask (via > dma_set_mask) first? GFP_DMA historically means ISA DMA memory on x86 :-) Other platforms had different "use" for it but basically it's old style drivers. The problem with dma_set_mask() is that there's no way without an iommu that the implementation of dma_alloc_coherent() can satisfy arbitrary masks since you don't control where the page allocator gets you the pages from ... unless you have zones. That's what ZONE_DMA and ZONE_DMA32 are for. Cheers, Ben. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-29 0:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-05 0:14 minimum guaranteed alignment of dma_alloc_coherent? Timur Tabi 2011-02-05 1:09 ` Dan Malek 2011-02-05 2:04 ` Tabi Timur-B04825 2011-02-05 2:56 ` Dan Malek 2011-02-07 15:13 ` Timur Tabi 2011-03-29 0:32 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox