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

["Jaya Kumar" <jayakumar.lkml@gmail.com>]

Hi David,

On Mon, Dec 29, 2008 at 2:32 PM, David Brownell <david-b@pacbell.net> wrote:
>
>  - passing bitmasks as {unsigned long *bits, int count} tuples
>  - separate calls to:
>     * zero a set of bits (loop: gpio_set_value to 0)
>     * fill a set of bits (loop: gpio_set_value to 1)
>     * copy a set of bits (loop: gpio_set_value to src[i])
>     * read a set of bits (loop: dst[i] = gpio_get_value)
>     * ... maybe more

I had read bitmasks.h as per your recommendation and my thought on
that was: How do I reconcile such a substantial API when the use case
is just setting/getting a bunch of gpio pins?

>
> Any restriction to 32 bit value seems shortsighted.  It would
> make sense to wrap the GPIO bitmask descriptions in a struct,
> letting drivers work with smaller sets -- probably most would
> fit into a single "unsigned long".
>

Hmm. Well. Currently, there's only been 1 bit support and its been
that way for years, hasn't it? It was not shortsighted at that time to
have only 1 bit access. No one raised a need for more. There weren't
any complaints about the 1-bit gpio API until am300epd.c came along.

You had correctly pointed out "I happen not to have come across the
need for such ganged access from Linux" in the start of this thread. I
think that you raised a strong point there. If I understood you
correctly, it implies it is NOT likely that there'll be many users of
this ganged access API.

Which is precisely why I took your suggestion to heart and stuck to
the middle path. For better or worse, we currently have a grand total
of just one use case for this ganged API: am300epd.c which does a
16-bit write. No one has spoken up with another concrete use case. So
I say we stick to the simple 32-bit startpin/mask/length API. Lets see
if people start using it. If more than a few do and issues are raised
with it being limited to "just 32 bits", then we can rearchitecht as
needed. After all, as you requested, it's an optional in-kernel only
API so we're in no danger of shooting ourselves in the foot here.
Further more, we've gone from years of 1-bit access with no complaints
to 32-bit access. A factor of 32 improvement seems a reasonably good
bet for the next few years to me. :-)

If any of my assertions are mistaken, I'll need your help to
understand which specific part of the conversation I've misunderstood.

Thanks,
jaya