Thread (6 messages) 6 messages, 4 authors, 2012-02-29

[PATCH] pinctrl: make the pinmux-pins more helpful

From: Linus Walleij <hidden>
Date: 2012-02-29 17:47:44
Also in: lkml

On Wed, Feb 29, 2012 at 6:27 PM, Stephen Warren [off-list ref] wrote:
Linus Walleij wrote at Wednesday, February 29, 2012 2:39 AM:
quoted
On Fri, Feb 24, 2012 at 5:44 PM, Stephen Warren [off-list ref] wrote:
quoted
If we do make a change like this, I'd prefer the format to be:

UNCLAIMED
"%s (HOG)", desc->owner
desc->owner
I don't see the point, the debugfs files are supposed to be
human-readable, a human is not interested in the fact that
the pinctrl device itself is owning the pin, what is interesting is
that it is hogged.
Well, I'm a human and I care far more that the pin controller device is
what owns the configuration rather than some artificial "hog" concept
is present...
Yeah OK I'll try to add both then to please both instances of
human...
quoted
On U300 it makes a lot of sense even thogh it is essentially
group based. When sitting with the datasheet with the pin names
and use groups it's simple to see exactly how any one pin is muxed
for the moment and troubleshoot from there.
If the HW muxes per group, then there's no concept of "which function is
selected for a pin", since functions are selected for a group not for a
pin.

So, the datasheet will be written in terms of "group X supports functions
A, B, C, D", not pins P, Q, R support functions "A, B, C, D". So,
representing mux function in debugfs at the group level would make a lot
more sense given that HW design.
I think we're talking past each other, it's that old thing with group
concepts again. I'd just say that for debugging
and understanding the muxing on U300 style hardware this
is very useful. It may be pointless in Tegra style HW.

Yours,
Linus Walleij
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help