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

[Shawn Guo]

On Wed, Jan 11, 2012 at 12:17:51PM -0800, Stephen Warren wrote:
> ...
> > To keep consistency as the currently design of pinctrl subsystem and also meet
> > the dt design philosophy, we still do not introduce a pinmux map in dt.
> > Instead, we choose to scan all the device node with a 'pinmux' phandle to construct
> > a pinmux map table before register the pin controller device(here we may also scan
> > the hog_on_boot node) and I guess it's easy to do that.
> ...
> > (Without scan the device node to construct the pinmux map table, we can only get the map
> > Information when we run the pinmux_get.
> > See: https://lkml.org/lkml/2012/1/5/153
> > So no pinmux map table exists and we surely do not want to see that the sysfs exporting
> > pinmux map information works in dt but unwork in non-dt)
> 
> Hmmm. I'm not sure that the pinctrl code should actively scan all nodes
> in the device tree for pin mux properties. That seems a little invasive;
> how does pinctrl know which nodes it really should be looking at, and
> which nodes are random internal parts of some device's custom binding?
> 
> Personally, I think I'd be OK with the sysfs pinctrl map file only
> containing the map entries for devices that had used the pinctrl API,
> and hence only parsing the pinmux properties in pinmux_get().
> 
During the discussion with Aisheng, I also inclined to go this way.
But it seems that he really cares about aligning dt support and
non-dt code path in pinctrl core level, which does not really matter
to me.  So if we vote, I'd vote this way.

If we go this way, all the hog_on_boot nodes need to be under particular
parent node, and get parsed and handled by pinctrl core at probe phase.

Regards,
Shawn

> However, we could perhaps do better by registering a bus notifier, and
> pro-actively parsing the top-level DT node (if there is one) for every
> device that is created. That way, the mapping would be parsed as soon
> as the device was created (or perhaps after probe?). The only case this
> might not cover is DT nodes for which the kernel doesn't actually have
> a driver, and hence no device is created.
>