On Sat, Sep 20, 2014 at 2:48 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Fri, Sep 19, 2014 at 12:20 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: >> On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >>> 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. > > OK. I'm ready to revisit the subject. > >> 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. > > Right. > >> 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 think the performance hit is acceptable, because this should > not be on a hot path anyway. I would say go ahead with this refactoring. Great! I will come with something once my holidays are over. It should not be a complex change. > >> 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? > > Ummmmm I think that is an orthogonal thing, but honestly I'm > not following the double-pointers thing, so I guess I need to see > the patch. Yes, this is completely orthogonal, and actually this won't be needed if we decide to get rid of that array. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html