-----Original Message-----
From: Stephen Warren [mailto:swarren at nvidia.com]
Sent: Saturday, January 07, 2012 1:24 AM
To: Dong Aisheng-B29396; linux-kernel at vger.kernel.org
Cc: linus.walleij at stericsson.com; s.hauer at pengutronix.de;
rob.herring at calxeda.com; linux-arm-kernel at lists.infradead.org;
kernel at pengutronix.de; cjb at laptop.org; devicetree-discuss at 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:

quoted

Stephen Warren wrote at Friday, January 06, 2012 7:38 AM:

quoted

Dong Aisheng-B29396 wrote at Tuesday, December 27, 2011 7:41 AM:

...

quoted

quoted

quoted

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.

quoted

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"

quoted

quoted

case.

Yes, that way I think is like:
iomuxc at 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