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

[Linus Walleij]

On Tue, Jun 25, 2013 at 11:46 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 06/25/2013 08:57 AM, James Hogan wrote:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/