Date:	Mon, 6 Feb 2012 18:29:35 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Dong Aisheng <dongas86@...il.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"Sascha Hauer (s.hauer@...gutronix.de)" <s.hauer@...gutronix.de>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	"Grant Likely (grant.likely@...retlab.ca)" 
	<grant.likely@...retlab.ca>,
	"ext Tony Lindgren (tony@...mide.com)" <tony@...mide.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: An extremely simplified pinctrl bindings proposal

On Mon, Feb 6, 2012 at 6:53 AM, Stephen Warren <swarren@...dia.com> wrote:

> I think the main argument to call it pinctrl/pinmux still is to provide
> some named API and reason for drivers to invoke when they wanted to make
> use of the feature.
>
> In other words, it's pretty easy to see why and when a driver would
> invoke a pin control API to configure the HW surrounding the HW module
> that driver controls. If we don't call that pinctrl, what else might we
> call it? That said, I'm sure we can come up with some reasonable more
> general-purpose name.

I feel pinctrl would be misleading and overly specific. Maybe something
like "hwstates" or "initvectors" or similar is more to the point. Or
just "soc-bios" :-)

An elegant way of doing it would be to hide the current pinctrl calls
behind the new API, say

hws = hardware_state_get(dev);
hardware_state_enable(hws);
hardware_state_disable(hws);
hardware_state_put(hws);

Then these can boil down to simple register read/writes or divert to
pinctrl or pinconfig.

>> A controlled set of register read/writes and maybe also conditionals
>> (...)
>
> I think anything beyond a simple linear list of register writes would
> get a /lot/ of pushback. See for example Grant's comments in one of the
> links I referenced:

OK. Keeping it simple is best then I guess.

> I can imagine the data including flags like 8/16/32/64-bit register
> accesses, or read-modify-write vs. just write (i.e. do we need to
> include a mask or not) being reasonable, but any state, looping, delay,
> conditionals etc. being nak'd.

Sure.

I have this mux on the AB8500 on the Ux500 that is on I2C.
So this off-chip device can mux its pins between GPIO and some
other functions. So I'd need something that can provide a
read/write function handle or so rather than plain register writes.
Or is this concept only for memory-mapped stuff?

>> While I would probably mourn the death of sematics I also see
>> that if the goal is to get huge static data sets out of the kernel,
>> something like this may be the best way to get there.
>
> Yes, the loss of semantics also doesn't entirely appeal to me. However,
> I wonder if the other advantages don't outweigh that.

I will certainly finalize the pinctrl subsystem as-is, adding the
pin configurations states as the last major piece. If for nothing
else it provides some understanding of the problem space.

I think we should keep both for the time being and consider the
alternative approach when patches appear. So if/when someone
creates a new subsystem like this, drivers can move over to it on a
per-driver basis. If there are zero drivers left in pinctrl it can be
deleted.

Yours,
Linus Walleij
--
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