[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111102194827.GF14372@legolas.emea.dhcp.ti.com>
Date: Wed, 2 Nov 2011 21:48:28 +0200
From: Felipe Balbi <balbi@...com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Felipe Balbi <balbi@...com>, Nicolas Pitre <nico@...xnic.net>,
Stephen Warren <swarren@...dia.com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Colin Cross <ccross@...roid.com>,
Olof Johansson <olof@...om.net>, Gary King <gking@...dia.com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm/tegra: add support for tegra30 interrupts
Hi,
On Wed, Nov 02, 2011 at 07:39:47PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2011 at 09:26:26PM +0200, Felipe Balbi wrote:
> > would it be better to just change the default value in
> > arm-generic/gpio.h to something very large ?
> >
> > I mean, ideally that wouldn't be gpio_desc wouldn't be an array anyway
> > right ?
>
> You'll excuse me if I take this slightly personally.
>
> You really can't expect me to say that I'm fine with a 6K growth in
> kernel size for something that not every platform needs if there's
> been objections to maybe a 128 byte growth for including the V:P
> patching code in the kernel by default.
>
> Either we care about memory usage or we don't. If we don't, lets get
> rid of offering ARM_PATCH_PHYS_VIRT in any configuration and always
> build with the dynamic V:P stuff enabled for the trivial cases. I
> mean:
>
> config ARM_PATCH_PHYS_VIRT
> - bool "Patch physical to virtual translations at runtime" if EMBEDDED
> + bool
> default y
> depends on !XIP_KERNEL && MMU
> depends on !ARCH_REALVIEW || !SPARSEMEM
you forgot to comment on the fact that gpio_desc shouldn't be held in an
array. Any comments ?
What I mean is that, just like irq_descs, we should be able to allocate
them dynamically. Maybe, just like irq_descs, hold them in a radix tree
and maybe even have a matching API "gpio_alloc_descs()".
It's a pain, anyway, to keep track of GPIO base numbers, specially on
complex boards where you have gpio controllers which are internal to the
SoC and several others connected via e.g. I2C.
Most PHY chips for several I/O have some extra GPIOs which are generally
unused or hacked around (see tusb6010.c for example).
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists