DMA support for at91-sama5d2 ADC driver

DMA support for at91-sama5d2 ADC driver

[Eugen.Hristev]

Hello,

I am making a proof of concept for DMA functionality for the
at91-sama5d2 ADC driver.
I would like to ask if it's better to implement in an old fashion way
(request dma channel, allocate memory, start transfer), or try to
integrate with the DMA-buffer in the iio subsystem ?
Is there any driver using that system in the current kernel ?

Also, is there a way to enable/disable DMA coming from the subsystem to
the driver ? (I mean from sysfs, to have or create an option for the
buffer to use DMA or not).
Using DMA has the advantage of less interrupts coming, but much less
granularity on the incoming triggered conversions. So I thought a way
for the user to enable or disable it might be convenient.


Thanks for all the inputs,

Eugen Hristev

Re: DMA support for at91-sama5d2 ADC driver

[Jonathan Cameron]

On 4 May 2017 14:07:19 BST, Eugen.Hristev@microchip.com wrote:
>Hello,
>
>I am making a proof of concept for DMA functionality for the
>at91-sama5d2 ADC driver.
>I would like to ask if it's better to implement in an old fashion way
>(request dma channel, allocate memory, start transfer), or try to
>integrate with the DMA-buffer in the iio subsystem ?
>Is there any driver using that system in the current kernel ?
Lars?

>
>Also, is there a way to enable/disable DMA coming from the subsystem to
>the driver ? (I mean from sysfs, to have or create an option for the
>buffer to use DMA or not).
>Using DMA has the advantage of less interrupts coming, but much less
>granularity on the incoming triggered conversions. So I thought a way
>for the user to enable or disable it might be convenient.
Use the fifo watermark stuff perhaps?  
If set high enough use DMA, if lower then don't.

Complexity around triggering however. Generally DMA pushed to kfifo is done without triggers as
there is no per scan interrupt to hang other devices off.  Also no timestamps...
>
>
>Thanks for all the inputs,
>
>Eugen Hristev
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: DMA support for at91-sama5d2 ADC driver

[Lars-Peter Clausen]

On 05/04/2017 06:21 PM, Jonathan Cameron wrote:
> 
> 
> On 4 May 2017 14:07:19 BST, Eugen.Hristev@microchip.com wrote:
>> Hello,
>>
>> I am making a proof of concept for DMA functionality for the
>> at91-sama5d2 ADC driver.
>> I would like to ask if it's better to implement in an old fashion way
>> (request dma channel, allocate memory, start transfer), or try to
>> integrate with the DMA-buffer in the iio subsystem ?
>> Is there any driver using that system in the current kernel ?
> Lars?

I know that somebody at some point made a working implementation for the
AT91 using the generic DMAengine buffer. So that certainly is an option and
I'd recommend it.

Unfortunately their e-mail address started bouncing (probably moved jobs)
and I'm not sure if the code ever got published.

Re: DMA support for at91-sama5d2 ADC driver

[Eugen Hristev]

Hello Lars, Jonathan,

After I had a deeper look into the DMA support in IIO,
it looks to me like there are few distinct options to
achieve this:

1) Have a regular triggered kfifo buffer.
Prepare dma transaction on buffer post-enable.
Configure dma slave at probe.
Trigger is already setup on buffer enable, so we have to just do
trigger_poll on dma complete. Check the residues and push to iio_buffer
all at once from the dma coherent buffer.
Have a hwfifo in sysfs for the buffer. Use it to configure dma
enable/disable and the dma buffer size for chunk conversions.
With hwfifo disabled, just use regular kfifo triggered buffer with
IRQ for each conversion.

2) Here is the tricky part with the usage of the DMA-buffer.
We can try to use this approach, and have the block size considering
the hwfifo sysfs attribute.
But this means we have to ditch the kfifo buffer. We can try to use a
regular trigger on submit callback such that no DMA is involved. Then
get the IRQ for each conversion and call the block done callback once
the IRQ is received.
If we have the hwfifo enabled, just prepare a DMA transaction and be
done with it.

3) Use the DMAengine buffer. Is this possible ? It looks like this
option is the least configurable and cannot use both DMA and non-DMA
transactions.

As it looks to me, we either start from a kfifo and add DMA support
to it, or we start from a DMAbuffer and add non-dma to it.
I am not sure which way is best to go, but, it is required that we can 
enable or disable the hwfifo (DMA) from sysfs, so the buffer must be
able to support both ways. However we can only expose one type of
buffer to the iio device.

Any opinion is appreciated,
Thanks,
Eugen

On 04.05.2017 19:21, Jonathan Cameron wrote:
> 
> 
> On 4 May 2017 14:07:19 BST, Eugen.Hristev@microchip.com wrote:
>> Hello,
>>
>> I am making a proof of concept for DMA functionality for the
>> at91-sama5d2 ADC driver.
>> I would like to ask if it's better to implement in an old fashion way
>> (request dma channel, allocate memory, start transfer), or try to
>> integrate with the DMA-buffer in the iio subsystem ?
>> Is there any driver using that system in the current kernel ?
> Lars?
> 
>>
>> Also, is there a way to enable/disable DMA coming from the subsystem to
>> the driver ? (I mean from sysfs, to have or create an option for the
>> buffer to use DMA or not).
>> Using DMA has the advantage of less interrupts coming, but much less
>> granularity on the incoming triggered conversions. So I thought a way
>> for the user to enable or disable it might be convenient.
> Use the fifo watermark stuff perhaps?
> If set high enough use DMA, if lower then don't.
> 
> Complexity around triggering however. Generally DMA pushed to kfifo is done without triggers as
> there is no per scan interrupt to hang other devices off.  Also no timestamps...
>>
>>
>> Thanks for all the inputs,
>>
>> Eugen Hristev
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: DMA support for at91-sama5d2 ADC driver

[Jonathan Cameron]

On Wed, 19 Jul 2017 10:25:33 +0300
Eugen Hristev <eugen.hristev@microchip.com> wrote:

> Hello Lars, Jonathan,
> 
Lars is definitely a better person to reply to this
than me, but I'll have a go!
> After I had a deeper look into the DMA support in IIO,
> it looks to me like there are few distinct options to
> achieve this:
> 
> 1) Have a regular triggered kfifo buffer.
> Prepare dma transaction on buffer post-enable.
> Configure dma slave at probe.
> Trigger is already setup on buffer enable, so we have to just do
> trigger_poll on dma complete. Check the residues and push to iio_buffer
> all at once from the dma coherent buffer.
> Have a hwfifo in sysfs for the buffer. Use it to configure dma
> enable/disable and the dma buffer size for chunk conversions.
> With hwfifo disabled, just use regular kfifo triggered buffer with
> IRQ for each conversion.
When using the trigger infrastructure to do dma triggering not
it breaks with the 'standard' meaning of the individual
triggers.  As such it become necessary to restrict the
use of the trigger to just this one device (then no one cares
that the frequency is wrong).

Timestamps can also become really complicated to generate
with any accuracy.  Anyhow, this is all stuff other drivers
are handling so copy them.
> 
> 2) Here is the tricky part with the usage of the DMA-buffer.
> We can try to use this approach, and have the block size considering
> the hwfifo sysfs attribute.
> But this means we have to ditch the kfifo buffer. We can try to use a
> regular trigger on submit callback such that no DMA is involved. Then
> get the IRQ for each conversion and call the block done callback once
> the IRQ is received.
> If we have the hwfifo enabled, just prepare a DMA transaction and be
> done with it.
Triggers really have very little meaning once you are using the
dma-buffer infrastructure.  Lars is working on some more complex
handling for this, but I have no idea what stage that work is at.

You are right that it is an either kfifo or dma buffer choice.
Mostly the dma-buffer stuff is for very fast devices where the
overheads of the kfifo handling really matter and hence the
kfifo doesn't make any sense at all.
> 
> 3) Use the DMAengine buffer. Is this possible ? It looks like this
> option is the least configurable and cannot use both DMA and non-DMA
> transactions.
> 
> As it looks to me, we either start from a kfifo and add DMA support
> to it, or we start from a DMAbuffer and add non-dma to it.
> I am not sure which way is best to go, but, it is required that we can 
> enable or disable the hwfifo (DMA) from sysfs, so the buffer must be
> able to support both ways. However we can only expose one type of
> buffer to the iio device.
Explicitly disable it or do it using the hints of the
watershed for example to work out whether low latency is required or
not.

My gut feeling here is that for SoC ADCs in general the kfifo
fed by dma is the best compromise.  Only real question is
whether we can cope with 1MSPS using that approach.

Jonathan
> 
> Any opinion is appreciated,
> Thanks,
> Eugen
> 
> On 04.05.2017 19:21, Jonathan Cameron wrote:
> > 
> > 
> > On 4 May 2017 14:07:19 BST, Eugen.Hristev@microchip.com wrote:  
> >> Hello,
> >>
> >> I am making a proof of concept for DMA functionality for the
> >> at91-sama5d2 ADC driver.
> >> I would like to ask if it's better to implement in an old fashion way
> >> (request dma channel, allocate memory, start transfer), or try to
> >> integrate with the DMA-buffer in the iio subsystem ?
> >> Is there any driver using that system in the current kernel ?  
> > Lars?
> >   
> >>
> >> Also, is there a way to enable/disable DMA coming from the subsystem to
> >> the driver ? (I mean from sysfs, to have or create an option for the
> >> buffer to use DMA or not).
> >> Using DMA has the advantage of less interrupts coming, but much less
> >> granularity on the incoming triggered conversions. So I thought a way
> >> for the user to enable or disable it might be convenient.  
> > Use the fifo watermark stuff perhaps?
> > If set high enough use DMA, if lower then don't.
> > 
> > Complexity around triggering however. Generally DMA pushed to kfifo is done without triggers as
> > there is no per scan interrupt to hang other devices off.  Also no timestamps...  
> >>
> >>
> >> Thanks for all the inputs,
> >>
> >> Eugen Hristev
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> >