RE: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one bit ADC-DAC

[Sa, Nuno]

Hi Jonathan,

> From: Jonathan Cameron <jic23@xxxxxxxxxx>
> Sent: Sunday, January 16, 2022 12:52 PM
> To: Pop, Cristian <Cristian.Pop@xxxxxxxxxx>
> Cc: linux-iio@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> robh+dt@xxxxxxxxxx
> Subject: Re: [PATCH v2 2/2] one-bit-adc-dac: Add initial version of one
> bit ADC-DAC
> 
> [External]
> 
> On Tue, 11 Jan 2022 13:59:19 +0200
> Cristian Pop <cristian.pop@xxxxxxxxxx> wrote:
> 
> > This allows remote reading and writing of the GPIOs. This is useful in
> > application that run on another PC, at system level, where multiple
> iio
> > devices and GPIO devices are integrated together.
> Hi Cristian,
> 
> So I fully understand why this can be useful, but it is a software only
> construction so I'm not convinced that it makes sense to necessarily
> configure it via device tree.   A better fit may well be configfs.
> (note I always meant to add configfs controls for iio_hwmon but
> haven't
> found the time to do it yet...)
> 
> As it currently stands, doing only polled / sysfs reads this driver doesn't
> do enough to justify its existence. You could just do all this in
> userspace
> using the existing gpio interfaces.  So to be useful I'd expect it to
> at least do triggered buffer capture.
> 
> When we have talked about handling digital signals int he past we
> discussed
> whether the IIO channel description would also benefit from tighter
> packing
> than the current minimum of a byte per channel.  Perhaps we don't

That reminded me about this series [1] Alex tried to upstream. It's slightly
related and this was all about supporting buffered channels with less than
8 bits (IIRC). I didn't went through the all thread but I remember you had some
"questions" about the whole thing. That series is something that I definitely want
to revive at some point (might be that I just need to change things in ADI kernel)
to stop having these custom patches in our tree.

> technically
> 'need' it here but if we do add it in future it will be hard to retrofit into
> this driver without big userspace ABI changes (i.e. breaking all existing
> users).

I think this is the perfect opportunity to add support for it (either with the series
I mentioned or something else) if we ever really want to have this in IIO. 


[1]: https://lore.kernel.org/linux-iio/20200424051818.6408-1-alexandru.ardelean@xxxxxxxxxx/
- Nuno Sá