Message-ID: <20240628195106.215839df@jic23-huawei>
Date: Fri, 28 Jun 2024 19:51:06 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: "Tinaco, Mariel" <Mariel.Tinaco@...log.com>
Cc: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Lars-Peter
 Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Liam
 Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 "Hennerich, Michael" <Michael.Hennerich@...log.com>, Marcelo Schmitt
 <marcelo.schmitt1@...il.com>, Dimitri Fedrau <dima.fedrau@...il.com>,
 Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 2/2] iio: dac: support the ad8460 Waveform DAC

On Mon, 24 Jun 2024 04:56:57 +0000
"Tinaco, Mariel" <Mariel.Tinaco@...log.com> wrote:

> > -----Original Message-----
> > From: Jonathan Cameron <jic23@...nel.org>
> > Sent: Sunday, May 12, 2024 12:44 AM
> > To: Tinaco, Mariel <Mariel.Tinaco@...log.com>
> > Cc: linux-iio@...r.kernel.org; devicetree@...r.kernel.org; linux-
> > kernel@...r.kernel.org; Lars-Peter Clausen <lars@...afoo.de>; Rob Herring
> > <robh@...nel.org>; Krzysztof Kozlowski <krzk+dt@...nel.org>; Conor Dooley
> > <conor+dt@...nel.org>; Liam Girdwood <lgirdwood@...il.com>; Mark Brown
> > <broonie@...nel.org>; Hennerich, Michael <Michael.Hennerich@...log.com>;
> > Marcelo Schmitt <marcelo.schmitt1@...il.com>; Dimitri Fedrau
> > <dima.fedrau@...il.com>; Guenter Roeck <linux@...ck-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@...log.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@...log.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.

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

Jonathan

Powered by blists - more mailing lists