[lkml]   [2006]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Proposal: common kernel-wide GPIO interface
On Wed, Aug 02, 2006 at 02:48:33PM -0600, Jim Cromie wrote:
> 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

Hmm, that certainly is different than the old /dev/... interface. Could
be nice.

> Did you mean to ask that question of Robert ?

I might have. :)

> I'll rephrase my Q here.
> /sys/class/gpio/gpio63/
> this suggests that either
> - only 1 GPIO device can register (bad)

Unacceptably bad. I currently use anywhere from 2 to 4 different
devices with GPIOs.

> - reservations might be taken in module-load order, and assigned
> numerically (bad-subtle)

Too messy.

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

That I think is perfectly easy to work with, as long as I can somehow
find which device (usually on PCI bus in my case) goes to which
directory. I suspect that would be the case.

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

That sounds nice and convinient.

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

I only consider the change of state on output pins, or reading state of
input pins to be a requirement for port-wide. Changing between
input/output, and enable and tristate and such, I have no problem with
doing bit by bit, since that is setup stuff.

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

Well I haven't seen a gpio driver that did port wide yet. I treat the
ppdev as 8 gpio pins, so at least for that I get port wide.

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

Sounds lovely to me.

> - 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 :-/

I look forward to seeing it.

> 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

Keeping the legacy for at least a while is probably a requirement since
people are already using those interfaces on that hardware.

> not yet on these: patches/clues welcome.
> >generate interrupt
> >edge/level trigger
> >high or low level/leading or trailing edge trigger

Well tying into interrupt handlers would be tricky I suspect. On the
other hand someone might have a use for the feature. I just mentioned
them because it is a feature of some of the devices I use, although I
don't use them for anything other than input/output myself.

Len Sorensen
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-08-03 15:59    [W:0.096 / U:63.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site