Re: RFC for a GPIO input muxer

[Drew Fustini <drew@beagleboard.org>]

On Mon, Mar 22, 2021 at 06:09:40PM +0100, Mauri Sandberg wrote:
> 
> 
> > ----------------------------------------
> > From: Drew Fustini <drew@beagleboard.org>
> > Sent: Mon Mar 22 07:19:16 CET 2021
> > To: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Cc: Mauri Sandberg <sandberg@mailfence.com>, Linux GPIO <linux-gpio@vger.kernel.org>
> > Subject: Re: RFC for a GPIO input muxer
> > 
> > 
> > On Wed, Mar 17, 2021 at 02:30:50PM +0200, Andy Shevchenko wrote:
> > > +Cc: Drew, I believe he has some thoughts about.
> > > 
> > > On Wed, Mar 17, 2021 at 1:17 AM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > On Tuesday, March 16, 2021, Mauri Sandberg <sandberg@mailfence.com> wrote:
> > > >>
> > > >> I am writing to you to ask for comments on the preferred way of implementing a 4-way GPIO multiplexer in the most generic way. The situation is that there is a dual 4-way multiplexer on my device and its select pins a controlled with GPIOs. The output pins of the multiplexer are connected to two other GPIOs. The datasheet of the multiplexer is here: https://assets.nexperia.com/documents/data-sheet/74HC_HCT153.pdf
> > > >>
> > > >> This is what I have been contemplating on but I am not aware if the same could be achieved with existing pinctrl or gpio driver or combination of those.
> > > >
> > > >
> > > > To me looks like a typical pinmux. Dunno if pinctrl supports pure pinmux and how it can handle that at runtime.
> > 
> > Regarding runtime pinmux, this patchset by myself was recently merged
> > and might be of interest [1].
> Thanks, I'll have a look.
> 
> > 
> > > >
> > > >  That said, I would consider what has been done in pinctrl for that.
> > > >>
> > > >>
> > > >> The 'key-mux1' below implements a gpio-controller that drives the multiplexer and provides gpios for reading device key presses. At the moment it has to be polled as interrupts are not being generated by the key presses. I tried looking around but software interrupts did not give me any hits.
> > > >>
> > > >> I have omitted 'key-mux2' from this for clarity.
> > > >>
> > > >> mux: mux-controller {
> > > >>         compatible = "gpio-mux";
> > > >>         #mux-control-cells = <0>;
> > > >>
> > > >>         mux-gpios = <&gpio 9 GPIO_ACTIVE_HIGH>,         /* s0 */
> > > >>                     <&gpio 11 GPIO_ACTIVE_HIGH>;        /* s1 */
> > > >> };
> > > >>
> > > >> gpio2: key-mux1 {
> > > >>         compatible = "gpio-mux-input";
> > > >>         mux-controls = <&mux>;
> > > >>
> > > >>         gpio-controller;
> > > >>         #gpio-cells = <2>;
> > > >>
> > > >>         // GPIOs used by this node, mux pin
> > > >>         pin-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;        /* 1y */
> > > >> };
> > 
> > I don't see "gpio-mux-input" in mainline so I presume you wrote a driver
> > than uses this binding?  If so, could you share the code?
> Oh yes, the code is at [2]. I  must apologize as it's still WIP but it should convey the general idea. It looks for a multiplexer, then proceeds to grab a GPIO pin and finally creates a gpio_chip.
> 
> Before polishing up I though it might be better to ask first if it is even the right approach.

I would recommend posting your RFC again but as a RFC patch containing
the new code. I was confused at first until I realized that you were
refering to new code that you had written but not yet shared. I believe
it is ok for the code in an RFC to have some problems if your goal is
to get feedback on the general approach.

I think regular gpio reviewers like Andy, Bartosz, Geert, Kent and Linus
will provide some opinions if you post the code.


Regards,
Drew