dma_alloc_coherent

[Ran Shalit]

Hello,

I read the readme about dma API, but still don't understand how it
should be used
It is said that dma_alloc_coherent is responsible for allocating the buffer.

1. But how to trigger the dma transaction to start ?
2. Is there a callback when it is finished ?

Thank you,
Ran

[Denis Kirjanov]

Post by Ran Shalit
Hello,
I read the readme about dma API, but still don't understand how it
should be used
It is said that dma_alloc_coherent is responsible for allocating the buffer.
1. But how to trigger the dma transaction to start ?
2. Is there a callback when it is finished ?

It's used for data transfer between IO device and system memory. You
allocate a kernel buffer for DMA transaction (in this case dma from
device to system memory) and setup your device for dma transfer. An IO
device usually generates an interrupt when DMA transfer completes.

Post by Ran Shalit
Thank you,
Ran
_______________________________________________
Kernelnewbies mailing list
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Ran Shalit]

Post by Denis Kirjanov

Post by Ran Shalit
Hello,
I read the readme about dma API, but still don't understand how it
should be used
It is said that dma_alloc_coherent is responsible for allocating the buffer.
1. But how to trigger the dma transaction to start ?
2. Is there a callback when it is finished ?

It's used for data transfer between IO device and system memory. You
allocate a kernel buffer for DMA transaction (in this case dma from
device to system memory) and setup your device for dma transfer. An IO
device usually generates an interrupt when DMA transfer completes.
Denis

If I understand correctly the full picture how to use dma is as
following (schematics):

buf = dma_alloc_coherent(); <<-- done once at the lifetime

every time we need to trigger dma:

//start transaction now
writeb(buf, DMA_ADDR) <<- juat an example, actually it is totally
depends on dma device
writeb(START_DMA, DMA_ADDR+2) <<- juat an example, actually it is
totally depends on dma device

//usually we also register on irq for callback on finishing the transaction.

hope I got it all correct, if you have any comments please add.

Thanks,
Ran

[Vishwas Srivastava]

Hi Ran,
the api which you have mentioned...

void *
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)

is the kernel api to alloc consistent memory.

DMA devices understand the physical addresses not the virtual addresses.

which means that we must supply to the dma device, the physical address, to read

from or to write to.

The second argument of this api is an input argument which is updated
by the kernel if this api returns a success (and contains the physical base
address of the allocated memory) and the returned value of this api is the
kernel virtual address.

if the *CPU* has to operate on this memory (assume that the memory is
dma'ed by the dma device and cpu want to read it for further processing )
it should use the virtual address, so the returned value of this api, as
the base address.
However, if the dma device has to operate on this memory (assume device
want to write to this memory), it should use the *dma_handle* , which is
the physical address (base) of the dma memory.

Now the question is how the dma device knows about this *physical* address?
The answer is that the "dma controller" register would have a register to
accept this physical address.

So the sequence of steps probably would be, in your case:
1: allocate the dma memory
2: programme the dma controller register with the physical address returned
by this api, plus the size of the transaction and may be some more
registers for setting some kind of flags (depends on your dma device)
3: programme the dma controller's dma *start* bit.

after this the dma starts and dma device starts writing to the memory .


I hope, this clarifies you.

Send Kernelnewbies mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kernelnewbies digest..."
1. Re: dma_alloc_coherent (Ran Shalit)
----------------------------------------------------------------------
Message: 1
Date: Sat, 6 Feb 2016 21:22:49 +0200
Subject: Re: dma_alloc_coherent
<
Content-Type: text/plain; charset=UTF-8

Post by Denis Kirjanov

Post by Ran Shalit
Hello,
I read the readme about dma API, but still don't understand how it
should be used
It is said that dma_alloc_coherent is responsible for allocating the
buffer.
1. But how to trigger the dma transaction to start ?
2. Is there a callback when it is finished ?

It's used for data transfer between IO device and system memory. You
allocate a kernel buffer for DMA transaction (in this case dma from
device to system memory) and setup your device for dma transfer. An IO
device usually generates an interrupt when DMA transfer completes.
Denis

If I understand correctly the full picture how to use dma is as
buf = dma_alloc_coherent(); <<-- done once at the lifetime
//start transaction now
writeb(buf, DMA_ADDR) <<- juat an example, actually it is totally
depends on dma device
writeb(START_DMA, DMA_ADDR+2) <<- juat an example, actually it is
totally depends on dma device
//usually we also register on irq for callback on finishing the
transaction.
hope I got it all correct, if you have any comments please add.
Thanks,
Ran
------------------------------
_______________________________________________
Kernelnewbies mailing list
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
End of Kernelnewbies Digest, Vol 63, Issue 7
********************************************

[Ran Shalit]

On Mon, Feb 8, 2016 at 6:01 AM, Vishwas Srivastava

Post by Vishwas Srivastava
Hi Ran,
the api which you have mentioned...
void *
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
is the kernel api to alloc consistent memory.
DMA devices understand the physical addresses not the virtual addresses.
which means that we must supply to the dma device, the physical address, to read
from or to write to.
The second argument of this api is an input argument which is updated
by the kernel if this api returns a success (and contains the physical base
address of the allocated memory) and the returned value of this api is the
kernel virtual address.
if the *CPU* has to operate on this memory (assume that the memory is dma'ed
by the dma device and cpu want to read it for further processing ) it should
use the virtual address, so the returned value of this api, as the base
address.
However, if the dma device has to operate on this memory (assume device want
to write to this memory), it should use the *dma_handle* , which is the
physical address (base) of the dma memory.
Now the question is how the dma device knows about this *physical* address?
The answer is that the "dma controller" register would have a register to
accept this physical address.
1: allocate the dma memory
2: programme the dma controller register with the physical address returned
by this api, plus the size of the transaction and may be some more registers
for setting some kind of flags (depends on your dma device)
3: programme the dma controller's dma *start* bit.
after this the dma starts and dma device starts writing to the memory .
I hope, this clarifies you.

Hi Vishwas,

That's fully clarify the questions about dma_alloc_coherent.

I also try to figure out what's the difference between
dma_alloc_coherent and dma_map_single.

I could not find and important difference between these two methods.
1. With both methods I stil need to program the dma controller with
the physical address and the start trigger.
2. I can still do the allocation whenever I want with both methods
(for example at the initialization of the driver),
3. Not sure what the actuall dma_map_single does (and if it really
necessary to use it), becuase it seems I could just translate the
virtual value from kmalloc into physical address and return it to the
dma controller.

Thank you for the time,
Ran

[Saumendra Dash]

Post by Vishwas Srivastava

Post by Vishwas Srivastava
Hi Ran,

the api which you have mentioned...

Post by Vishwas Srivastava
void *
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
is the kernel api to alloc consistent memory.
DMA devices understand the physical addresses not the virtual addresses.
which means that we must supply to the dma device, the physical address, to read
from or to write to.
The second argument of this api is an input argument which is updated
by the kernel if this api returns a success (and contains the physical
base address of the allocated memory) and the returned value of this
api is the kernel virtual address.
if the *CPU* has to operate on this memory (assume that the memory is
dma'ed by the dma device and cpu want to read it for further
processing ) it should use the virtual address, so the returned value
of this api, as the base address.
However, if the dma device has to operate on this memory (assume
device want to write to this memory), it should use the *dma_handle* ,
which is the physical address (base) of the dma memory.
Now the question is how the dma device knows about this *physical* address?
The answer is that the "dma controller" register would have a register
to accept this physical address.
1: allocate the dma memory
2: programme the dma controller register with the physical address
returned by this api, plus the size of the transaction and may be some
more registers for setting some kind of flags (depends on your dma
device)
3: programme the dma controller's dma *start* bit.
after this the dma starts and dma device starts writing to the memory .

Hi Vishwas,

Post by Vishwas Srivastava
That's fully clarify the questions about dma_alloc_coherent.
I also try to figure out what's the difference between dma_alloc_coherent and dma_map_single.
I could not find and important difference between these two methods.
1. With both methods I stil need to program the dma controller with the physical address and the start trigger.
2. I can still do the allocation whenever I want with both methods (for example at the initialization of the driver), 3. Not sure what the actuall dma_map_single does (and if it really necessary to use it), becuase it >seems I could just translate the virtual value from kmalloc into physical address and return it to the dma controller.

DMA transfers are done either in BURST mode or CYCLE STEALING mode.
In Burst mode, the bus is captured for the entire duration of the transfer from the SRC to DST. In this case, the bus will be released when the Xfer is complete, so obviously it is not an efficient way of doing DMA. DMA_ALLOC_COHERENT() does this way.
In Cycle Stealing mode, the DMA controller grab the bus when free, send a byte and then free the bus immediately. This process is repeated till the Xfer is complete, it is very efficient sine the bus is not grabbed for the entire transaction to complete. DMA_MAP_SINGLE() does this way.

Hope this helps.

Thanks,
Saumendra


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------

[sanjeev sharma]

Hello Saumendra,

I would suggest you to go through the following link: 1) This will explain
need of DMA with practical scenario 2) ARM DMA Mapping with example

https://sanjeevsharmaengg.wordpress.com/2014/08/26/why-dma-required-in-linux-kernel/

http://linuxkernelhacker.blogspot.in/2014/07/arm-dma-mapping-explained.html

I hope these link will give you more confidence around understanding of DMA.

Regards
Sanjeev Sharma

Post by Vishwas Srivastava

Post by Vishwas Srivastava

Post by Vishwas Srivastava
Hi Ran,

the api which you have mentioned...

Post by Vishwas Srivastava
void *
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
is the kernel api to alloc consistent memory.
DMA devices understand the physical addresses not the virtual addresses.
which means that we must supply to the dma device, the physical address, to read
from or to write to.
The second argument of this api is an input argument which is updated
by the kernel if this api returns a success (and contains the physical
base address of the allocated memory) and the returned value of this
api is the kernel virtual address.
if the *CPU* has to operate on this memory (assume that the memory is
dma'ed by the dma device and cpu want to read it for further
processing ) it should use the virtual address, so the returned value
of this api, as the base address.
However, if the dma device has to operate on this memory (assume
device want to write to this memory), it should use the *dma_handle* ,
which is the physical address (base) of the dma memory.
Now the question is how the dma device knows about this *physical*

address?

Post by Vishwas Srivastava

Post by Vishwas Srivastava
The answer is that the "dma controller" register would have a register
to accept this physical address.
1: allocate the dma memory
2: programme the dma controller register with the physical address
returned by this api, plus the size of the transaction and may be some
more registers for setting some kind of flags (depends on your dma
device)
3: programme the dma controller's dma *start* bit.
after this the dma starts and dma device starts writing to the memory .

Hi Vishwas,

Post by Vishwas Srivastava
That's fully clarify the questions about dma_alloc_coherent.
I also try to figure out what's the difference between dma_alloc_coherent

and dma_map_single.

Post by Vishwas Srivastava
I could not find and important difference between these two methods.
1. With both methods I stil need to program the dma controller with the

physical address and the start trigger.

Post by Vishwas Srivastava
2. I can still do the allocation whenever I want with both methods (for

example at the initialization of the driver), 3. Not sure what the actuall
dma_map_single does (and if it really necessary to use it), becuase it

Post by Vishwas Srivastava
seems I could just translate the virtual value from kmalloc into physical

address and return it to the dma controller.
DMA transfers are done either in BURST mode or CYCLE STEALING mode.
In Burst mode, the bus is captured for the entire duration of the
transfer from the SRC to DST. In this case, the bus will be released
when the Xfer is complete, so obviously it is not an efficient way of doing
DMA. DMA_ALLOC_COHERENT() does this way.
In Cycle Stealing mode, the DMA controller grab the bus when free, send a
byte and then free the bus immediately. This process is repeated till the
Xfer is complete, it is very efficient sine the bus is not grabbed for the
entire transaction to complete. DMA_MAP_SINGLE() does this way.
Hope this helps.
Thanks,
Saumendra
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as
information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability
on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior
written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error
please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses
and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
Kernelnewbies mailing list
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies