From: Stephen Warren <swarren@wwwdotorg.org>
To: James Hogan <james.hogan@imgtec.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Heiko Stübner" <heiko@sntech.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"Grant Likely" <grant.likely@linaro.org>,
"Rob Herring" <rob.herring@calxeda.com>
Subject: Re: [PATCH 3/4] pinctrl: remove slew-rate parameter from tz1090
Date: Tue, 25 Jun 2013 15:46:24 -0600 [thread overview]
Message-ID: <51CA0FB0.7090608@wwwdotorg.org> (raw)
In-Reply-To: <51C9AFC4.1020305@imgtec.com>
On 06/25/2013 08:57 AM, James Hogan wrote:
> On 25/06/13 14:22, Linus Walleij wrote:
>> Can't we just try to come up with a patch that nails down the meaning of
>> slew rate in some meaningful manner then?
>>
>> So according to:
>> http://en.wikipedia.org/wiki/Slew_rate
>> a proper expression for slew rate would be dV/dt i.e.
>> something like microvolts per microsecond (which then just
>> becomes volts/second).
>>
>> What we need to figure out is what range will be applicable within
>> reasonable doubt for current scenarios and the next few years.
>>
>> What are your datasheets specifying here, and what would be
>> a proper measure?
>
> My datasheet says:
>
> 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? Even the order of whether 0 or 3 is highest or
lowest need not be mandated by the spec?
Note also that Tegra has separate rising and falling slew-rate
configuration.
And the slew rate is influenced by a "low-power mode" setting.
And as for James, I imagine the actual dV/dT is influenced by the
voltage on the IO rail for a particular board, since I'm pretty sure we
have some IOs that can operate at multiple different voltages, simply
based on whatever voltage is supplied for that pin/block's VDD.
next prev parent reply other threads:[~2013-06-25 21:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 12:55 [PATCH 0/4] Fix more issues with generic pinconf bindings Heiko Stübner
2013-06-25 12:55 ` Heiko Stübner
2013-06-25 12:55 ` [PATCH 1/4] pinctrl: more clarifications for generic pull configs Heiko Stübner
2013-06-25 13:14 ` Linus Walleij
2013-06-25 12:56 ` [PATCH 2/4] pinctrl: set unit for debounce time pinconfig to usec Heiko Stübner
2013-06-25 13:15 ` Linus Walleij
[not found] ` <201306251455.01540.heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
2013-06-25 12:56 ` [PATCH 3/4] pinctrl: remove slew-rate parameter from tz1090 Heiko Stübner
2013-06-25 12:56 ` Heiko Stübner
2013-06-25 13:05 ` James Hogan
2013-06-25 13:05 ` James Hogan
2013-06-25 13:21 ` Heiko Stübner
2013-06-25 13:27 ` James Hogan
2013-06-25 13:27 ` James Hogan
2013-06-25 13:32 ` Linus Walleij
2013-06-25 13:50 ` James Hogan
2013-06-25 15:39 ` Linus Walleij
2013-06-25 21:40 ` Stephen Warren
2013-06-25 13:22 ` Linus Walleij
2013-06-25 14:57 ` James Hogan
2013-06-25 21:46 ` Stephen Warren [this message]
2013-06-27 8:32 ` Linus Walleij
2013-06-25 12:57 ` [PATCH 4/4] pinctrl: remove bindings for pinconf options needing more thought Heiko Stübner
2013-06-25 13:34 ` Linus Walleij
2013-06-25 13:16 ` [PATCH 0/4] Fix more issues with generic pinconf bindings James Hogan
2013-06-25 13:16 ` James Hogan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51CA0FB0.7090608@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@linaro.org \
--cc=heiko@sntech.de \
--cc=james.hogan@imgtec.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.