Dynamically configured channels, overlap with GPIO, encoder support

Dynamically configured channels, overlap with GPIO, encoder support

[Giedrius Trainavičius]

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? 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?

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

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.

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.

Thank you!
Giedrius.

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

[Andy Shevchenko]

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? 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?
>
> 2. Can IIO channels be appended and removed to/from the list during runtime?
>
> 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.
>
> 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.

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.


-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

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