Re: [RFC] Proposal: common kernel-wide GPIO interface
From: Jim Cromie
Date: Wed Aug 02 2006 - 16:46:03 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/