Re: [PATCH 1/2] x86, gpio: Increase ARCH_NR_GPIOs to 512

From: Alexandre Courbot
Date: Fri Sep 19 2014 - 03:20:49 EST


I should have responded to that thread long ago, but I am currently on
holidays and strangely tend to check my mail less often than I should.
:P

On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> Argh! This is the kind of stuff I want to get rid of ....
>
> Preferably gpio should be a subsystem without a lot of hooks all over
> the place with arch-specific modifications for this and that, including
> the max number of GPIOs.
>
> I would actually prefer if you bump the value in
> include/asm-generic/gpio.h to 512 over this.
>
> But better still, now that we have descriptors etc would be to define
> some new per-arch selectable config option like
> CONFIG_ONLY_DYNAMIC_GPIO that changes the GPIO
> core to use something like a radix tree to store and retrieve
> descriptors.
>
> I.e. in drivers/gpio/gpiolib.c get rid of this:
> static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
>
> Replace it with a radix tree of descriptors.
>
> This however makes it *impossible* to use things like desc_to_gpio()
> and/or gpio_to_desc() so the code has to be augmented all over the
> place to avoid any uses of GPIO numbers on that architecture,
> but I am sure it *can* be done on pure ACPI or device tree
> systems, and that's what we should aim for.

desc_to_gpio()/gpio_to_desc() could still work even if we remove the
big array of GPIO descriptors. Actually that's what I intended to do
when I first submitted the gpiod patches some time ago but it was
rejected for performance reasons.

desc_to_gpio() actually doesn't even access this array - it does its
job using the chip base and the beginning address of its descriptors
array.

gpio_to_desc() would suffer a performance hit. What I initially
proposed was to parse the linked list of GPIO chips and check if the
requested number is in their assigned range. This is obviously slower
than accessing an array, but if we consider that we generally don't
have too many GPIO chips on a given hardware I don't think the hit
would be that bad. It would also give some incentive for people to
move to the gpiod interface.

I also have a patch in my queue that enables multiple users on the
same GPIO descriptor (something requested since some time already).
What happens with it is that descriptors ownership is fully
transferred to the gpio_chip instances, and the static array becomes a
array of double-pointers, making it considerable smaller and reducing
the impact of increasing its size. Maybe I should submit that change
just for this case?
--
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/