From: Doug Anderson <dianders@chromium.org>
To: Guenter Roeck <groeck@google.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Kishon Vijay Abraham I <kishon@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Shawn Lin <shawn.lin@rock-chips.com>,
Ziyuan Xu <xzy.xu@rock-chips.com>,
Brian Norris <briannorris@chromium.org>,
Adrian Hunter <adrian.hunter@intel.com>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Guenter Roeck <groeck@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance
Date: Mon, 20 Jun 2016 12:36:51 -0700 [thread overview]
Message-ID: <CAD=FV=XTk_mY3oJaJX8sUnUzvNf3z8PtjanKJ1a8oWKDi7TwSQ@mail.gmail.com> (raw)
In-Reply-To: <CABXOdTeO8--Rk2k8tk62uiPa6T=ZoDZjBQwMHyWpNBwJo2pinA@mail.gmail.com>
Hi,
On Mon, Jun 20, 2016 at 12:29 PM, Guenter Roeck <groeck@google.com> wrote:
> On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson
> <dianders@chromium.org> wrote:
>> Previous PHY code waited a fixed amount of time for the DLL to lock at
>> power on time. Unfortunately, the time for the DLL to lock is actually
>> a bit more dynamic and can be longer if the card clock is slower.
>>
>> Instead of waiting a fixed 30 us, let's now dynamically wait until the
>> lock bit gets set. We'll wait up to 10 ms which should be OK even if
>> the card clock is at the super slow 100 kHz.
>>
>
> 10 ms active delay (no sleep) is actually quite long. Can this code sleep ?
It is expected that in nearly all cases it will be much shorter than
10ms. The longest expected (at 400kHz) is 1.3 ms and we should only
be probing down to 300, 200, 100 kHz if we are having trouble
communicating. When running at a normal speed (50 MHz, 100 MHz, etc)
it should be much smaller and closer to 10 us or less. We could still
try to sleep in some of these cases, but IMHO the extra code
complexity for something like this that should happen very
infrequently (only at bootup or if we decide to re-tune) is probably
not worth it. Also note that at boot eMMC is (probably) on the
critical path, so there may be some boot speed benefits to continuing
as quickly as possible.
-Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Guenter Roeck <groeck-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Brian Norris
<briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Adrian Hunter
<adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Guenter Roeck <groeck-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance
Date: Mon, 20 Jun 2016 12:36:51 -0700 [thread overview]
Message-ID: <CAD=FV=XTk_mY3oJaJX8sUnUzvNf3z8PtjanKJ1a8oWKDi7TwSQ@mail.gmail.com> (raw)
In-Reply-To: <CABXOdTeO8--Rk2k8tk62uiPa6T=ZoDZjBQwMHyWpNBwJo2pinA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On Mon, Jun 20, 2016 at 12:29 PM, Guenter Roeck <groeck-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson
> <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> Previous PHY code waited a fixed amount of time for the DLL to lock at
>> power on time. Unfortunately, the time for the DLL to lock is actually
>> a bit more dynamic and can be longer if the card clock is slower.
>>
>> Instead of waiting a fixed 30 us, let's now dynamically wait until the
>> lock bit gets set. We'll wait up to 10 ms which should be OK even if
>> the card clock is at the super slow 100 kHz.
>>
>
> 10 ms active delay (no sleep) is actually quite long. Can this code sleep ?
It is expected that in nearly all cases it will be much shorter than
10ms. The longest expected (at 400kHz) is 1.3 ms and we should only
be probing down to 300, 200, 100 kHz if we are having trouble
communicating. When running at a normal speed (50 MHz, 100 MHz, etc)
it should be much smaller and closer to 10 us or less. We could still
try to sleep in some of these cases, but IMHO the extra code
complexity for something like this that should happen very
infrequently (only at bootup or if we decide to re-tune) is probably
not worth it. Also note that at boot eMMC is (probably) on the
critical path, so there may be some boot speed benefits to continuing
as quickly as possible.
-Doug
WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance
Date: Mon, 20 Jun 2016 12:36:51 -0700 [thread overview]
Message-ID: <CAD=FV=XTk_mY3oJaJX8sUnUzvNf3z8PtjanKJ1a8oWKDi7TwSQ@mail.gmail.com> (raw)
In-Reply-To: <CABXOdTeO8--Rk2k8tk62uiPa6T=ZoDZjBQwMHyWpNBwJo2pinA@mail.gmail.com>
Hi,
On Mon, Jun 20, 2016 at 12:29 PM, Guenter Roeck <groeck@google.com> wrote:
> On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson
> <dianders@chromium.org> wrote:
>> Previous PHY code waited a fixed amount of time for the DLL to lock at
>> power on time. Unfortunately, the time for the DLL to lock is actually
>> a bit more dynamic and can be longer if the card clock is slower.
>>
>> Instead of waiting a fixed 30 us, let's now dynamically wait until the
>> lock bit gets set. We'll wait up to 10 ms which should be OK even if
>> the card clock is at the super slow 100 kHz.
>>
>
> 10 ms active delay (no sleep) is actually quite long. Can this code sleep ?
It is expected that in nearly all cases it will be much shorter than
10ms. The longest expected (at 400kHz) is 1.3 ms and we should only
be probing down to 300, 200, 100 kHz if we are having trouble
communicating. When running at a normal speed (50 MHz, 100 MHz, etc)
it should be much smaller and closer to 10 us or less. We could still
try to sleep in some of these cases, but IMHO the extra code
complexity for something like this that should happen very
infrequently (only at bootup or if we decide to re-tune) is probably
not worth it. Also note that at boot eMMC is (probably) on the
critical path, so there may be some boot speed benefits to continuing
as quickly as possible.
-Doug
next prev parent reply other threads:[~2016-06-20 19:38 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:56 [PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399 Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 19:23 ` Guenter Roeck
2016-06-20 19:23 ` Guenter Roeck
2016-06-20 19:23 ` Guenter Roeck
2016-06-20 19:30 ` Doug Anderson
2016-06-20 19:30 ` Doug Anderson
2016-06-20 19:30 ` Doug Anderson
2016-06-20 19:36 ` Guenter Roeck
2016-06-20 19:36 ` Guenter Roeck
2016-06-20 19:36 ` Guenter Roeck
2016-06-20 19:38 ` Doug Anderson
2016-06-20 19:38 ` Doug Anderson
2016-06-20 19:38 ` Doug Anderson
2016-06-20 17:56 ` [PATCH v3 02/15] phy: rockchip-emmc: configure frequency range and drive impedance Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 03/15] phy: rockchip-emmc: configure default output tap delay Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 04/15] phy: rockchip-emmc: reindent the register definitions Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 19:29 ` Guenter Roeck
2016-06-20 19:29 ` Guenter Roeck
2016-06-20 19:29 ` Guenter Roeck
2016-06-20 19:36 ` Doug Anderson [this message]
2016-06-20 19:36 ` Doug Anderson
2016-06-20 19:36 ` Doug Anderson
2016-06-20 19:38 ` Guenter Roeck
2016-06-20 19:38 ` Guenter Roeck
2016-06-20 19:38 ` Guenter Roeck
2016-06-20 17:56 ` [PATCH v3 06/15] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-22 12:34 ` Adrian Hunter
2016-06-22 12:34 ` Adrian Hunter
2016-06-22 12:34 ` Adrian Hunter
2016-06-20 17:56 ` [PATCH v3 07/15] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 08/15] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399 Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-22 12:34 ` Adrian Hunter
2016-06-22 12:34 ` Adrian Hunter
2016-06-20 17:56 ` [PATCH v3 09/15] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399 Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-22 16:30 ` Heiko Stübner
2016-06-22 16:30 ` Heiko Stübner
2016-06-20 17:56 ` [PATCH v3 10/15] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 11/15] " Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-22 12:35 ` Adrian Hunter
2016-06-22 12:35 ` Adrian Hunter
2016-06-20 17:56 ` [PATCH v3 12/15] Documentation: phy: Let the rockchip eMMC PHY get an exported " Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 13/15] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off() Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` [PATCH v3 14/15] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 18:14 ` Heiko Stübner
2016-06-20 18:14 ` Heiko Stübner
2016-06-20 17:56 ` [PATCH v3 15/15] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399 Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-20 17:56 ` Douglas Anderson
2016-06-22 16:31 ` Heiko Stübner
2016-06-22 16:31 ` Heiko Stübner
2016-06-22 16:31 ` Heiko Stübner
2016-06-20 18:17 ` [PATCH v3 0/15] Changes to support 150 MHz eMMC on rk3399 Heiko Stübner
2016-06-20 18:17 ` Heiko Stübner
2016-06-22 15:23 ` Ulf Hansson
2016-06-22 15:23 ` Ulf Hansson
2016-06-22 15:23 ` Ulf Hansson
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='CAD=FV=XTk_mY3oJaJX8sUnUzvNf3z8PtjanKJ1a8oWKDi7TwSQ@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=adrian.hunter@intel.com \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=groeck@chromium.org \
--cc=groeck@google.com \
--cc=heiko@sntech.de \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=ulf.hansson@linaro.org \
--cc=xzy.xu@rock-chips.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.