Thread (20 messages) 20 messages, 4 authors, 2013-06-27

Re: [PATCH 3/4] pinctrl: remove slew-rate parameter from tz1090

From: Linus Walleij <hidden>
Date: 2013-06-27 08:32:05
Also in: lkml

On Tue, Jun 25, 2013 at 11:46 PM, Stephen Warren [off-list ref] wrote:
On 06/25/2013 08:57 AM, James Hogan wrote:
quoted
0: slow (half frequency)
1: fast

I just got a reply back from a hardware engineer, who said that the
relationship with the actual volts/usec will depend on both the drive
strength and the load on the pad, and that a definite answer probably
requires running a simulation.
Tegra is similar here. The docs just say (for a 2-bit field expressed in
binary) "Code 11 is the least slewing of the signal, code 00 is the
highest slewing of the signal".

I'm not sure that a generic parameter actually needs specific units. Why
can't we simply specify the units as HW-defined, even while using a
standardized DT property name and kernel-internal enum to represent the
concept of slew rate?
That is fine I guess, that is how it is currently defined for the
kernel internals in
<linux/pinconf/pinconf-generic.h>:

 * @PIN_CONFIG_SLEW_RATE: if the pin can select slew rate, the argument to
 *      this parameter (on a custom format) tells the driver which alternative
 *      slew rate to use.

It's just that the very phrase "device tree" bring out the
standards body slow-and-impersonal considering all aspects
of the world side of me.

Unless someone from the DT camp think it is horrible to have
this value vendor-specific I'm all game.

But I guess it needs some binding doc for each and every pin
controller in that case, so referring to the generic binding will
not work. (And the driver needs to do some range checking
etc I guess.)

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