> -----Original Message----- > From: Jonathan Cameron <jic23@xxxxxxxxxx> > Sent: Saturday, June 29, 2024 2:51 AM > To: Tinaco, Mariel <Mariel.Tinaco@xxxxxxxxxx> > Cc: linux-iio@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; Lars-Peter Clausen <lars@xxxxxxxxxx>; Rob Herring > <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley > <conor+dt@xxxxxxxxxx>; Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown > <broonie@xxxxxxxxxx>; Hennerich, Michael <Michael.Hennerich@xxxxxxxxxx>; > Marcelo Schmitt <marcelo.schmitt1@xxxxxxxxx>; Dimitri Fedrau > <dima.fedrau@xxxxxxxxx>; Guenter Roeck <linux@xxxxxxxxxxxx> > 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@xxxxxxxxxx> wrote: > > > > -----Original Message----- > > > From: Jonathan Cameron <jic23@xxxxxxxxxx> > > > Sent: Sunday, May 12, 2024 12:44 AM > > > To: Tinaco, Mariel <Mariel.Tinaco@xxxxxxxxxx> > > > Cc: linux-iio@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux- > > > kernel@xxxxxxxxxxxxxxx; Lars-Peter Clausen <lars@xxxxxxxxxx>; Rob > > > Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; > > > Conor Dooley <conor+dt@xxxxxxxxxx>; Liam Girdwood > > > <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; Hennerich, > > > Michael <Michael.Hennerich@xxxxxxxxxx>; Marcelo Schmitt > > > <marcelo.schmitt1@xxxxxxxxx>; Dimitri Fedrau > > > <dima.fedrau@xxxxxxxxx>; Guenter Roeck <linux@xxxxxxxxxxxx> > > > 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > > > 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
