On Tue, Jun 25, 2013 at 11:46 PM, Stephen Warren <swar...@wwwdotorg.org> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
