From: Grant Likely <grant.likely@secretlab.ca>
To: Linus Walleij <linus.walleij@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, gnurou@gmail.com,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc
Date: Sat, 09 Feb 2013 09:58:03 +0000 [thread overview]
Message-ID: <20130209095803.61C653E2CF2@localhost> (raw)
In-Reply-To: <1359822572-26009-10-git-send-email-acourbot@nvidia.com>
On Sun, 3 Feb 2013 01:29:31 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Parse the list of chips to find the descriptor corresponding to a GPIO
> number instead of directly picking the entry of the global gpio_desc[]
> array, which is due to be removed.
>
> This turns the complexity of converting a GPIO number into a descriptor
> from O(1) to O(n) where n is the number of GPIO chips in the system.
> Since n is ought to be small anyway, there should be no noticeable
> performance impact. Moreover, GPIO users who care for speed already have
> implemented their own gpio_get_value() and gpio_set_value() with a
> fast path for the GPIO numbers that matter and this change does not
> affect such use cases.
>
> The descriptor-based GPIO API, due to be introduced soon, will make this
> lookup unnecessary.
I'm actually going to NAK this one. This is a hot path. Having a O(1)
lookup from gpio number to gpio desc is important. I know you want to be
rid of the gpio_desc table entirely, but in this case I think it is
warranted. However, you can change the gpio_desc table to be a table of
pointers to gpio_descs instead of a table of gpio_descs. That would save
a lot of memory since unused GPIOs wouldn't have gpio_descs associated
with them. It is also the mechanism used by the IRQ subsystem.
So, it makes sense for the primary gpio_chip lookup to be the list, but
the table needs to stick around as a secondary lookup.
g.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 9599b9a..0247c48 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -122,10 +122,21 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
> */
> static struct gpio_desc *gpio_to_desc(unsigned gpio)
> {
> - if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
> - return NULL;
> - else
> - return &gpio_desc[gpio];
> + struct gpio_chip *chip;
> +
> + list_for_each_entry(chip, &gpio_chips, list) {
> + int gpio_min = chip->base;
> + int gpio_max = gpio_min + chip->ngpio;
> + if (gpio >= gpio_min && gpio < gpio_max)
> + return &chip->desc[gpio - gpio_min];
> + else if (gpio < gpio_min)
> + /* gpio_chips are ordered by base, so we won't get any
> + * hit if we arrive here... */
> + break;
> + }
> +
> + pr_warn("%s: no registered chip to handle GPIO %d\n", __func__, gpio);
> + return NULL;
> }
>
> /**
> --
> 1.8.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Alexandre Courbot <acourbot@nvidia.com>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, gnurou@gmail.com
Subject: Re: [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc
Date: Sat, 09 Feb 2013 09:58:03 +0000 [thread overview]
Message-ID: <20130209095803.61C653E2CF2@localhost> (raw)
Message-ID: <20130209095803.-eus5UTrh_DM25NRrUQyLB8kBrxZLbe4g8YHrYkHBBM@z> (raw)
In-Reply-To: <1359822572-26009-10-git-send-email-acourbot@nvidia.com>
On Sun, 3 Feb 2013 01:29:31 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Parse the list of chips to find the descriptor corresponding to a GPIO
> number instead of directly picking the entry of the global gpio_desc[]
> array, which is due to be removed.
>
> This turns the complexity of converting a GPIO number into a descriptor
> from O(1) to O(n) where n is the number of GPIO chips in the system.
> Since n is ought to be small anyway, there should be no noticeable
> performance impact. Moreover, GPIO users who care for speed already have
> implemented their own gpio_get_value() and gpio_set_value() with a
> fast path for the GPIO numbers that matter and this change does not
> affect such use cases.
>
> The descriptor-based GPIO API, due to be introduced soon, will make this
> lookup unnecessary.
I'm actually going to NAK this one. This is a hot path. Having a O(1)
lookup from gpio number to gpio desc is important. I know you want to be
rid of the gpio_desc table entirely, but in this case I think it is
warranted. However, you can change the gpio_desc table to be a table of
pointers to gpio_descs instead of a table of gpio_descs. That would save
a lot of memory since unused GPIOs wouldn't have gpio_descs associated
with them. It is also the mechanism used by the IRQ subsystem.
So, it makes sense for the primary gpio_chip lookup to be the list, but
the table needs to stick around as a secondary lookup.
g.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 9599b9a..0247c48 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -122,10 +122,21 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
> */
> static struct gpio_desc *gpio_to_desc(unsigned gpio)
> {
> - if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
> - return NULL;
> - else
> - return &gpio_desc[gpio];
> + struct gpio_chip *chip;
> +
> + list_for_each_entry(chip, &gpio_chips, list) {
> + int gpio_min = chip->base;
> + int gpio_max = gpio_min + chip->ngpio;
> + if (gpio >= gpio_min && gpio < gpio_max)
> + return &chip->desc[gpio - gpio_min];
> + else if (gpio < gpio_min)
> + /* gpio_chips are ordered by base, so we won't get any
> + * hit if we arrive here... */
> + break;
> + }
> +
> + pr_warn("%s: no registered chip to handle GPIO %d\n", __func__, gpio);
> + return NULL;
> }
>
> /**
> --
> 1.8.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc
Date: Sat, 09 Feb 2013 09:58:03 +0000 [thread overview]
Message-ID: <20130209095803.61C653E2CF2@localhost> (raw)
In-Reply-To: <1359822572-26009-10-git-send-email-acourbot@nvidia.com>
On Sun, 3 Feb 2013 01:29:31 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Parse the list of chips to find the descriptor corresponding to a GPIO
> number instead of directly picking the entry of the global gpio_desc[]
> array, which is due to be removed.
>
> This turns the complexity of converting a GPIO number into a descriptor
> from O(1) to O(n) where n is the number of GPIO chips in the system.
> Since n is ought to be small anyway, there should be no noticeable
> performance impact. Moreover, GPIO users who care for speed already have
> implemented their own gpio_get_value() and gpio_set_value() with a
> fast path for the GPIO numbers that matter and this change does not
> affect such use cases.
>
> The descriptor-based GPIO API, due to be introduced soon, will make this
> lookup unnecessary.
I'm actually going to NAK this one. This is a hot path. Having a O(1)
lookup from gpio number to gpio desc is important. I know you want to be
rid of the gpio_desc table entirely, but in this case I think it is
warranted. However, you can change the gpio_desc table to be a table of
pointers to gpio_descs instead of a table of gpio_descs. That would save
a lot of memory since unused GPIOs wouldn't have gpio_descs associated
with them. It is also the mechanism used by the IRQ subsystem.
So, it makes sense for the primary gpio_chip lookup to be the list, but
the table needs to stick around as a secondary lookup.
g.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 9599b9a..0247c48 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -122,10 +122,21 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
> */
> static struct gpio_desc *gpio_to_desc(unsigned gpio)
> {
> - if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
> - return NULL;
> - else
> - return &gpio_desc[gpio];
> + struct gpio_chip *chip;
> +
> + list_for_each_entry(chip, &gpio_chips, list) {
> + int gpio_min = chip->base;
> + int gpio_max = gpio_min + chip->ngpio;
> + if (gpio >= gpio_min && gpio < gpio_max)
> + return &chip->desc[gpio - gpio_min];
> + else if (gpio < gpio_min)
> + /* gpio_chips are ordered by base, so we won't get any
> + * hit if we arrive here... */
> + break;
> + }
> +
> + pr_warn("%s: no registered chip to handle GPIO %d\n", __func__, gpio);
> + return NULL;
> }
>
> /**
> --
> 1.8.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Alexandre Courbot <acourbot@nvidia.com>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, gnurou@gmail.com,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc
Date: Sat, 09 Feb 2013 09:58:03 +0000 [thread overview]
Message-ID: <20130209095803.61C653E2CF2@localhost> (raw)
In-Reply-To: <1359822572-26009-10-git-send-email-acourbot@nvidia.com>
On Sun, 3 Feb 2013 01:29:31 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Parse the list of chips to find the descriptor corresponding to a GPIO
> number instead of directly picking the entry of the global gpio_desc[]
> array, which is due to be removed.
>
> This turns the complexity of converting a GPIO number into a descriptor
> from O(1) to O(n) where n is the number of GPIO chips in the system.
> Since n is ought to be small anyway, there should be no noticeable
> performance impact. Moreover, GPIO users who care for speed already have
> implemented their own gpio_get_value() and gpio_set_value() with a
> fast path for the GPIO numbers that matter and this change does not
> affect such use cases.
>
> The descriptor-based GPIO API, due to be introduced soon, will make this
> lookup unnecessary.
I'm actually going to NAK this one. This is a hot path. Having a O(1)
lookup from gpio number to gpio desc is important. I know you want to be
rid of the gpio_desc table entirely, but in this case I think it is
warranted. However, you can change the gpio_desc table to be a table of
pointers to gpio_descs instead of a table of gpio_descs. That would save
a lot of memory since unused GPIOs wouldn't have gpio_descs associated
with them. It is also the mechanism used by the IRQ subsystem.
So, it makes sense for the primary gpio_chip lookup to be the list, but
the table needs to stick around as a secondary lookup.
g.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 9599b9a..0247c48 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -122,10 +122,21 @@ static int gpio_chip_hwgpio(const struct gpio_desc *desc)
> */
> static struct gpio_desc *gpio_to_desc(unsigned gpio)
> {
> - if (WARN(!gpio_is_valid(gpio), "invalid GPIO %d\n", gpio))
> - return NULL;
> - else
> - return &gpio_desc[gpio];
> + struct gpio_chip *chip;
> +
> + list_for_each_entry(chip, &gpio_chips, list) {
> + int gpio_min = chip->base;
> + int gpio_max = gpio_min + chip->ngpio;
> + if (gpio >= gpio_min && gpio < gpio_max)
> + return &chip->desc[gpio - gpio_min];
> + else if (gpio < gpio_min)
> + /* gpio_chips are ordered by base, so we won't get any
> + * hit if we arrive here... */
> + break;
> + }
> +
> + pr_warn("%s: no registered chip to handle GPIO %d\n", __func__, gpio);
> + return NULL;
> }
>
> /**
> --
> 1.8.1.1
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
next prev parent reply other threads:[~2013-02-09 9:58 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-02 16:29 [PATCH 0/9] gpiolib: remove gpio_desc[] static array Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 1/9] gpiolib: link all gpio_chips using a list Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:00 ` Linus Walleij
2013-02-05 17:00 ` Linus Walleij
2013-02-09 9:20 ` Grant Likely
2013-02-09 9:20 ` Grant Likely
2013-02-02 16:29 ` [PATCH 2/9] gpiolib: use gpio_chips list in gpiolib_sysfs_init Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:04 ` Linus Walleij
2013-02-05 17:04 ` Linus Walleij
2013-02-09 9:22 ` Grant Likely
2013-02-09 9:22 ` Grant Likely
2013-02-09 9:22 ` Grant Likely
2013-02-02 16:29 ` [PATCH 3/9] gpiolib: use gpio_chips list in gpiochip_find Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:05 ` Linus Walleij
2013-02-05 17:05 ` Linus Walleij
2013-02-09 9:25 ` Grant Likely
2013-02-09 9:25 ` Grant Likely
2013-02-09 9:25 ` Grant Likely
2013-02-02 16:29 ` [PATCH 4/9] gpiolib: use gpio_chips list in sysfs ops Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:15 ` Linus Walleij
2013-02-05 17:15 ` Linus Walleij
2013-02-09 9:37 ` Grant Likely
2013-02-09 9:37 ` Grant Likely
2013-02-09 9:37 ` Grant Likely
2013-02-09 13:53 ` Alexandre Courbot
2013-02-09 13:53 ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 5/9] gpiolib: use gpio_chips list in gpiochip_find_base Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:21 ` Linus Walleij
2013-02-05 17:21 ` Linus Walleij
2013-02-06 4:48 ` Alex Courbot
2013-02-06 4:48 ` Alex Courbot
2013-02-09 9:47 ` Grant Likely
2013-02-09 9:47 ` Grant Likely
2013-02-02 16:29 ` [PATCH 6/9] gpiolib: use descriptors internally Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 17:53 ` Linus Walleij
2013-02-05 17:53 ` Linus Walleij
2013-02-07 6:57 ` Alexandre Courbot
2013-02-07 6:57 ` Alexandre Courbot
2013-02-09 9:17 ` Grant Likely
2013-02-09 9:17 ` Grant Likely
2013-02-09 9:17 ` Grant Likely
2013-02-11 14:09 ` Linus Walleij
2013-02-11 14:09 ` Linus Walleij
2013-02-11 15:40 ` Paul Mundt
2013-02-11 15:40 ` Paul Mundt
2013-02-11 17:39 ` Stephen Warren
2013-02-11 17:39 ` Stephen Warren
2013-02-12 12:29 ` Linus Walleij
2013-02-12 12:29 ` Linus Walleij
2013-02-12 15:59 ` Paul Mundt
2013-02-12 15:59 ` Paul Mundt
2013-02-12 17:18 ` Arnd Bergmann
2013-02-12 17:18 ` Arnd Bergmann
2013-02-09 13:11 ` Grant Likely
2013-02-09 13:11 ` Grant Likely
2013-02-09 13:11 ` Grant Likely
2013-02-09 13:11 ` Grant Likely
2013-02-09 14:15 ` Alexandre Courbot
2013-02-09 14:15 ` Alexandre Courbot
2013-02-09 13:24 ` Grant Likely
2013-02-09 13:24 ` Grant Likely
2013-02-09 13:24 ` Grant Likely
2013-02-09 13:24 ` Grant Likely
2013-02-09 14:18 ` Alexandre Courbot
2013-02-09 14:18 ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 7/9] gpiolib: let gpio_chip reference its descriptors Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 18:00 ` Linus Walleij
2013-02-05 18:00 ` Linus Walleij
2013-02-09 13:28 ` Grant Likely
2013-02-09 13:28 ` Grant Likely
2013-02-02 16:29 ` [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 18:01 ` Linus Walleij
2013-02-05 18:01 ` Linus Walleij
2013-02-05 18:01 ` Linus Walleij
2013-02-09 9:58 ` Grant Likely [this message]
2013-02-09 9:58 ` Grant Likely
2013-02-09 9:58 ` Grant Likely
2013-02-09 9:58 ` Grant Likely
2013-02-09 14:21 ` Alexandre Courbot
2013-02-09 14:21 ` Alexandre Courbot
2013-02-09 14:37 ` Grant Likely
2013-02-09 14:37 ` Grant Likely
2013-02-02 16:29 ` [PATCH 9/9] gpiolib: dynamically allocate descriptors array Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-05 18:02 ` Linus Walleij
2013-02-05 18:02 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130209095803.61C653E2CF2@localhost \
--to=grant.likely@secretlab.ca \
--cc=acourbot@nvidia.com \
--cc=arnd@arndb.de \
--cc=gnurou@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.