linux-kernel - Re: Pinmux bindings proposal V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120127171653.GI13504@atomide.com>
Date:	Fri, 27 Jan 2012 09:16:53 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Shawn Guo <shawn.guo@...aro.org>
Cc:	Stephen Warren <swarren@...dia.com>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"Linus Walleij (linus.walleij@...aro.org)" <linus.walleij@...aro.org>,
	"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>,
	Dong Aisheng <dongas86@...il.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	"Grant Likely (grant.likely@...retlab.ca)" 
	<grant.likely@...retlab.ca>,
	"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: Pinmux bindings proposal V2

* Shawn Guo <shawn.guo@...aro.org> [120126 22:37]:
> On Thu, Jan 26, 2012 at 09:51:23AM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Shawn Guo <shawn.guo@...aro.org> [120126 00:53]:
> > > 
> > > On Mon, Jan 23, 2012 at 01:00:52PM -0800, Tony Lindgren wrote:
> > > ...
> > > > So to summarize: I suggest we'll just stick to basics to get the system
> > > > booting and devices working using device tree. In most cases the device
> > > > drivers should be able to configure the suspend and off states in a generic
> > > > way using pinctrl API. Everything else, like debugging, we can probably
> > > > do with userspace tools.
> > > > 
> > > > This would mean just using a minimal subset of your binding, probably
> > > > very close to what you originally suggested.
> > > > 
> > > IMHO, as a generic device tree binding, it should be able to cope with
> > > different use cases.  It's really free for you to use the minimal
> > > subset of the binding as your need, but we should not make the binding
> > > design just be that minimal subset to force that everyone else can
> > > only use the minimal subset.
> > 
> > The main issue I have is that the example posted in this thread repeats
> > the same registers five times for one driver entry alone in the device
> > tree data. The repeated registers are TEGRA_PMX_PG_DTA and TEGRA_PMX_PG_DTD
> > in the example.
> > 
> > The alternative values are something that the pinmux/pinconf driver can
> > set based on state changes communicated from the driver using these pins.
> 
> I'm against the idea that requires client device drivers call pinctrl
> APIs on pin basis.  They do not even know or care about the pins that
> they are using.  That's all pinctrl driver's business.  All client
> driver needs to do when it wants to change pinctrl setup should just
> be calling pinmux/pinconf_get/put[enable/disable](dev, "state").

That should work fine too. As long as the states are generic, such as
PMX_STATE_ENABLED, PMX_STATE_IDLE, PMX_STATE_SUSPEND, PMX_STATE_OFF
and so on. You really don't want to change states with some string
names if you need to toggle something every time your enter and exit
idle. And it should be possible to set it on per pin or pingroup basis.
For wake-up events you typically just toggle one pin for the device,
such as serial rx line.

I guess the analog we should follow here is clk_get and clk_set_rate,
except we would have pinconf_set_state with predefined states.

Regards,

Tony
--
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/