Dong Aisheng-B29396 wrote at Friday, January 06, 2012 3:51 AM:

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

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"
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, 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.

(as a minor nit, DT usually uses - not _ in property names, so that would
be "hog-on-boot").

-- 
nvpublic