RE: [PATCH 2/2] iio: dac: support the ad8460 Waveform DAC

Tinaco, Mariel
2024-07-07T23:33:06Z

> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Saturday, June 29, 2024 2:51 AM
> To: Tinaco, Mariel <Mariel.Tinaco@analog.com>
> Cc: linux-iio@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; Lars-Peter Clausen <lars@metafoo.de>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Liam Girdwood <lgirdwood@gmail.com>; Mark Brown
> <broonie@kernel.org>; Hennerich, Michael <Michael.Hennerich@analog.com>;
> Marcelo Schmitt <marcelo.schmitt1@gmail.com>; Dimitri Fedrau
> <dima.fedrau@gmail.com>; Guenter Roeck <linux@roeck-us.net>
> Subject: Re: [PATCH 2/2] iio: dac: support the ad8460 Waveform DAC
>
> [External]
>
> On Mon, 24 Jun 2024 04:56:57 +0000
> "Tinaco, Mariel" <Mariel.Tinaco@analog.com> wrote:
>
> > > -----Original Message-----
> > > From: Jonathan Cameron <jic23@kernel.org>
> > > Sent: Sunday, May 12, 2024 12:44 AM
> > > To: Tinaco, Mariel <Mariel.Tinaco@analog.com>
> > > Cc: linux-iio@vger.kernel.org; devicetree@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Lars-Peter Clausen <lars@metafoo.de>; Rob
> > > Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>;
> > > Conor Dooley <conor+dt@kernel.org>; Liam Girdwood
> > > <lgirdwood@gmail.com>; Mark Brown <broonie@kernel.org>; Hennerich,
> > > Michael <Michael.Hennerich@analog.com>; Marcelo Schmitt
> > > <marcelo.schmitt1@gmail.com>; Dimitri Fedrau
> > > <dima.fedrau@gmail.com>; Guenter Roeck <linux@roeck-us.net>
> > > Subject: Re: [PATCH 2/2] iio: dac: support the ad8460 Waveform DAC
> > >
> > > [External]
> > >
> > > On Fri, 10 May 2024 14:40:53 +0800
> > > Mariel Tinaco <Mariel.Tinaco@analog.com> wrote:
> > >
> > > > The AD8460 is a “bits in, power out” high voltage, high-power,
> > > > highspeed driver optimized for large output current (up to ±1 A)
> > > > and high slew rate (up to ±1800 V/μs) at high voltage (up to ±40
> > > > V) into capacitive loads.
> > > >
> > > > A digital engine implements user-configurable features: modes for
> > > > digital input, programmable supply current, and fault monitoring
> > > > and programmable protection settings for output current, output
> > > > voltage, and junction temperature. The AD8460 operates on high
> > > > voltage dual supplies up to ±55 V and a single low voltage supply of 5 V.
> > > >
> > > > Signed-off-by: Mariel Tinaco <Mariel.Tinaco@analog.com>
> > >
> > > I'd like to see some ABI docs for the debugfs interface.
> > > The device is unusual enough that a general intro document or a lot
> > > more in the series cover letter would be useful.
> > >
> > > I'm not sure what the dmaengine usage in here is doing for example?
> > > Driving the parallel bus perhaps? David was correct that the
> > > binding should reflect that part as well. I was assuming you'd only
> implemented the spi part.
> > >
> > > How to handle the pattern generator is also an interesting question.
> > > That probably wants a version of the symbol interfaces we use for
> > > PSK and similar. We did have some DDS drivers a long time back in
> > > staging but they only did a few fixed waveforms so this is breaking new
> ground.
> >
> > I also thought about how should the pattern generator be handled. IN
> > the last revision, there were two debug attributes that make up this
> > feature. Pattern depth and pattern memory. Ultimately I found a way to
> > combine these two attributes into one called "test_pattern". The
> > attribute is a string containing an array of values with a maximum of
> > 16 data words, which the DAC will cycle through to generate a pattern.
> > The number of values within the string can be anywhere between 1 to 16 and
> have a space in between. I also added a "test_pattern_enable"
> > debug attribute. For the ABI file, should I create one alongside other "debugfs-
> *"
> > files and just mention the name of the part? e.g. "debugfs-driver-ad8460"
>
> Doing this in debugfs basically means you aren't intending it to get used in real
> usecases. So we need some sysfs ABI.
>
> That probably means a mode switch similar to the ones we have for devices that
> use an external toggle (typically for Frequency Shift Keying or similar or
> sometimes just to flip between two DC voltages). We need a new term though
> as this isn't a toggle.
>
> For the values we could map it to that interface which is something like
>
> out_voltage0_raw0
> out_voltage0_raw1
>
> etc. That avoids need for a new ABI for the values, but perhaps isn't that elegant
> if the patterns on other devices we eventually support this on get large.

I saw some drivers making use of "test_pattern" attribute. I think that might fit.
But I'd look into "raw0" and "raw1" as well

>
> Anyone know how large these typically get? I'm being lazy and don't want to
> datasheet dive this evening!

It only gets up to 16 values.

>
> Jonathan