Re: [RFC] Compound GPIO driver

[Einar Vading <einar.vading@xxxxxxxx>]

On Tue, Jun 26, 2018 at 11:28:30AM +0200, Linus Walleij wrote:
> On Wed, Jun 20, 2018 at 10:26 AM Einar Vading <einar.vading@xxxxxxxx> wrote:
> 
> > I was hoping to get some feedback for a GPIO driver that I'm considering writing.
> 
> This is the right place to ask! :)

:)

> > Background:
> > Having SOC GPIOs exposed to end users of a product may not always
> > be a good idea. F.ex. I may want to have +-60V tolarant IOs that can
> > source/sink hundreds of mA. One way to solve that is to put more
> > robust FETs (or something), in some configuration, between the user
> > accessible pin and the SOC pad. Reconstructing the SOC GPIO block
> > outside the chip in a way. Having dedicated SOC GPIOs for
> > pull-up/down, input and output and so on.
> 
> That is sort of like adding a "driver stage" outside of the SoC
> I guess.
> 
> SoC GPIO -> driver stage -> actual pin
> 
> And the driver stage is controlled by additional GPIO lines.
> 
> Right?

Yes, something like this:

                            VDD
                             |
     OUT                 ||--+
   SOC GPIO -------------||
                         ||--+
                             |
          SOC VDD            |
             |               |
            | |              |
            | |              |
            |_|              |
     IN      |              | |
   SOC GPIO -+--||          | | PU
                ||-----+    |_|
             +--||     |     |
             |         |     |
            GND        |     |
                       |     |
                   VDD |     |
                    |  |     |
      OUT       ||--+  |     |
   SOC GPIO  ---||     |     |
                ||--+  |     |
                    +--+-----+----- Rugged GPIO
     OUT        ||--+        |
   SOC GPIO  ---||           |
                ||--+       | |
                    |       | | PD
                   GND      |_|
                             |
     OUT                 ||--+
   SOC GPIO  ------------||
                         ||--+
                             |
                            GND

Where some things may be optional. F.ex. Open Drain only or no pull-up/downs.

> > Proposed solution:
> > Having a driver that, controlled by DT, could build Linux GPIOs
> > from groups of GPIOs with different functions.
> 
> That looks like it could be done!
> 
> It would be a GPIO built from GPIOs, but we have done crazier
> things.
> 
> > Maybe this already exists? I have a hard time believing
> > that we are the only ones building rugged GPIOs like this.
> 
> I have never seen anything like this before, but it sure looks
> interesting.

So we are special snowflakes after all =)

> Your driver should probably be in drivers/pinctrl and those
> drivers are more complex, but they provide the APIs you need
> for pull up/down, drive strength etc so there will be a bit of
> overhead.
> 
> I would recommend that you look at a complex one-chip
> GPIO expander solution like
> drivers/pinctrl/pinctrl-sx150x.c
> there you have something that is doing both GPIO and
> pin control and has dealt with the issues involved with
> a combined driver.

Thanks for the tip, that driver looks like a really good starting
point.

> It involves sorting the pins into groups (maybe one-pin
> per group) and using a mapping between pins and GPIOs
> but hopefully you can get the hang of it.
> 
> Another solution (that I am more uncertain of) would be
> to just use drivers/gpio/* with only the .set_config() API,
> and keeping track of all the GPIO lines used to control
> the actual GPIO inside of this driver.
> 
> This has the advantage that the API is simpler, and the
> .set_config() callback does support all things that pin
> config does. But I'm uncertain about the implications
> wrt device tree: there is no DT flags for providing these
> settings as arguments to a 2-cell DT handle, and you
> will run into problems with the specification and generic
> DT bindings. Those bindings already exist in the
> pin control case i.e.
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

It sounds like I would have to "reinvent" many of the pinctrl-bindings
allover again. So I'll try my luck with the pinctrl solution first.

> William Beathitt Gray is doing some heavy-duty industrial
> I/O solutions albeit using EISA cards, and might have
> additional feedback.

Super, thanks for all the feedback.

> Yours,
> Linus Walleij

Regards,
Einar Vading
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html