On Wed, Aug 14, 2024 at 10:58 AM Conor Dooley <conor@xxxxxxxxxx> wrote: > > On Fri, Jul 26, 2024 at 02:17:00PM -0500, David Lechner wrote: > > On 7/26/24 7:38 AM, Rob Herring wrote: > > > On Mon, Jul 22, 2024 at 04:57:12PM -0500, David Lechner wrote: > > >> The AXI SPI Engine has support for hardware offloading capabilities. > > >> There can be up to 32 offload instances per SPI controller, so the > > >> bindings limit the value accordingly. > > >> > > >> Signed-off-by: David Lechner <dlechner@xxxxxxxxxxxx> > > >> --- > > >> > > >> RFC: I have a few questions about this one... > > >> > > >> 1. The trigger-source properties are borrowed from the leds bindings. > > >> Do we want to promote this to a generic binding that can be used by > > >> any type of device? > > > > > > I would make it specific to spi-offload. > > > > OK > > > > Meanwhile, we are working on some other ADCs (without SPI offload) and > > finding that they are using basically the same sorts of triggers. And > > on the driver side of things in this series, I'm getting feedback that > > we should have some sort of generic trigger device rather than using, > > e.g. a clk directly. If we need this same sort of trigger abstraction > > for both SPI offloads and IIO device, it does seems like we might want > > to consider something like a new trigger subsystem. > > A "device" in the sense that "pwm-clk" is a device I suppose. > In simple cases, yes it could be like "pwm-clk" where a PWM/clock/gpio is used directly as the trigger. We also have a case where there is a PWM output combined with a clock output using an AND gate, so more of a "real" device. And finally, there is actual dedicated hardware, like this [1] time division duplexing (TDD) controller that, in addition to it's primary purpose for RF applications, can be used as a general purpose trigger source - mostly useful for creating burst of a finite number of pulses. [1]: http://analogdevicesinc.github.io/hdl/library/axi_tdd/index.html > Are any of > these other things WIP on the lists (that I may have missed while I was > away) or are they still something you're working on internally. My ideas on actual trigger devices and bindings are still mostly on paper, but we do have a couple of ADCs on the mailing lists right now where I think it would make more sense to have a flexible "trigger" but we have been making due with what is currently available. ad7525 In this case, we need two coordinated triggers for the CNV and CLK signals, one that generates a single pulse and one that generates a burst of 16 or 18 pulses, both repeating periodically. Right now, the proposed DT bindings only allow specifying a PWM to provide the CNV signal and a second PWM combined with a clock and an AND gate (same one mentioned above) to provide the CLK signal because that is the reference hardware design. But technically if one wanted to use, for example, the aforementioned TDD controller to create these signals for CNV and CLK instead, it should work just the same. [ad7525]: https://lore.kernel.org/linux-iio/20240809-ad7625_r1-v2-0-f85e7ac83150@xxxxxxxxxxxx/ ad4030 This also needs a CNV trigger, but it works slightly differently than ad7525. For now, the proposed DT bindings just have a cnv-gpios to describe what is connected to the CNV pin. But for certain applications, a GPIO is not the best choice. For example, to use the oversampling feature of the chip, we have to provide a burst of some power of 2 pulses, up to 16k pulses, with specific timing to trigger 2**N conversions before reading one sample. This can be done by bit-banging the GPIO but could be done much better/faster by something like the TDD controller that is specifically designed to create a burst of a finite number of pulses. [ad4030]: https://lore.kernel.org/linux-iio/20240627-eblanc-ad4630_v1-v1-0-fdc0610c23b0@xxxxxxxxxxxx/ Having a generic DT binding for these ADC input pins that can be connected to a wide variety of outputs seems more future proof than having to modify the bindings each time someone wants to support a new type of output provider.
