[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.036 / U:5.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site