using dma buffers for SPI adcs

using dma buffers for SPI adcs

[Alex Roberts]

Hello,

I am learning how to use and write iio device drivers for ADCs. It seems
most of the support is tied to FPGA based SoCs where ADCs can make use of
Analog Devices SPI Engine and AXI IP. I'm looking at the AD7768-1 driver on
the Analog Devices fork for example.

How does one use dma buffers for generic ARM processors for an ADC attached
to a dma-enabled SPI port.. for example a Beaglebone Black or Raspberry PI?
Is this even possible or something that makes sense? The goal is of course
to use DMA to avoid interrupting the processor for every conversion.

I tried using the ADI driver, but get a ENODEV error when requesting the
dma channel because there is not a "dmas" entry in the device tree node for
the ADC, however it's parent SPI node does have dma entries.

Thanks,
Alex.

Re: using dma buffers for SPI adcs

[Jonathan Cameron]

On Sat, 12 Jun 2021 19:33:32 -0500
Alex Roberts <alex.roberts@ieee.org> wrote:

> Hello,
> 
> I am learning how to use and write iio device drivers for ADCs. It seems
> most of the support is tied to FPGA based SoCs where ADCs can make use of
> Analog Devices SPI Engine and AXI IP. I'm looking at the AD7768-1 driver on
> the Analog Devices fork for example.
> 
> How does one use dma buffers for generic ARM processors for an ADC attached
> to a dma-enabled SPI port.. for example a Beaglebone Black or Raspberry PI?
> Is this even possible or something that makes sense? The goal is of course
> to use DMA to avoid interrupting the processor for every conversion.
> 
> I tried using the ADI driver, but get a ENODEV error when requesting the
> dma channel because there is not a "dmas" entry in the device tree node for
> the ADC, however it's parent SPI node does have dma entries.
> 
> Thanks,
> Alex.

Hi Alex,

I'll take a stab at answering this.

So the key thing here is that it's 'normally' not that easy to get a
DMA enabled SPI port to act like a fully fledged DMA engine suitable for
autonomous use streaming data into RAM.  They tend to be much more focused
on simple transfers needed for SPI itself.  Sometimes they are capable of
simple streaming but not in a remotely generic fashion.

Thus to use a DMA engine to do SPI based ADC transfers you need something
a bit cleverer. The Analog Device SPI Engine is effectively an offload engine
for SPI ADC management.  IIRC you set it up to sample a cyclic set of channels
and it generates all the writes needed to the device to make those happen
+ packs the data in to DMA buffers (large contiguous memory regions in RAM).

It's possible that a generic board might have a smart enough SPI implementation
to do this, but I'm not aware of it being possible on the BBB or RaspberryPi.

I vaguely remember some discussions a long time back about using the PRU on
the BBB to implement this sort of functionality, but can't remember where
or when those happened :(  Possible IRC a long time back.

Jonathan

Re: using dma buffers for SPI adcs

[Lars-Peter Clausen]

On 6/14/21 12:59 PM, Jonathan Cameron wrote:
> On Sat, 12 Jun 2021 19:33:32 -0500
> Alex Roberts <alex.roberts@ieee.org> wrote:
>
>> Hello,
>>
>> I am learning how to use and write iio device drivers for ADCs. It seems
>> most of the support is tied to FPGA based SoCs where ADCs can make use of
>> Analog Devices SPI Engine and AXI IP. I'm looking at the AD7768-1 driver on
>> the Analog Devices fork for example.
>>
>> How does one use dma buffers for generic ARM processors for an ADC attached
>> to a dma-enabled SPI port.. for example a Beaglebone Black or Raspberry PI?
>> Is this even possible or something that makes sense? The goal is of course
>> to use DMA to avoid interrupting the processor for every conversion.
>>
>> I tried using the ADI driver, but get a ENODEV error when requesting the
>> dma channel because there is not a "dmas" entry in the device tree node for
>> the ADC, however it's parent SPI node does have dma entries.
>>
>> Thanks,
>> Alex.
> Hi Alex,
>
> I'll take a stab at answering this.
>
> So the key thing here is that it's 'normally' not that easy to get a
> DMA enabled SPI port to act like a fully fledged DMA engine suitable for
> autonomous use streaming data into RAM.  They tend to be much more focused
> on simple transfers needed for SPI itself.  Sometimes they are capable of
> simple streaming but not in a remotely generic fashion.
>
> Thus to use a DMA engine to do SPI based ADC transfers you need something
> a bit cleverer. The Analog Device SPI Engine is effectively an offload engine
> for SPI ADC management.  IIRC you set it up to sample a cyclic set of channels
> and it generates all the writes needed to the device to make those happen
> + packs the data in to DMA buffers (large contiguous memory regions in RAM).
>
> It's possible that a generic board might have a smart enough SPI implementation
> to do this, but I'm not aware of it being possible on the BBB or RaspberryPi.
>
> I vaguely remember some discussions a long time back about using the PRU on
> the BBB to implement this sort of functionality, but can't remember where
> or when those happened :(  Possible IRC a long time back.

That sums it up pretty nicely.

The problem is you need support for executing the SPI transaction 
automatically in response to the trigger or data ready signal. Otherwise 
the interrupt overhead will overload the system once you go above a few 
kHz. I've seen some SoCs and Microcontrollers which support this, but no 
Linux support. Sometimes it is possible to use a controller that was 
more meant for audio use cases, but even then it needs to support more 
thatn what is required for just audio, so the list will be very short.

The only alternative is to dedicate a full CPU to doing the SPI 
transfers and instead of using interrupts poll the data ready signal, 
this will reduce the overhead and latency itself. But the CPU will spend 
a lot of time busy waiting and not be able to do any other work. Some 
SoCs these days have smaller co-processors like a cortex-r5, these would 
be ideal candidates to implement this if they are not already busy doing 
something else.

- Lars

Re: using dma buffers for SPI adcs

[Andy Shevchenko]

On Tue, Jun 15, 2021 at 12:37 PM Lars-Peter Clausen <lars@metafoo.de> wrote:
>
> On 6/14/21 12:59 PM, Jonathan Cameron wrote:
> > On Sat, 12 Jun 2021 19:33:32 -0500
> > Alex Roberts <alex.roberts@ieee.org> wrote:
> >
> >> Hello,
> >>
> >> I am learning how to use and write iio device drivers for ADCs. It seems
> >> most of the support is tied to FPGA based SoCs where ADCs can make use of
> >> Analog Devices SPI Engine and AXI IP. I'm looking at the AD7768-1 driver on
> >> the Analog Devices fork for example.
> >>
> >> How does one use dma buffers for generic ARM processors for an ADC attached
> >> to a dma-enabled SPI port.. for example a Beaglebone Black or Raspberry PI?
> >> Is this even possible or something that makes sense? The goal is of course
> >> to use DMA to avoid interrupting the processor for every conversion.
> >>
> >> I tried using the ADI driver, but get a ENODEV error when requesting the
> >> dma channel because there is not a "dmas" entry in the device tree node for
> >> the ADC, however it's parent SPI node does have dma entries.
> >>
> >> Thanks,
> >> Alex.
> > Hi Alex,
> >
> > I'll take a stab at answering this.
> >
> > So the key thing here is that it's 'normally' not that easy to get a
> > DMA enabled SPI port to act like a fully fledged DMA engine suitable for
> > autonomous use streaming data into RAM.  They tend to be much more focused
> > on simple transfers needed for SPI itself.  Sometimes they are capable of
> > simple streaming but not in a remotely generic fashion.
> >
> > Thus to use a DMA engine to do SPI based ADC transfers you need something
> > a bit cleverer. The Analog Device SPI Engine is effectively an offload engine
> > for SPI ADC management.  IIRC you set it up to sample a cyclic set of channels
> > and it generates all the writes needed to the device to make those happen
> > + packs the data in to DMA buffers (large contiguous memory regions in RAM).
> >
> > It's possible that a generic board might have a smart enough SPI implementation
> > to do this, but I'm not aware of it being possible on the BBB or RaspberryPi.
> >
> > I vaguely remember some discussions a long time back about using the PRU on
> > the BBB to implement this sort of functionality, but can't remember where
> > or when those happened :(  Possible IRC a long time back.
>
> That sums it up pretty nicely.
>
> The problem is you need support for executing the SPI transaction
> automatically in response to the trigger or data ready signal. Otherwise
> the interrupt overhead will overload the system once you go above a few
> kHz. I've seen some SoCs and Microcontrollers which support this, but no
> Linux support. Sometimes it is possible to use a controller that was
> more meant for audio use cases, but even then it needs to support more
> thatn what is required for just audio, so the list will be very short.
>
> The only alternative is to dedicate a full CPU to doing the SPI
> transfers and instead of using interrupts poll the data ready signal,
> this will reduce the overhead and latency itself. But the CPU will spend
> a lot of time busy waiting and not be able to do any other work. Some
> SoCs these days have smaller co-processors like a cortex-r5, these would
> be ideal candidates to implement this if they are not already busy doing
> something else.

On top of what guys already said, you need hardware assistance for that.
The simplest way is to use a SoC / platform that allows users to mux
Dreq Dack (DMA main signals) to be connected to the data provider in
question. In general we have SPI host controller to follow this schema
(that's why it can do transfers from and to SPI FIFO, but there are no
signals that anyhow can affect the Dreq / Dack from the outside. I
believe that such kind of hardware might exist, but it will be
specialized one for dedicated tasks (like Audio streaming).


-- 
With Best Regards,
Andy Shevchenko

Re: using dma buffers for SPI adcs

[Alex Roberts]

Jonathan,

Thanks for the information. It appears my original email was sent with
an old @ieee.org alias, meaning I never received the reply since that
alias is currently inactive.

My end goal is get an 8-channel ADC working with >100ksps/channel.
That doesn't seem do-able without an FPGA/PRU/real-time coprocessor to
offload the SPI controller to for an IIO-based approach. So now I'm
researching how to do something similar, but with the ASoC framework
instead of iio, using a different ADC that supports DAIs like NXP SAI
and TI McASP. But I'm running into issues there too with learning how
to configure simple-sound-card and a dummy-codec, but I suppose my
questions there should to go to the ALSA mailing list.

Starting to wonder though if I do need to go PRU/real-time coprocessor
route e,g., Cortex-M4 on same die as microprocessor (e.g, IMX8 and M4,
STM32MP1 A7 w/ M4, AM3358 w/ PRU, etc.).

Thanks,
Alex.