On 6/14/21 12:59 PM, Jonathan Cameron wrote:
On Sat, 12 Jun 2021 19:33:32 -0500
Alex Roberts <alex.roberts@xxxxxxxx> 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
