[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.