Re: Dynamically configured channels, overlap with GPIO, encoder support

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 28 Jun 2022 14:35:20 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, Jun 28, 2022 at 12:06 PM Giedrius Trainavičius
> <giedrius@blokas.io> wrote:
> >
> > Hello,
> >
> > I am developing an extension board for Raspberry Pi, it has a
> > microcontroller on it and I'm trying to expose its pins as a I/O
> > expander via I²C bus. I've recently successfully implemented gpiochip
> > interface as well as irq_chip in a kernel module, and now I'm looking
> > at adding ADC support, Industrial IO seems like a good candidate for
> > exposing it, but I have a couple of questions:
> >
> > 1. Can the IIO channels be configured dynamically?

Nope. You'd need to remove and probe the device again.

> On the
> > microcontroller, the same pins can be used for GPIO, ADC, etc... - can
> > things like the channel direction, the function (simple high or low
> > GPIO pin, ADC, PWM output) be configured by userspace programs? Can it
> > be configured within a kernel module, if I provide my own sysfs
> > interface for function setup?

As a general rule, a pin is wired to one thing on a given board, so it very
rarely makes sense to actually configure these at runtime.  Normally you
push that complexity to device tree.  Sure there are cases with dev boards
etc where this isn't a perfect fit but having to unbind a driver and rebind
it with a new DT overlay isn't too bad and makes things a lot simpler
for the common case of not wanting to do anything dynamic.

> >
> > 2. Can IIO channels be appended and removed to/from the list during runtime?

Not with a bound driver.

> >
> > 3. Are encoders supported by IIO? I'd like to decode encoders within
> > the firmware of the microcontroller, and provide only
> > increments/decrements to the kernel module via I²C, can encoders built
> > in such a way be exposed via IIO? I've seen some patches on the
> > internet adding 'counter' interface to IIO, but it seems it never made
> > it to be within IIO, and instead the 'counter' in its own subsystem.

Other way around.  Counters were supported in IIO, but the fit was not good
so in the end the counter subsystem was written to handle them better and
we've since moved all the drivers over.

> >
> > 4. How does IIO interact with gpiochip? As I'm implementing gpiochip
> > interface, I could simply return -EBUSY for pins already used by the
> > other subsystem.
It doesn't.  You need to control the usecases before binding drivers (calling
probe etc) so that each driver is told only about the 'channels / pins'
that it has access.

Wrapping such a device up as an MFD with appropriate registration functions
to handle management is one way to handle this.

> 
> We have a DLN2 adapter that provides 4 interfaces with overlapped GPIO
> pins, I don't remember how they solved this. Perhaps the
> microcontroller itself refuses GPIO line acquisition when it's in use
> for other functions.
> 
> Hence, I recommend looking into the drivers for Diolan DLN2.
> 
Good suggestion.

Jonathan