Date:	Thu, 3 Aug 2006 09:55:58 -0400
From:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
To:	Jim Cromie <jim.cromie@...il.com>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Chris Boot <bootc@...tc.net>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists