Dong Aisheng wrote at Saturday, January 14, 2012 10:58 AM:

On Sat, Jan 14, 2012 at 2:33 AM, Stephen Warren [off-list ref] wrote:

quoted

Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM:

quoted

On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren [off-list ref] wrote:
...

quoted

quoted

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.

...

quoted

(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)

...

quoted

quoted

And i'm not sure it's the right place for of_platform.c to handle
pinmux things when create new devices.

So of_device_alloc(), which is called by of_platform_populate() for each
device, already parses basic DT content such as reg and interrupts, and
converts them to Linux resources. I'd consider parsing any pinmux properties
and registering them with the pinctrl subsystem to be of a similar nature,
so adding some code to of_device_alloc() that calls a core pinmux function
to parse the DT node seems reasonable to me.

It's not perfect to me since pinmux map looks not the pure hw
conception like reg/int.
but i wonder if we can find a better way, (scanning?)

I suppose up-front scanning might work. To be fully safe, I think you'd
need to:

Enumerate all nodes with a compatible property (for anything without,
it won't be a device node, so who knows what it is).

In those nodes, look for pinctrl and pinctrl-names properties. If they're
present, process them.

For each phandle, make sure the referenced "pin configuration node" has
a specific pinctrl compatible flag (just to make sure it really is pin
control data, not some random other thing that happens to be pointed at
by a property named pinctrl from some random binding developed by some
3rd-party without review.)

I propose for this:

    compatible = "pinctrl-configuration";

Now, you know the device node and the pin configuration, so you can create
the pinctrl mapping table entries.

-- 
nvpublic