Thread (98 messages) 98 messages, 13 authors, 2012-01-20

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

From: Shawn Guo <hidden>
Date: 2012-01-11 23:10:56
Also in: linux-devicetree, lkml

On Wed, Jan 11, 2012 at 12:17:51PM -0800, Stephen Warren wrote:
...
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)
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help