They wouldn't want names so easily confused with the current set
of GPIO calls, no.
But if they're using GPIOs as a low-bandwidth parallel bus they'd
most *certainly* need to be able to read, not just write. That's
what the "I" part of "GPIO" represents: "I"nput (vs "O"utput).
Doesn't necessarily need to be *you* doing that, but if it only
works on older gumstix boards it'd not be general enough. Which
is part of why I say to get the lowest level proposal out there
first. If done right, it'll be easy to support on other chips.
... including probably ganged request/free, and direction updates.
When bitbanging a multiplexed parallel databus, you'll often need
to change directions.
Kind of verbose for my taste, and it's already "multibit" (one
at a time, but still multiple) ... let's see some more mergeable
proposals and code first. Different C file too, I suspect.
The gpio_*() interfaces are how system glue code and drivers
access GPIOs, unless they roll their own chip-specific calls.
Whereas gpiolib (and gpio_chip) are an *optional* framework
for implementing those calls. Platforms can (and do!) use
other frameworks ... maybe they don't want to pay its costs,
and don't need the various GPIO expander drivers.
So to repeat: don't assume the interface is implemented in
one particular way (using gpiolib). It has to make sense
with other implementation strategies too. Standard split
between interface and implementation, that's all. (Some folk
have been heard to talk about "gpiolib" as the interface to
drivers ... it's not, it's a provider-only interface library.)
- Dave
--
