Re: using dma buffers for SPI adcs

[Lars-Peter Clausen <lars@metafoo.de>]

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