linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm/tegra: add support for tegra30 interrupts
Date: Wed, 2 Nov 2011 21:48:28 +0200	[thread overview]
Message-ID: <20111102194827.GF14372@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <20111102193947.GD12913@n2100.arm.linux.org.uk>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111102/6b0e1ae1/attachment-0001.sig>

  reply	other threads:[~2011-11-02 19:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-02 15:38 [PATCH] arm/tegra: add support for tegra30 interrupts Peter De Schrijver
2011-11-02 16:39 ` Stephen Warren
2011-11-02 18:06   ` Stephen Warren
2011-11-02 19:09     ` Stephen Warren
2011-11-02 19:21       ` Russell King - ARM Linux
2011-11-02 19:26         ` Felipe Balbi
2011-11-02 19:39           ` Russell King - ARM Linux
2011-11-02 19:48             ` Felipe Balbi [this message]
2011-11-02 19:54               ` Russell King - ARM Linux
2011-11-02 20:40                 ` Felipe Balbi
2011-11-02 18:13 ` Colin Cross

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=20111102194827.GF14372@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).