Message-Id: <200611131200.02032.david-b@pacbell.net>
Date:	Mon, 13 Nov 2006 12:00:01 -0800
From:	David Brownell <david-b@...bell.net>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Bill Gatliff <bgat@...lgatliff.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Monday 13 November 2006 10:38 am, Paul Mundt wrote:
> On Mon, Nov 13, 2006 at 12:19:11PM -0600, Bill Gatliff wrote:
> > True, but right now if the "multiple GPIO controllers" are on something 
> > like i2c/spi, they have the synch/asynch issues that Jamey mentioned and 
> > so are by definition out of scope for this proposal.  If the GPIO lines 
> > are in an MMIO controller (PLD/FPGA, perhaps), then there's no reason 
> > that the board implementer couldn't address that in their implementation 
> > of the proposed functions.
> > 
> They're something that has to be accounted for in any sort of API, or we
> just end up throwing it all out and starting over again. I was thinking
> more of the SuperIO or mfd device scope, where this _is_ a requirement.

Could you elaborate on these SuperIO and MFD thingies?  Especially with
reference to my point that multiple controllers *are* allowed, and that
this is just a platform-specific issue?  (As shown by the fact that the
API works fine with OMAP1, accessing both GPIO and MPUIO controllers
through those API calls ...)


> > ... except that I bet David is thinking that the implementations will be 
> > in arch/arm/irq-at91rm9200.c or something, and not in 
> > asm/arm/board-xyz.c, so it's the arch implementer's responsibility and 
> > not the platform author's.  Yea, I see your point now.
>
> The problem with this is that it gets in to something that's getting
> close to static pin state configuration.

I really don't see this at all (see previous email).


>	 Setting up the mux

... pin mux is 100% out of scope for managing/using GPIOs, since pin mux kicks
in for pins that aren't even GPIO-capable ...


>	 from platform code is brain-damage,

On the contrary, keeping board-specific pin configuration code out of otherwise
generic/portable device drivers is a Very Good Thing.  And that primarily means
moving that code into platform/board specific setup code.  (Today's Linux doesn't
have other places to put such code, especially if you don't want to demand much
from typically-sluggish boot loader teams.)


>	 since it's ultimately up to the system and driver 
> inserted at the time to grab and configure the pin as necessary, the
> board or CPU code is not going to have any notion of the "preferred" pin
> state, especially in the heavily muxed case.

I don't see this either.

In the primary "production board" use case, there is absolutely a "preferred"
pin mux config state:  each pin is connected to one peripheral in one way.
And typically its configuration is never changed; if it is, that's something
the pin mux API would need to handle.  (One example:  using a UART's RXD
pin as a wakeup GPIO while the system sleeps.  Presumably there are others.)

The only situation where there might not be a "preferred" mode is very much
a secondary use case:  the "development board", used to hook up many different
kinds of peripheral hardware.  Even in those cases, it makes perfect sense
for Kconfig options to define the _current_ "preferred" mode -- these pins
get muxed for the peripheral that's actually connected today, rather than the
one that we developed two months ago.  Because those drivers being developed
are going to be used with a "production board", where costs incurred for
dynamic configuration are undesirable...


> > I say that we go with David's proposal for 2.6.19 anyway, and maybe by 
> > 2.6.20 we'll have a consensus on how to address that with some 
> > behind-the-API magic.  :)  (functions added to the machine descriptor, 
> > maybe?)
>
> This is all too late for 2.6.19 regardless. We've gone this long without
> a generic API,

I'd be surprised to see it in 2.6.19, but that's what the patch is against;
though I'd not say it's "too late" in any absolute sense, it's certainly a
small and safe enough change (and bigger changes have gone in later).


> I see no reason to merge a temporary hack now if it's not 
> going to be satisfactory for people and require us to throw it all out
> and start over again anyways.

You've not shown any technical problems with the proposal though; nothing
about it is a "temporary hack".  The functionality in it is clearly
satisfactory enough to work for at least a dozen different platforms,
which are now using similar code.  I don't see why you're so negative...

 
> I have a real need for supporting multiple controllers and handling
> muxing dynamically from various drivers on various architectures, and
> anything that exposes the pin # higher than the controller mapping to
> function level is never going to work. Drivers have _zero_ interest in
> pin #, only in the desired function.

Sure, so what's the problem you have with this then?  It doesn't expose
pin numbers, just GPIO numbers.  It allows platforms to support multiple
controllers.  It doesn't even get in the way of whatever wierd pin mux
setup any given platforms needs.  You should be applauding!

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists