lkml.org 
[lkml]   [2006]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Proposal: common kernel-wide GPIO interface
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/

\
 
 \ /
  Last update: 2006-08-02 22:51    [W:0.103 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site