| Message ID | 1343219864-3040-1-git-send-email-dirk.behme@de.bosch.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jul 25, 2012 at 9:37 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote: > From: Matthias Thomae <matthias.thomae@de.bosch.com> > > Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO > controllers with 32 signals each. The default of 256 GPIOs wastes > some static table space as explained in Documentation/gpio.txt. > > Signed-off-by: Matthias Thomae <matthias.thomae@de.bosch.com> Looks like a typo in the subject. It should be 224, right?
On 25.07.2012 16:12, Fabio Estevam wrote: > On Wed, Jul 25, 2012 at 9:37 AM, Dirk Behme<dirk.behme@de.bosch.com> wrote: >> From: Matthias Thomae<matthias.thomae@de.bosch.com> >> >> Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO >> controllers with 32 signals each. The default of 256 GPIOs wastes >> some static table space as explained in Documentation/gpio.txt. >> >> Signed-off-by: Matthias Thomae<matthias.thomae@de.bosch.com> > > Looks like a typo in the subject. It should be 224, right? Yes. Any further comments to be fixed in v2? Best regards Dirk
On Wed, Jul 25, 2012 at 02:37:43PM +0200, Dirk Behme wrote: > From: Matthias Thomae <matthias.thomae@de.bosch.com> > > Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO > controllers with 32 signals each. The default of 256 GPIOs wastes > some static table space as explained in Documentation/gpio.txt. > > Signed-off-by: Matthias Thomae <matthias.thomae@de.bosch.com> > CC: Shawn Guo <shawn.guo@linaro.org> > --- > arch/arm/Kconfig | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index b25c9d3..5e4cde3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1626,6 +1626,7 @@ config ARCH_NR_GPIO > default 355 if ARCH_U8500 > default 264 if MACH_H4700 > default 512 if SOC_OMAP5 > + default 224 if SOC_IMX6Q So what if we build imx_v6_v7_defconfig with IMX6Q deselected?
On 28.07.2012 15:32, Shawn Guo wrote: > On Wed, Jul 25, 2012 at 02:37:43PM +0200, Dirk Behme wrote: >> From: Matthias Thomae<matthias.thomae@de.bosch.com> >> >> Set ARCH_NR_GPIO for the i.MX6 processor family, which has 7 GPIO >> controllers with 32 signals each. The default of 256 GPIOs wastes >> some static table space as explained in Documentation/gpio.txt. >> >> Signed-off-by: Matthias Thomae<matthias.thomae@de.bosch.com> >> CC: Shawn Guo<shawn.guo@linaro.org> >> --- >> arch/arm/Kconfig | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index b25c9d3..5e4cde3 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1626,6 +1626,7 @@ config ARCH_NR_GPIO >> default 355 if ARCH_U8500 >> default 264 if MACH_H4700 >> default 512 if SOC_OMAP5 >> + default 224 if SOC_IMX6Q > > So what if we build imx_v6_v7_defconfig with IMX6Q deselected? Hmm, sorry if I missed anything, but how is adding a 'default .. SOC_IMX6Q' related to any defconfig? If you want to deselect SOC_IMX6Q using the way you like you'll get the standard 256 (if I remember correctly). Best regards Dirk
On Sun, Jul 29, 2012 at 06:18:21PM +0200, Dirk Behme wrote: > Hmm, sorry if I missed anything, but how is adding a 'default .. > SOC_IMX6Q' related to any defconfig? If you want to deselect > SOC_IMX6Q using the way you like you'll get the standard 256 (if I > remember correctly). > I'm essentially questioning about the point of the patch. It intends to save a little space for imx6q build without caring about imx3 and imx5. That said, when imx6q is excluded from the build, we are still wasting those space. That's why I'm not so excited about the patch. Looking at current users of this definition, you will find all of them are defining a number bigger than 256 for extending the maximum number. It might be a sign that having a gpio array which is a little bigger than necessary is not a concern on machines today.
On 30.07.2012 03:14, Shawn Guo wrote: > On Sun, Jul 29, 2012 at 06:18:21PM +0200, Dirk Behme wrote: >> Hmm, sorry if I missed anything, but how is adding a 'default .. >> SOC_IMX6Q' related to any defconfig? If you want to deselect >> SOC_IMX6Q using the way you like you'll get the standard 256 (if I >> remember correctly). >> > I'm essentially questioning about the point of the patch. It intends > to save a little space for imx6q build without caring about imx3 and > imx5. That said, when imx6q is excluded from the build, we are still > wasting those space. It's my understanding that the ARCH_NR_GPIO Kconfig was introduced recently for optimization/conversion/cleanup reasons. So from my point of view it's in a first step better to use it for iMX6 than ignoring this optimization/conversion/cleanup. But yes, it's even better to enable it for imx3/imx5, too. As I don't know these platforms, two questions: - Do you like to propose a better macro than SOC_IMX6Q to cover imx3/imx6, too? - Do imx3 and imx5 have the same GPIO number like imx6? I.e. 7 banks with 32 pins == 224 GPIOs? > Looking at current users of this definition, you will find all of them > are defining a number bigger than 256 for extending the maximum number. > It might be a sign that having a gpio array which is a little bigger > than necessary is not a concern on machines today. Or it might be a sign that they *have* more than 256? I don't know. But what's the issue using a matching number if possible? Best regards Dirk
On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote: > - Do you like to propose a better macro than SOC_IMX6Q to cover > imx3/imx6, too? > No, I do not see the need of this. CONFIG_ARCH_NR_GPIO is not the only way to overwrite the default number. We can define ARCH_NR_GPIOS to the number we want in IMX platform headers. > - Do imx3 and imx5 have the same GPIO number like imx6? I.e. 7 banks > with 32 pins == 224 GPIOs? > imx31, imx35: 3 banks imx51: 4 banks imx53: 7 banks > >Looking at current users of this definition, you will find all of them > >are defining a number bigger than 256 for extending the maximum number. > >It might be a sign that having a gpio array which is a little bigger > >than necessary is not a concern on machines today. > > Or it might be a sign that they *have* more than 256? I don't know. Yes. I was actually saying that there is no platforms defining the Kconfig symbol smaller than 256 to save the space. > But what's the issue using a matching number if possible? > At least for IMX, it does not help that much.
On 30.07.2012 10:46, Shawn Guo wrote: > On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote: >> - Do you like to propose a better macro than SOC_IMX6Q to cover >> imx3/imx6, too? >> > No, I do not see the need of this. CONFIG_ARCH_NR_GPIO is not the only > way to overwrite the default number. We can define ARCH_NR_GPIOS to > the number we want in IMX platform headers. I understood http://lkml.indiana.edu/hypermail/linux/kernel/1111.0/01565.html that the goal is to not use the headers any more. But I might have misunderstood that ... >> - Do imx3 and imx5 have the same GPIO number like imx6? I.e. 7 banks >> with 32 pins == 224 GPIOs? >> > imx31, imx35: 3 banks > imx51: 4 banks > imx53: 7 banks Sounds like 7 is a good max number then, thanks! >>> Looking at current users of this definition, you will find all of them >>> are defining a number bigger than 256 for extending the maximum number. >>> It might be a sign that having a gpio array which is a little bigger >>> than necessary is not a concern on machines today. >> Or it might be a sign that they *have* more than 256? I don't know. > > Yes. I was actually saying that there is no platforms defining the > Kconfig symbol smaller than 256 to save the space. Hmm, maybe they just have all more than 256 and we are the first with less? Anyway, I'm not sure why smaller/bigger should be important here. I would feel that the goal should be to configure the correct number if possible, independent of smaller/bigger. Best regards Dirk
On Mon, Jul 30, 2012 at 04:46:07PM +0800, Shawn Guo wrote: > On Mon, Jul 30, 2012 at 08:40:58AM +0200, Dirk Behme wrote: > > - Do you like to propose a better macro than SOC_IMX6Q to cover > > imx3/imx6, too? > > > No, I do not see the need of this. CONFIG_ARCH_NR_GPIO is not the only > way to overwrite the default number. We can define ARCH_NR_GPIOS to > the number we want in IMX platform headers. Don't do that. CONFIG_ARCH_NR_GPIO is there so that we can consolidate out as much crap from mach/gpio.h as possible. Either use it now, or I will patch you to make you use it. Either way, you will end up using it... :)
On Mon, Jul 30, 2012 at 03:29:08PM +0100, Russell King - ARM Linux wrote: > Don't do that. CONFIG_ARCH_NR_GPIO is there so that we can consolidate > out as much crap from mach/gpio.h as possible. Either use it now, or I > will patch you to make you use it. Either way, you will end up using > it... :) Right. I was wrong on that. But I still maintain my position that there is no much point to define CONFIG_ARCH_NR_GPIO as 224 for space saving. I would rather not use it for IMX until we have an IMX SoC implementing more than 256 gpio.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b25c9d3..5e4cde3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1626,6 +1626,7 @@ config ARCH_NR_GPIO default 355 if ARCH_U8500 default 264 if MACH_H4700 default 512 if SOC_OMAP5 + default 224 if SOC_IMX6Q default 0 help Maximum number of GPIOs in the system.