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. > _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
