Re: [RFC] Proposal: common kernel-wide GPIO interface

[Jim Cromie <jim.cromie@gmail.com>]

Lennart Sorensen wrote:
> On Tue, Aug 01, 2006 at 03:25:32PM -0600, Jim Cromie wrote:
>   
> > this is cool to see.  Using a class-driver is very different from the 
> > vtable-approach
> > that I used (struct nsc_gpio_ops) in pc8736x_gpio and scx200_gpio.
> >
> > Are any of the limitation youve cited above related to the 
> > /sys/class/gpio paths below ?
> >
> > +	  To set pin 63 to low (to start the motor) do a:
> > +	   $ echo 0 > /sys/class/gpio/gpio63/level
> > +	  Or to stop the motor again:
> > +	   $ echo 1 > /sys/class/gpio/gpio63/level
> > +	  To get the level of the key (pin 8) do:
> > +	   $ cat /sys/class/gpio/gpio8/level
> > +	  The result will be 1 or 0.
> > +
> > +	  To add new GPIO pins at runtime (lets say pin 88 should be an 
> > input)
> > +	  you can do a:
> > +	   $ echo 88:in > /sys/class/gpio/map_gpio
> > +	  The same with a new GPIO pin 95, it should be an output and at 
> > high level:
> > +	   $ echo 95:out:hi > /sys/class/gpio/map_gpio
> > +
> >     
>
> How do you deal with having multiple places that provide GPIOs then? 

pc8736x_gpio and scx200_gpio appear here:

soekris:/sys/devices/platform# ls pc8736x_gpio.0/
Display all 292 possibilities? (y or n)

soekris:/sys/devices/platform# ls scx200_gpio.0/
Display all 532 possibilities? (y or n)


soekris:/sys/devices/platform# ls scx200_gpio.0/bit_0.0_*
scx200_gpio.0/bit_0.0_current_output  scx200_gpio.0/bit_0.0_pullup_enabled
scx200_gpio.0/bit_0.0_debounced       scx200_gpio.0/bit_0.0_status
scx200_gpio.0/bit_0.0_locked          scx200_gpio.0/bit_0.0_totem
scx200_gpio.0/bit_0.0_output_enabled  scx200_gpio.0/bit_0.0_value


Did you mean to ask that question of Robert ?

I'll rephrase my Q here.

/sys/class/gpio/gpio63/

this suggests that either
- only 1 GPIO device can register (bad)
- reservations might be taken in module-load order, and assigned 
numerically (bad-subtle)

Using another path (like /sys/devices/platform/scx200_gpio.%d/ )
which names the driver (or some other structural info) seems much more
stable in the face of combinations of GPIO hardware.

FWIW, I didnt add the .0 to the directories, I think that was added for 
me by the device-core,
(warmfuzzy) so Id expect it to handle .1,2,3 etc..


>  I
> may have 8 pins on a PCI UART chip, 22 on my super io chip, 16 on my
> cpu, etc.  How would this be mapped if you only have one map_gpio
> method?  It is much simpler to code for knowing pin 0 to 7 of device
> uartgpio is where my UART pins are, and some other device has 22 pins
> for the super io chip.  If they all ended up in one place with
> consequative numbers it would be a real pain.  
>
> Sometimes it is also nice to be able to control multiple pins as a block,
> which only a few gpio interfaces seem to provide (they all seem to think
> they should only be moved one pin at a time, which makes for a lot more
> system calls to get things done).
>   
Both GPIO chips Ive touched have port-wide read and write.
I consider it an essential minimum feature in the driver, for hardware 
that supports it.
Other pin features (OE, etc) are only controllable per-pin.
If we synthesize port-wide from per-pin, then we get a bit/port agnostic 
interface.
( driver users must still be cognizant of the limitations of synthetic 
OutputEnable,
where tri-stating would take many bus cycles )

> Right now I am working on adding some stuff to the jsm driver to use an
> Exar uart along with using the gpios, and so far I added gpio access
> similar to how scx200_gpio does things, using minors 0 to 7 for the 8
> pins on the first uart, 8 to 15 for the second, and so on.  What to name
> the /dev entries is a different issue.  I can identify which device to
> look for based on the /sys info for which pci slot the uart is connected
> to.  I am not sure how this would tie into a generic gpio design.
>
> Does your gpio design 
I want to separate my answers -

- pc8736x_gpio , scx200_gpio went thru mm into mainline-rc - they 
support the legacy gpio-bit
access via char-device-file.  They expose port-wide read/write inside 
the kernel, via struct nsc_gpio_ops,
but it seems a bad idea to expose them as device-files. ;-)

- This thread is about a new interface, I think we're all tacitly 
agreeing on :
   a sysfs based GPIO-attr representation
   some of us want/demand a port-interface where hardware has portwide 
read/write
   a reservation scheme.

- Im working on a patch, which rendered the ls output I pasted above.
   bits_ and ports_ agnostic
   interfaces are nearly identical - its 0/1 vs 0xFF (hw dependent width)
   no reservations yet :-/


> deal with all the things gpios often do:
>   
char-dev interfaces in scx200_gpio 18-rc are compatible with legacy, 
pc87360 is new (and same).
my sysfs-gpio patch actually has a half-baked compatibly hack on the 
_status attr,
platform# more scx200_gpio.0/bit_0.0_status
io00: 0x0044 TS OD PUE  EDGE LO DEBOUNCE        io:1/1

> input/output/tristate
> high/low
>   
not yet on these:  patches/clues welcome.
> generate interrupt
> edge/level trigger
> high or low level/leading or trailing edge trigger
>
> --
> Len Sorensen
>
>   

thanks for the input
Jim Cromie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/