Re: dma_alloc_coherent

Re: dma_alloc_coherent

[Robert Hancock]

Kartik Babu wrote:
>  I'm trying to replace consistent_alloc in a driver that was written for 
> the 2.4 kernel with dma_alloc_coherent. My question is that I do not use 
> a struct device * pointer at all. Browsing through the source for the 
> 2.6.12
> on ARM XScale PXA255, I see that this argument may be NULL.
> 
> Still, I'd like to know if passing NULL has any side effects. If so, 
> what are they?
> 
> I do however have a cdev structure taht I use for device registration, 
> but I do not see how that would help.

What kind of a device is it? If it's a PCI device, the struct device can 
be accessed with the dev pointer inside the struct pci_dev.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: dma_alloc_coherent

[Kartik Babu]

Its a char device driver Im using to control the SPI port on the PXA255 
processor. I transfer fixed sized packets over this bus, and hence DMA 
is a good option instead of interrupt driven IO.

it seems that the dma_pool_create function explicitly handles both cases 
dev = NULL and dev != NULL.

However, the dma_alloc_coherent function only checks if dev is not NULL, 
and apparently uses the valu in one case without checking it.

My understanding is that the dev pointer is needed only to check the 
mask for accesible DMA locations correct?

Kartik

Robert Hancock wrote:
> Kartik Babu wrote:
>>  I'm trying to replace consistent_alloc in a driver that was written 
>> for the 2.4 kernel with dma_alloc_coherent. My question is that I do 
>> not use a struct device * pointer at all. Browsing through the source 
>> for the 2.6.12
>> on ARM XScale PXA255, I see that this argument may be NULL.
>>
>> Still, I'd like to know if passing NULL has any side effects. If so, 
>> what are they?
>>
>> I do however have a cdev structure taht I use for device 
>> registration, but I do not see how that would help.
>
> What kind of a device is it? If it's a PCI device, the struct device 
> can be accessed with the dev pointer inside the struct pci_dev.
>

dma_alloc_coherent

[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.




On Sun, Feb 7, 2016 at 10:30 PM, <kernelnewbies-request@kernelnewbies.org>
wrote:

> Send Kernelnewbies mailing list submissions to
>         kernelnewbies at kernelnewbies.org
>
> 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
>         kernelnewbies-request at kernelnewbies.org
>


>
> You can reach the person managing the list at
>         kernelnewbies-owner at kernelnewbies.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
>    1. Re: dma_alloc_coherent (Ran Shalit)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 6 Feb 2016 21:22:49 +0200
> From: Ran Shalit <ranshalit@gmail.com>
> Subject: Re: dma_alloc_coherent
> To: Denis Kirjanov <kirjanov@gmail.com>
> Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
> Message-ID:
>         <
> CAJ2oMhLi9LV6QQ-Yr1yNKgoBwC_ET-qTwDAGGrDc9BGZLKNNXA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Feb 5, 2016 at 11:15 AM, Denis Kirjanov <kirjanov@gmail.com>
> wrote:
> > On 2/5/16, Ran Shalit <ranshalit@gmail.com> wrote:
> >> 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@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
>
>
>
> ------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> End of Kernelnewbies Digest, Vol 63, Issue 7
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160208/232c5080/attachment-0001.html 

dma_alloc_coherent

[Ran Shalit]

On Mon, Feb 8, 2016 at 6:01 AM, Vishwas Srivastava
<vishu.kernel@gmail.com> wrote:
> 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.
>
>

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

dma_alloc_coherent

[Saumendra Dash]

>> 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 .

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.

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.

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

dma_alloc_coherent

[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

On Mon, Feb 8, 2016 at 12:29 PM, Saumendra Dash <saumendra.d@hcl.com> wrote:

> >> 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 .
>
> 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.
>
> 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.
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160208/4ef37283/attachment.html 

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

dma_alloc_coherent

[Denis Kirjanov]

On 2/5/16, Ran Shalit <ranshalit@gmail.com> wrote:
> 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.
>
> Thank you,
> Ran
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
Regards / Mit besten Gr??en,
Denis

dma_alloc_coherent

[Ran Shalit]

On Fri, Feb 5, 2016 at 11:15 AM, Denis Kirjanov <kirjanov@gmail.com> wrote:
> On 2/5/16, Ran Shalit <ranshalit@gmail.com> wrote:
>> 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@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

dma_alloc_coherent

[bob jonny]

In dma_alloc_coherent(), where is it allocating memory from, and how does it know that that memory is cache coherent? Does every device have it's cache coherent memory? I got lost at function pointer struct dma_map_ops ops, is there an easy way to figure out what ops->alloc_coherent() points to?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111012/8e392753/attachment.html 

dma_alloc_coherent

[rohan puri]

On Wed, Oct 12, 2011 at 11:47 PM, bob jonny <ilikepie420@live.com> wrote:

>  In dma_alloc_coherent(), where is it allocating memory from, and how does
> it know that that memory is cache coherent? Does every device have it's
> cache coherent memory? I got lost at function pointer struct dma_map_ops
> ops, is there an easy way to figure out what ops->alloc_coherent() points
> to?
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> Hi Bob,

dma_alloc_coherent() invokes the alloc_coherent method for the particular
device which is the first parameter.

So to see from where the memory is getting allocated, you need to see that
device's dma_map_op's alloc_coherent method.

I went through some of them, they tend to alloc memory by calling either
__get_free_pages() or alloc_pages() functions.

To maintain cache coherency, the pages which are allocated in these
functions have to be uncached and if they where cached earlier then they
have to be flushed.

Following function explains all these : -

void *dma_generic_alloc_coherent(struct device *dev, size_t size,
                                 dma_addr_t *dma_handle, gfp_t gfp)
{
        void *ret, *ret_nocache;
        int order = get_order(size);

        gfp |= __GFP_ZERO;

        ret = (void *)__get_free_pages(gfp, order);
        if (!ret)
                return NULL;

        /*
         * Pages from the page allocator may have data present in
         * cache. So flush the cache before using uncached memory.
         */
        dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);

        ret_nocache = (void __force *)ioremap_nocache(virt_to_phys(ret),
size);
        if (!ret_nocache) {
                free_pages((unsigned long)ret, order);
                return NULL;
        }

        split_page(pfn_to_page(virt_to_phys(ret) >> PAGE_SHIFT), order);

        *dma_handle = virt_to_phys(ret);

        return ret_nocache;
}

Regards,
Rohan Puri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111013/59f83a29/attachment.html 

dma_alloc_coherent

[Kartik Babu]

  I'm trying to replace consistent_alloc in a driver that was written 
for the 2.4 kernel with dma_alloc_coherent. My question is that I do not 
use a struct device * pointer at all. Browsing through the source for 
the 2.6.12
on ARM XScale PXA255, I see that this argument may be NULL.

 Still, I'd like to know if passing NULL has any side effects. If so, 
what are they?

 I do however have a cdev structure taht I use for device registration, 
but I do not see how that would help.

Thanks
Kartik