lkml.org 
[lkml]   [2013]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
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





\
 
 \ /
  Last update: 2013-11-07 23:21    [W:0.478 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site