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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
