Re: [RFC] Compound GPIO driver

[William Breathitt Gray <vilhelm.gray@xxxxxxxxx>]

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

Thank you,

William Breathitt Gray
--
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