Re: [RFC] Compound GPIO driver

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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?

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

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.

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

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

Yours,
Linus Walleij
--
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