From: Grant Likely <grant.likely@secretlab.ca>
To: Linus Walleij <linus.walleij@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, gnurou@gmail.com,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [RFC] gpiolib: introduce descriptor-based GPIO interface
Date: Thu, 06 Dec 2012 14:42:59 +0000 [thread overview]
Message-ID: <20121206144259.136693E0950@localhost> (raw)
In-Reply-To: <1354779918-4028-2-git-send-email-acourbot@nvidia.com>
On Thu, 6 Dec 2012 16:45:18 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GPIOs for a given system is fixed at system time, and a
> large array of that size is statically allocated to hold the GPIO
> descriptors. Worse, GPIOs can be used without being properly allocated.
>
> In order to improve the situation, the integer namespace must first get
> away. This patch introduces an alternative GPIO API that uses opaque
> handlers and refactor gpiolib's internals to work with these handlers
> instead of GPIO numbers. The former integer-based API is still available
> as a light wrapper around this new API.
>
> This first step will then us to build more improvements for gpiolib,
> like proper GPIO lookup functions per device and provider, and getting
> rid of the static GPIO array and the ARCH_NR_GPIO configuration option.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 302 ++++++++++++++++++++++--------------------
> include/asm-generic/gpio.h | 74 ++++++++---
> include/linux/gpio/consumer.h | 45 +++++++
> 3 files changed, 261 insertions(+), 160 deletions(-)
> create mode 100644 include/linux/gpio/consumer.h
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 1c8d9e3..bf32511 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -83,6 +83,32 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label)
> #endif
> }
>
> +/**
> + * Convert a GPIO descriptor to the integer namespace.
> + * This should disappear in the future but is needed since we still
> + * use GPIO numbers for error messages and sysfs nodes
> + */
> +static inline int desc_to_gpio(struct gpio_desc *desc)
> +{
> + return desc - &gpio_desc[0];
> +}
> +
> +/**
> + * Return the GPIO number of the passed descriptor relative to its chip
> + */
> +int gpio_chip_offset(struct gpio_desc *desc)
> +{
> + return (desc - &gpio_desc[0]) - desc->chip->base;
> +}
how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
I've only lightly scanned this patch, but I like what I see. I would
keep going with it.
g.
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-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, gnurou@gmail.com
Subject: Re: [RFC] gpiolib: introduce descriptor-based GPIO interface
Date: Thu, 06 Dec 2012 14:42:59 +0000 [thread overview]
Message-ID: <20121206144259.136693E0950@localhost> (raw)
Message-ID: <20121206144259.wNCkEVRt6_-S8L3gmVcShih0Vs9TF58vPsh8-owOKDI@z> (raw)
In-Reply-To: <1354779918-4028-2-git-send-email-acourbot@nvidia.com>
On Thu, 6 Dec 2012 16:45:18 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GPIOs for a given system is fixed at system time, and a
> large array of that size is statically allocated to hold the GPIO
> descriptors. Worse, GPIOs can be used without being properly allocated.
>
> In order to improve the situation, the integer namespace must first get
> away. This patch introduces an alternative GPIO API that uses opaque
> handlers and refactor gpiolib's internals to work with these handlers
> instead of GPIO numbers. The former integer-based API is still available
> as a light wrapper around this new API.
>
> This first step will then us to build more improvements for gpiolib,
> like proper GPIO lookup functions per device and provider, and getting
> rid of the static GPIO array and the ARCH_NR_GPIO configuration option.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 302 ++++++++++++++++++++++--------------------
> include/asm-generic/gpio.h | 74 ++++++++---
> include/linux/gpio/consumer.h | 45 +++++++
> 3 files changed, 261 insertions(+), 160 deletions(-)
> create mode 100644 include/linux/gpio/consumer.h
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 1c8d9e3..bf32511 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -83,6 +83,32 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label)
> #endif
> }
>
> +/**
> + * Convert a GPIO descriptor to the integer namespace.
> + * This should disappear in the future but is needed since we still
> + * use GPIO numbers for error messages and sysfs nodes
> + */
> +static inline int desc_to_gpio(struct gpio_desc *desc)
> +{
> + return desc - &gpio_desc[0];
> +}
> +
> +/**
> + * Return the GPIO number of the passed descriptor relative to its chip
> + */
> +int gpio_chip_offset(struct gpio_desc *desc)
> +{
> + return (desc - &gpio_desc[0]) - desc->chip->base;
> +}
how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
I've only lightly scanned this patch, but I like what I see. I would
keep going with it.
g.
WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] gpiolib: introduce descriptor-based GPIO interface
Date: Thu, 06 Dec 2012 14:42:59 +0000 [thread overview]
Message-ID: <20121206144259.136693E0950@localhost> (raw)
In-Reply-To: <1354779918-4028-2-git-send-email-acourbot@nvidia.com>
On Thu, 6 Dec 2012 16:45:18 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GPIOs for a given system is fixed at system time, and a
> large array of that size is statically allocated to hold the GPIO
> descriptors. Worse, GPIOs can be used without being properly allocated.
>
> In order to improve the situation, the integer namespace must first get
> away. This patch introduces an alternative GPIO API that uses opaque
> handlers and refactor gpiolib's internals to work with these handlers
> instead of GPIO numbers. The former integer-based API is still available
> as a light wrapper around this new API.
>
> This first step will then us to build more improvements for gpiolib,
> like proper GPIO lookup functions per device and provider, and getting
> rid of the static GPIO array and the ARCH_NR_GPIO configuration option.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 302 ++++++++++++++++++++++--------------------
> include/asm-generic/gpio.h | 74 ++++++++---
> include/linux/gpio/consumer.h | 45 +++++++
> 3 files changed, 261 insertions(+), 160 deletions(-)
> create mode 100644 include/linux/gpio/consumer.h
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 1c8d9e3..bf32511 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -83,6 +83,32 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label)
> #endif
> }
>
> +/**
> + * Convert a GPIO descriptor to the integer namespace.
> + * This should disappear in the future but is needed since we still
> + * use GPIO numbers for error messages and sysfs nodes
> + */
> +static inline int desc_to_gpio(struct gpio_desc *desc)
> +{
> + return desc - &gpio_desc[0];
> +}
> +
> +/**
> + * Return the GPIO number of the passed descriptor relative to its chip
> + */
> +int gpio_chip_offset(struct gpio_desc *desc)
> +{
> + return (desc - &gpio_desc[0]) - desc->chip->base;
> +}
how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
I've only lightly scanned this patch, but I like what I see. I would
keep going with it.
g.
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-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, gnurou@gmail.com,
Alexandre Courbot <acourbot@nvidia.com>
Subject: Re: [RFC] gpiolib: introduce descriptor-based GPIO interface
Date: Thu, 06 Dec 2012 14:42:59 +0000 [thread overview]
Message-ID: <20121206144259.136693E0950@localhost> (raw)
In-Reply-To: <1354779918-4028-2-git-send-email-acourbot@nvidia.com>
On Thu, 6 Dec 2012 16:45:18 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GPIOs for a given system is fixed at system time, and a
> large array of that size is statically allocated to hold the GPIO
> descriptors. Worse, GPIOs can be used without being properly allocated.
>
> In order to improve the situation, the integer namespace must first get
> away. This patch introduces an alternative GPIO API that uses opaque
> handlers and refactor gpiolib's internals to work with these handlers
> instead of GPIO numbers. The former integer-based API is still available
> as a light wrapper around this new API.
>
> This first step will then us to build more improvements for gpiolib,
> like proper GPIO lookup functions per device and provider, and getting
> rid of the static GPIO array and the ARCH_NR_GPIO configuration option.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpio/gpiolib.c | 302 ++++++++++++++++++++++--------------------
> include/asm-generic/gpio.h | 74 ++++++++---
> include/linux/gpio/consumer.h | 45 +++++++
> 3 files changed, 261 insertions(+), 160 deletions(-)
> create mode 100644 include/linux/gpio/consumer.h
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 1c8d9e3..bf32511 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -83,6 +83,32 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label)
> #endif
> }
>
> +/**
> + * Convert a GPIO descriptor to the integer namespace.
> + * This should disappear in the future but is needed since we still
> + * use GPIO numbers for error messages and sysfs nodes
> + */
> +static inline int desc_to_gpio(struct gpio_desc *desc)
> +{
> + return desc - &gpio_desc[0];
> +}
> +
> +/**
> + * Return the GPIO number of the passed descriptor relative to its chip
> + */
> +int gpio_chip_offset(struct gpio_desc *desc)
> +{
> + return (desc - &gpio_desc[0]) - desc->chip->base;
> +}
how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
I've only lightly scanned this patch, but I like what I see. I would
keep going with it.
g.
next prev parent reply other threads:[~2012-12-06 14:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-06 7:45 [RFC] gpiolib: introduce descriptor-based GPIO interface Alexandre Courbot
2012-12-06 7:45 ` Alexandre Courbot
2012-12-06 7:45 ` Alexandre Courbot
2012-12-06 7:45 ` Alexandre Courbot
2012-12-06 7:45 ` Alexandre Courbot
2012-12-06 7:45 ` Alexandre Courbot
2012-12-06 14:42 ` Grant Likely [this message]
2012-12-06 14:42 ` Grant Likely
2012-12-06 14:42 ` Grant Likely
2012-12-06 14:42 ` Grant Likely
2012-12-07 2:06 ` Alex Courbot
2012-12-07 2:06 ` Alex Courbot
2012-12-07 8:24 ` Linus Walleij
2012-12-07 8:24 ` Linus Walleij
2012-12-10 22:34 ` Grant Likely
2012-12-10 22:34 ` Grant Likely
2012-12-06 20:19 ` Linus Walleij
2012-12-06 20:19 ` Linus Walleij
2012-12-07 2:49 ` Guenter Roeck
2012-12-07 2:49 ` Guenter Roeck
2012-12-07 7:02 ` Alex Courbot
2012-12-07 7:02 ` Alex Courbot
2012-12-07 15:07 ` Guenter Roeck
2012-12-07 15:07 ` Guenter Roeck
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=20121206144259.136693E0950@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.