Re: How about a gpio_get(device *, char *) function?

[Linus Walleij]

On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot <acourbot@xxxxxxxxxx> wrote:

> Interesting. I see you already gave the whole thing a thought. What I don't
> understand however is what is so wrong with the current GPIO numberspace that
> you want to replace it? Whether we use simple integers or blind pointers, the
> adressable space will basically remain the same. GPIO numbers can actually be
> considered as handles, and actually I would not mind typedef'ing "int" to a
> GPIO handle type in order to add more opacity to the framework.

So the basic problem is scalability and multiplatform support.

Currently we have a global "roof" on GPIO numbers, ARCH_NR_GPIOS,
which is helpfully set to 256 in include/asm-generic/gpio.h.

In the embedded case "ARCH" is a particular board for a particular
SoC so this number is actually roof:ed for some arbitrary combination
of SoC + electronics, at compile time, for that very machine.

So what happens when we try to achieve multiplatform support in the
ARM tree (same for others, I expect ACPI etc to run into the same
problem) is that this has to be set to some arbitrarily high value so
that all GPIOs will fit, and they are not sparse, so if you're just using
GPIOs 0 .. 15 and 199935..200000 you will need to reserve
200000 * sizeof(int) bytes.

So to avoid this, arch maintainers try with different clever
macros to pack the GPIO number assignments per board
downward to begin at 0 and keep the array at minimum size,
and do not dynamically grab GPIO numbers as they like.

Contrast this to IRQs which are in the CONFIG_SPARSE_IRQ
case stored in a radix tree and IRQs can be sparse like this
without wasting much memory. So IRQdomains can for example
just grab a number of free IRQ descriptors and the actual
numbers returned do not matter.

Using static number assignments also has the side effect
that developers will just int mygpio = 42; directly in the code
to cut corners and invites such laziness instead of allocating
and propagating resources. With abstract handles this does
not happen.

So moving forward we need a dynamic, radix tree of sparse GPIOs,
and we need to follow the design pattern of IRQ descriptors to
keep the kernel consistent, for example pinctrl does this with
pins - these are sparse and dynamically allocated. They do not
have integer numbers other than locally for a particular pin
controller.

> Also the current DT bindings will likely continue to require the legacy API
> anyway, so I am not sure we can make it go away.

We can make any DT business go away as long as all DTS
files are maintained in the kernel and especially if their
structure is not future-proof. The "DT contract" to make
bindings stable and everlasting is being broken every day
as things are right now.

Not that I know the DT stuff by
heart, but if the way we're doing GPIO in DT is requiring the
OS to use a certain type of static array implementation it must
be wrong since DT is supposed to be OS-neutral.

> My initial thought was to build something on top of the existing scheme to
> address my immediate needs - what you are talking about is much more scary. :)
> Could you elaborate on your motivations for such a radical direction?

See above.

I suspect Grant have similar thoughts, but let's see...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/