On Tue, Jun 15, 2021 at 12:37 PM Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: > > 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. 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
