Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

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

On Saturday 29 November 2008, Jaya Kumar wrote:
> On Sun, Nov 30, 2008 at 6:54 AM, David Brownell <david-b@pacbell.net> wrote:
> > If you want to pursue this, I'd like to get the gpio_chip
> > proposal in place first:  bitmask read and write, without
> > forcing an "all bits are contiguous" policy.  Lightweight.
> 
> Yup, yup, I definitely want to pursue it. I want Linux e-paper
> displays to be zippy. :-) Agreed, I will do bitmask read and write.
> Hey, wait a sec, bitmask write definitely. but bitmask read is
> peculiar to me. I can understand the caller would want to do something
> like foo = gpio_get_values(gpio, bitwidth). But would they really want
> to do foo = gpio_get_values(gpio, bitwidth, bitmask) rather than deal
> with it appropriately themselves?

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).


> > Maybe it should suffice to have a gpio_chip support the
> > bitmask ops, instead of just bit-at-a-time ones... so it'd
> > be practical to incorporate this by itself, given patches
> > to convert a couple gpio_chip implementations.
> 
> Ok, you've scared me there. I only have a Gumstix board so I can do it
> for the pxa255 but will need help if more platforms are needed.
> Exploiting this opportunity for hardware whoring, if anyone wants to
> send me free hardware, I'll be ecstatic and will eagerly do support
> duty on said platforms. :-)

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.


> >
> > Then separately two more things:
> >
> >  - A gpio_* interface proposal for higher-level bitmask calls.
> >   This is worth some discussion; the calls should clearly
> >   be optional (not everything will implement them), and I
> >   can't help but suspect <linux/bitmap.h> interfaces should
> >   interoperate smoothly.

... including probably ganged request/free, and direction updates.
When bitbanging a multiplexed parallel databus, you'll often need
to change directions.


> >
> >  - A gpiolib based implementation, using those new gpio_chip
> >   methods as accelerators if they're present.  This should
> >   probably also be optional, even at the Kconfig level; many
> >   systems won't need to spend memory on these calls.
> 
> Understood. I will make it optional. Does
> CONFIG_GPIOLIB_MULTIBIT_ACCESS sound okay?

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.


> > Don't assume gpiolib when defining the interface.
> 
> Ok, I didn't understand this part. I think you mentioned a higher
> level interface before but I didn't fully understand, if not gpiolib,
> then at what level do you recommend?

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