linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Courbot <acourbot@nvidia.com>
To: Steven King <sfking@fdwdc.com>
Cc: Greg Ungerer <gerg@uclinux.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Guenter Roeck <linux@roeck-us.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	gnurou@gmail.com
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface
Date: Sun, 20 Jan 2013 15:07:02 +0900	[thread overview]
Message-ID: <50FB8986.9010205@nvidia.com> (raw)
In-Reply-To: <201301170850.43655.sfking@fdwdc.com>

Hi Steven,

On 01/18/2013 01:50 AM, Steven King wrote:
> Well, my concern is the small, single chip platforms with limited ram and
> speeds measured in MHz.  My goal was that these platforms that had very basic
> gpio needs, no offboard gpio, just toggling a few pins for spi or whatever,
> could do that without pulling in a bunch of code they dont need.  I realize
> that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its
> no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and
> even more constraining, 2 megs of flash) need all the help they can get.

Running readelf on gpiolib.o built for Tegra, here are the footprints:

.text: 9412B
.data: 260B
.bss: 12312B
.rodata: 268B

Total: 22252B or 22KB.

... of which more than half is the BSS section which consists of a 
static array of 1024 GPIO descriptors, an arbitrary number that you can 
tune and is way too large even for Tegra (but we have to use these 
gigabytes somehow). Say you only need to use 256 GPIOs and .bss is down 
to ~3KB, for a total overhead of 15kB or 0.09% of your 16MB which, in 
perspective, suddenly seem gigantic. :)

If you are concerned about the additional indirection that GPIOlib 
introduces and the potential slowdown for bitbanging, you can always 
define custom gpio_set_value() and gpio_get_value() macros to shortcut 
GPIOlib when the GPIO is in the range you want performance for.

> I haven't been keeping up with the kernel list of late, can someone point me
> to what''s being discussed so I can see what were talking about here?

Arnd explained it already, but basically we'd like to consolidate the 
GPIO subsystem around GPIOlib and introduce safer interfaces (while 
preserving backward compatibility). Good progress in that direction 
would be achieved if all users of the GENERIC_GPIO interface relied on 
GPIOlib (making GENERIC_GPIO require GPIOLIB).

Actually the question of switching to GPIOlib is only worth being asked 
if you are making use of drivers that require GENERIC_GPIO. If this is 
not the case and your GPIOs are only used by your own platform code, you 
can always give up using defining GENERIC_GPIO and continue implementing 
them your own way.

Thanks,
Alex.

  parent reply	other threads:[~2013-01-20  6:05 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08  7:18 [PATCH 0/4] gpio: introduce descriptor-based interface Alexandre Courbot
2013-01-08  7:18 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 12:59   ` Arnd Bergmann
2013-01-09  1:06     ` Alexandre Courbot
2013-01-09 10:25       ` Russell King - ARM Linux
2013-01-09 10:35       ` Arnd Bergmann
2013-01-09 10:44         ` Russell King - ARM Linux
2013-01-09 11:10           ` Russell King - ARM Linux
     [not found]             ` <20130109111055.GG3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 11:52               ` Arnd Bergmann
2013-01-09 11:52                 ` Arnd Bergmann
2013-01-09 14:44             ` Nicolas Pitre
2013-01-09 15:04               ` [PATCH] Proposed removal of IS_ERR_OR_NULL() (was: Re: [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface) Russell King - ARM Linux
     [not found]                 ` <20130109150427.GL3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 15:21                   ` Grant Likely
2013-01-09 15:21                     ` Grant Likely
2013-01-09 15:26                     ` Arnd Bergmann
2013-01-09 15:27                 ` Nicolas Pitre
2013-01-09 15:27                   ` Nicolas Pitre
2013-01-09 15:51                   ` Russell King - ARM Linux
2013-01-09 16:09                     ` Nicolas Pitre
2013-01-09 16:21                       ` Russell King - ARM Linux
2013-01-09 17:12                         ` Russell King - ARM Linux
2013-01-09 17:52                           ` Tony Lindgren
2013-01-17 10:28                 ` Linus Walleij
2013-01-10  8:36             ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Thierry Reding
2013-01-10  8:36               ` Thierry Reding
2013-01-08  7:18 ` [PATCH 2/4] gpiolib: add gpiod_get and gpiod_put functions Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 13:07   ` Arnd Bergmann
2013-01-09  1:49     ` Alexandre Courbot
2013-01-08  7:18 ` [PATCH 3/4] gpiolib: of: convert OF helpers to descriptor API Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18 ` [PATCH 4/4] gpiolib: add documentation for new gpiod_ API Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 13:06 ` [PATCH 0/4] gpio: introduce descriptor-based interface Arnd Bergmann
2013-01-08 13:06   ` Arnd Bergmann
2013-01-09  1:48   ` Alexandre Courbot
2013-01-09 10:46     ` Arnd Bergmann
2013-01-10  4:07       ` Alex Courbot
2013-01-10 10:08         ` Arnd Bergmann
2013-01-14 10:21           ` Alex Courbot
2013-01-14 10:46             ` Arnd Bergmann
2013-01-14 10:46               ` Arnd Bergmann
2013-01-17 11:15           ` Linus Walleij
2013-01-17 11:15             ` Linus Walleij
2013-01-17 12:02             ` Greg Ungerer
2013-01-17 16:50               ` Steven King
2013-01-17 16:50                 ` Steven King
2013-01-17 19:22                 ` Arnd Bergmann
2013-01-20  6:07                 ` Alex Courbot [this message]
2013-01-22  8:55                   ` Linus Walleij
2013-01-22  8:55                     ` Linus Walleij
2013-01-17 11:25           ` 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=50FB8986.9010205@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=geert@linux-m68k.org \
    --cc=gerg@uclinux.org \
    --cc=gnurou@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=sfking@fdwdc.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).