GPIO hint meanings

[John Hein]

Ian Lepore wrote at 16:27 -0600 on Sep  6, 2013:
 > On Fri, 2013-09-06 at 16:13 -0600, Warner Losh wrote:
 > > On Sep 6, 2013, at 4:00 PM, Ian Lepore wrote:
 > > > On Fri, 2013-09-06 at 13:42 -0600, Warner Losh wrote:
[snip]
 > > >> We really need a pinmux/pinctl type interface for this which is standard across drivers/platforms.
 > > >
 > > > The more ARM SoCs I look at, the less I think we could design a single
 > > > pinmux api that works for all of them.  The number of things that can be
 > > > controlled varies from almost-nothing to chips that let you select from
 > > > one of a dozen different resistor strengths for pullup or pulldown per
 > > > pin.  And that's not to mention really crazy things like daisy-chaining
 > > > pins so the signal also goes to another pin which can be forced as an
 > > > input even though it's normally a device output.
 > >
 > > Linux is able to have one, although I'm not sure how they handle the daisy-chain... that's a new one on me...
 >
 > Maybe they just don't, since it's a weird enough thing that probably
 > nothing uses it.  I only discovered it because the datasheet said it was
 > a potential workaround for an erratum that had to do with a device not
 > handling a pin properly.

They love their special filesystems, they do.  I suspect the first
hacker to add support for fancy new GPIO feature for whatever gets to
pick the "filename" in the /sys/clas/gpio/gpioX tree or special value
to echo > to it.

https://www.kernel.org/doc/Documentation/gpio.txt


 > The semi-related thing I've been pondering lately is clock and power
 > management.  I don't even care about dynamic stuff, just a simple common
 > way for a driver to figure out what clock(s) and/or power need to be on
 > for it to run, and a common api for turning them on would be nice.
 > (Whether clocks and power should be two separate APIs or not is a basic
 > question.)