On 13-11-06 09:00 AM, Stephen Warren wrote:
You probably don't want to reference the individual xxx1/2/3 nodes in the client pinctrl properties, but instead wrap them in a higher-level node that represents the whole pinctrl state. Then, the client pinctrl properties can reference just that single parent node, instead of many small nodes. In other words:pinctrl@... { ... sx: state_xxx { xxx1 { ... }; xxx2 { ... }; xxx3 { ... }; }; sy: state_yyy { yyy1 { ... }; yyy2 { ... }; }; } some_client@... { ... pinctrl-names = "default"; pinctrl-0 = <&sx>; }; other_client@... { ... pinctrl-names = "default"; pinctrl-0 = <&sy>; }; rather than: pinctrl@... { ... sx1: xxx1 { ... }; sx2: xxx2 { ... }; sx3: xxx3 { ... }; sy1: yyy1 { ... }; sy2: yyy2 { ... }; } some_client@... { ... pinctrl-names = "default"; pinctrl-0 = <&sx1 &sx2 &sx3>; }; other_client@... { ... pinctrl-names = "default"; pinctrl-0 = <&sy1 &sy2>; }; This is exactly how the Tegra pinctrl bindings work for example.
Ok, right, I mistakenly thought the "xxx1" nodes are pin config nodes. Actually that's the way my original driver works as well, other than the fact that I don't have as many "xxx1" type nodes as decribed in the "xxx" node below.
This works fine. However, I'm just thinking that it would have been easier if we could specify just one node: xxx { pins = <PINA>, <PINB>, <PINC>; function = <...>; pull-up = <1 1 0>; } This "feature" seems a bit more concise to me and is what I did for my original pinctrl driver. The only downside is that with this method, one cannot specify "don't touch this option for this pin" if the same property must provide values for other pins.The other downside is that if the lists get even slightly long, it get really hard to match up the entries in the t properties.
Agree that it would start to get difficult to read if a subnode has too many pins. I guess the solution would be to somehow split up the pins to more subnodes with fewer pins each.
Regards, Sherman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
