* 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;
as well as URLs for NNTP newsgroup(s).