linux-kernel - RE: Pinmux bindings proposal

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17801D22F5@HQMAIL01.nvidia.com>
Date:	Tue, 17 Jan 2012 11:28:50 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Dong Aisheng-B29396 <B29396@...escale.com>,
	Shawn Guo <shawn.guo@...aro.org>
CC:	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"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>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: RE: Pinmux bindings proposal

Dong Aisheng wrote at Tuesday, January 17, 2012 2:47 AM:
> Shawn Guo wrote at Tuesday, January 17, 2012 4:24 PM:
> > On Mon, Jan 16, 2012 at 12:50:02PM +0000, Dong Aisheng-B29396 wrote:
> > > Stephen Warren wrote:
> > ...
> > > >                         mux =
> > > >                                 <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
> > > >                                 <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>
> > > >                                 /* Syntax example */
> > > >                                 <&foo_pmx FOO_PMX_PG_X FOO_PMX_MUX_0>;
> > >
> > > I'm still think how do we construct the pinmux map for such binding.
> > > The format you're using is:
> > > <&pmx_controller_phandle muxable_entity_id selected_function> For
> > > contruct pinmux map, we need to know at least 3 things for a device:
> > > a) pinctrl device b) function name c) group name.
> > > For a, we can get it from this binding.
> > > But for b and c, since they are constants, how to convert to name string?
> >
> > I guess, for function name, it should be retrieved from the client device node,
> > and for the group name, it should be retrieved from the node here.
>
> I guess Stephen's idea is to retrieving the function name and group name
> From the pinctrl driver since Tagre prefers to define those things in driver
> Rather than in board file or soc.dts file.
> But it does not fit for IMX since we define it in soc.dts.

You can still get the data from the driver, even if the driver got the
data from the DT instead of static tables.

> > For above example, the function name can be picked from sdhci device node
> > pinctr-names property I proposed,
>
> If I understand correctly, the pinctrl-names property you proposed represents
> The pin group state.

Yes, that's my understanding.

...
> And in this way we're still using virtual groups.
> It has no big difference as we did before like:
> pinmux-groups {
>         uart4grp: group@0 {
>                 grp-name = "uart4grp";
>                 grp-pins = <107 108>;
>                 grp-mux = <4 4>;
>         };
> 
>         sd4grp: group@1 {
>                 grp-name = "sd4grp";
>                 grp-pins = <170 171 180 181 182 183 184 185 186 187>;
>                 grp-mux = <0 0 1 1 1 1 1 1 1 1>;
>         };
> };

I'd prefer not to call these virtual groups, since "group" already has
a meaning to the pinctrl subsystem that is somewhat different. As you've
probably noticed, I've been using the term "pre-defined/canned pin
configuration"!

> The real problem is do we need to support individual pin mux
> Or still using virtual pin group?
>
> For the way Stephen proposed, we can only support individual pin mux
> Since IMX pins are not grouped together in HW.

I think the "mux" and "config" properties I had in my proposal should
deal purely with raw HW entities; nothing virtual/pre-defined/canned/...

You can get what you're calling "virtual groups" simply by defining a
bunch of pinmux configuration nodes in the pin controller's device node
and exclusively referencing those in the per-device pinctrl properties.

-- 
nvpublic

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