| 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
| ||
|
Date: Fri, 6 Jan 2012 11:33:54 +0000
From: Dong Aisheng-B29396 <B29396@...escale.com>
To: Stephen Warren <swarren@...dia.com>,
Dong Aisheng <dongas86@...il.com>
CC: "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
> -----Original Message-----
> From: Stephen Warren [mailto:swarren@...dia.com]
> Sent: Friday, January 06, 2012 9:06 AM
> To: Dong Aisheng
> Cc: Dong Aisheng-B29396; linux-kernel@...r.kernel.org;
> linus.walleij@...ricsson.com; s.hauer@...gutronix.de; rob.herring@...xeda.com;
> linux-arm-kernel@...ts.infradead.org; kernel@...gutronix.de; cjb@...top.org;
> devicetree-discuss@...ts.ozlabs.org
> Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
> mappings
> Importance: High
>
> 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?
>
grp-pins is the group of pins for this function.
grp-mux is the corresponding mux setting of each pin in that group for this specific
function.
num-pins and num-mux are the number of pins and mux. They're mainly used for sanity
Checking in driver since it's easy to make a mistake when write too many pins for a
function. These two could be removed finally.
> 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.
>
We still have not started pin config work.
For pinmux, one way we thought is trying to define pin groups
in soc dts file and reference that pin group by a phandle in board dts file.
It could be:
In the soc dts file arch/arm/boot/dts/imx6q.dtsi:
iomuxc@...e0000 {
reg = <0x020e0000 0x4000>;
pinmux-groups {
pingrp_uart4: uart4 {
grp-pins = <107 108>;
grp-mux = <4 4>;
};
pingrp_sd4: sd4 {
grp-pins = <170 171 180 181 182 183 184 185 186 187>;
grp-mux = <0 0 1 1 1 1 1 1 1 1>;
}
}
};
In board dts file:
usdhc@...9c000 { /* uSDHC4 */
fsl,card-wired;
status = "okay";
pinmux = <&pinctrl_sd4>;
};
uart3: uart@...f0000 { /* UART4 */
status = "okay";
pinmux = <&pinctrl_uart4>;
};
iomuxc@...e0000 {
pinctrl_uart4: uart4 {
group = <&pingrp_uart4>;
pinconfig = ....;
};
pinctrl_sd4: sd4 {
group = <&pingrp_sd4>;
pinconfig = ....;
};
};
Then we know the whole map information for a specific device without a pinmux map.
Do you think if it's ok?
BTW, for imx we won't define all possible groups since most are useless and
It's hard to cover all cases due to the issue raised by Sascha before.
We only define what we're most using firstly.
> 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
>
Regards
Dong Aisheng
--
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