Subject: Re: RFC: General purpose "general purpose i/o pin" framework
To: Jason R Thorpe <firstname.lastname@example.org>
From: Dave Sainty <email@example.com>
Date: 09/21/2002 01:56:30
Old topic, I'm catching up :)
Jason R Thorpe writes:
> * When a device (e.g. a generic GPIO facility in an
> I/O processor) wishes to publish its GPIO pins to
> the world, it requests one or more chunks of GPIO
> "pin number" space from the GPIO framework. A mapping
> is then established, e.g. "gpio pin 3 -> i80321 gpio pin 3"
> or "gpio pin 5 -> sc520 gpio pin 9".
> It's worth mentioning that I'm not entirely happy with
> either the dynamic nature of the assignment (what if it
> changes when you add a device?) nor with the fact that
> the mapping might not necessarily be 1 -> 1, 2 -> 2, etc.
> Although, this won't happen unless your system has more
> than one device that wants to publish its GPIO pins.
> * There'll also be a userland API, which takes two forms:
> - An ioctl-based API that looks a lot like the
> kernel API.
> - A /dev/gpioN, where N == pin number, which is meant
> for easy frobbing by scripts. The idea is to do:
It seems awfully easy via this interface to require 100's of devices,
and also somewhat difficult to make any association between device
number and its physical location.
I get the impression you're trying to allow user access to individual
pins based on the device node ownership, hence one node per pin. But
if the number assignment for physical pins isn't tied down this looks
risky, it seems a little too likely to catch people out.
If you used some kind of gpioconfig utility, you could configure up
the properties of a gpio device node and associate sets of pins from
their physical location (addressed how though, I'm not sure). And
perhaps some other simple properties, like associating per-write
clocking pins and stuff. Perhaps support things like I2C through this
interface too, where the hardware supports it - or perhaps in software
That would limit the need for bulk quantities of device nodes, would
give you by-group-membership device access, and solve at least some of
the performance concerns.
I question the need to allow scripts to toggle a pin with an "echo" :)
If someone is writing a program as a script then obviously speed isn't
too important. I think running 'gpioctl -d /dev/gpio0 toggle 0'
wouldn't be a big hardship :)
But Herb's state machine idea would be cooler! You could do away with
all those pesky SCSI / network card drivers, everything could be
written in terms of gpio state machines :)