Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

[David Brownell <david-b@pacbell.net>]

On Monday 28 April 2008, Ben Nizette wrote:
>
> Ah well we're backwards there, though now I think of it I can't think of
> a great many valid use-cases on my side.  Just for funzies I'll post on
> the avrfreaks AVR32 support forum and see how many I can actually dig
> up.

Use cases would always help clarify things.  I've seen just
enough to make me understand this is a useful feature, and
for more reasons than just "feature equality" letting us
obsolete three drivers/i2c/chips/*.c drivers and help vanish
half a dozen (at least!) out-of-tree drivers doing that.

The Gumstix user forums and wiki may help too.  ISTR they
have such a GPIO widget (maybe that's the one I saw which
supports polling?) and have shipped it for ages ... so they
will surely have some (PXA-specific) examples lurking.


> > Trent pointed out that dynamic range assignment can make trouble,
> > so I can see some help might be needed here.  Were you suggesting
> > something like a /sys/class/gpio/chips file with contents like
> > 
> > 	0-15	gpio
> > 	16-31	gpio
> > 	32-47	gpio
> > 	48-63	gpio
> > 	192-207	mpuio
> > 	208-213	tps65010
> > 
> > (Matching a stock OMAP 5912 OSK board, for what it's worth.)
> 
> Yeah that's the kind of a thing.  Would be well worth having that info
> especially for dynamically allocated chip bases.

I'd have no problem with that.  Some people surely would though;
it has more than one value in that file!  OMG, it's readable! We
can't have any of that!!  The Earth will turn in its grave!  And
Slashdot will be decorated in Pink!  Teh End Daze arrive!  :)

 
> > > > The D-space footprint is negligible, except for the sysfs resources
> > > > associated with each exported GPIO.  The additional I-space footprint
> > > > is about half of the current size of gpiolib.  No /dev node creation
> > > > involved, and no "udev" support is needed.
> > > 
> > > Which is good for simplicity but makes async notification kinda tricky.
> > 
> > Sysfs attributes are supposed to be pollable.  I've not done it,
> > but fs/sysfs/file.c::sysfs_notify() looks relevant ...
> 
> Right, that'll work.

OK.  In that case, I think I should plan to rename the "direction"
attribute as "configuration" or something a bit broader ... so that
writing "irq" (or maybe "rising", "falling", "bothedges", "poll")
would eventually configure it as an input with an IRQ handler.

Whenever someone contributes such an async notification scheme,
that is.  ;)

- Dave