[RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

[Dong Aisheng-B29396]

> -----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:
> > 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 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
>