Messages in this thread | | | From | Dong Aisheng-B29396 <> | Subject | RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings | Date | Tue, 10 Jan 2012 07:02:24 +0000 |
| |
> -----Original Message----- > From: Stephen Warren [mailto:swarren@nvidia.com] > Sent: Saturday, January 07, 2012 1:24 AM > To: Dong Aisheng-B29396; linux-kernel@vger.kernel.org > Cc: linus.walleij@stericsson.com; s.hauer@pengutronix.de; > rob.herring@calxeda.com; linux-arm-kernel@lists.infradead.org; > kernel@pengutronix.de; cjb@laptop.org; devicetree-discuss@lists.ozlabs.org > Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux > mappings > Importance: High > > Dong Aisheng-B29396 wrote at Friday, January 06, 2012 3:51 AM: > > Stephen Warren wrote at Friday, January 06, 2012 7:38 AM: > > > Dong Aisheng-B29396 wrote at Tuesday, December 27, 2011 7:41 AM: > ... > > > > But what about the pin maps without device associated? > > > > > > Indeed; that's why I'd tend towards defining a table of pinmux usage > > > in the pinmux node, and having other devices refer to that table. > > > > Currently we still prefer to use device node relationship to reflect > > the pinmux map if we can since as you said pinmux map is little > > depending on the pinctrl subsystem implementation. > > And I'm trying to do it now. > > > > > Still, if the pinmux definitions are in the device nodes, we could > > > simply make the pinmux controller have such a definition itself too, for the > "system hog" > > > case. > > > > Yes, that way I think is like: > > iomuxc@020e0000 { > > pinctrl_uart4: uart4 { > > grp-pins = <107 108>; > > grp-mux = <4 4>; > > hog_on_boot; > > }; > > } > > If pinmux usage is defined in each individual device node, Per my understanding a phandle to the pinmux usage defined in iomuxc node Is also ok. The next, you also pointed out before, we need to find a at least semi-standardized per-device "pinmux" property which is suitable for all platforms.
> and the "hog" > setup is included in the pinmux controller's own device node, then there's no > need for a "hog_on_boot" property; any pinmux setup node that's inside the > pinmux controller node would automatically be a "hog" entry, and could be > activated as soon as the pinmux controller was probed and registered with the > pinctrl subsystem. > +1 I think this is a right solution for dt without a pinmux map.
> (as a minor nit, DT usually uses - not _ in property names, so that would be > "hog-on-boot"). > > -- > nvpublic >
| |