Re: [RFC] Compound GPIO driver

[Einar Vading <einar.vading@xxxxxxxx>]

On Tue, Jun 26, 2018 at 02:41:12PM -0400, William Breathitt Gray wrote:
> 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?
> >
> >> 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
> 
> Hmm, I'm not sure I have much additional feedback at the moment but this
> does sound like an interesting idea because many industrial I/O cards
> feature a mixmatch of various GPIO to a diverse set of specifications.
> For example, the PCIe-IDIO-24 device has several opto-isolated inputs
> for high noise signals, while also featuring regular TTL GPIO for
> general use. These I/O have very different intended use-cases yet are
> featured on the same device, so being able to configure and expose these
> groups of GPIO independently has some merit.
> 
> Einar, please CC me on any future patches or discussions regarding this
> because I would like to keep an eye on its development as it progresses.
> It's possible that this could become useful for some of the industrial
> applications I encounter, and I may chime in with my own suggestions in
> the future as well. ;-)

Sure thing, will do.

> Thank you,
> 
> William Breathitt Gray

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