[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17761F18F8@HQMAIL01.nvidia.com>
Date: Thu, 5 Jan 2012 17:05:46 -0800
From: Stephen Warren <swarren@...dia.com>
To: Dong Aisheng <dongas86@...il.com>
CC: Dong Aisheng-B29396 <B29396@...escale.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"cjb@...top.org" <cjb@...top.org>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
mappings
Dong Aisheng wrote at Thursday, January 05, 2012 6:48 AM:
> On Sun, Dec 25, 2011 at 11:37 AM, Stephen Warren <swarren@...dia.com> wrote:
> > Dong Aisheng-B29396 wrote at Thursday, December 22, 2011 1:18 AM:
...
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl.txt
...
> +Examples:
> +soc {
> + aips-bus@...00000 { /* AIPS1 */
> + iomuxc@...e0000 {
> + pinctrl_uart4: uart4 {
> + func-name = "uart4";
> + grp-name = "uart4grp";
> + grp-pins = <107 108>;
> + num-pins = <2>;
> + grp-mux = <4 4>;
> + num-mux = <2>;
> + };
Before I get too far into reviewing this path, could you explain the
above node in a little more detail; what it is and what the properties
define?
I'm confused because the node has properties for function name and
group name which make sense to define the mux setting for that group.
However, I'm not sure what the grp-pins/num-pins/grp-mux/num-mux
properties are for; if those properties define the available mux options
and for the group and set of pins included in the group, I think the node
is representing too many things in one place. I'd expect to see:
a) Either data in the pinctrl driver or separate DT nodes to define each
available pin group, mux function, etc.; the definition of what the SoC
itself can do.
b) The configuration of each pin group that's used by the particular board.
All that's relevant here is the mux selection for each pin groups; things
like which pins are included in each group are defined by the SoC not the
board and hence wouldn't be included in a per-board node.
Thanks for enlightening me!
> +
> + pinctrl_sd4: sd4 {
> + func-name = "sd4";
> + grp-name = "sd4grp";
> + grp-pins = <170 171 180 181 182 183 184 185 186 187>;
> + num-pins = <10>;
> + grp-mux = <0 0 1 1 1 1 1 1 1 1>;
> + num-mux = <10>;
> + };
> + };
> + };
> +
> + aips-bus@...00000 { /* AIPS2 */
> + usdhc@...9c000 { /* uSDHC4 */
> + fsl,card-wired;
> + status = "okay";
> + pinmux = <&pinctrl_sd4>;
> + };
> +
> + uart3: uart@...f0000 { /* UART4 */
> + status = "okay";
> + pinmux = <&pinctrl_uart4>;
> + };
> + };
> +};
--
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/
Powered by blists - more mailing lists