All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH 3/5] mmc: core: changes frequency to hs_max_dtr when selecting hs400es
Date: Thu, 22 Sep 2016 12:21:17 +0200	[thread overview]
Message-ID: <CAPDyKFrNp=Y3BhVE_kxtggv7Qc6m=2kef2U8Dn2Bb3ANHPYV-Q@mail.gmail.com> (raw)
In-Reply-To: <62a8d622-39d2-db7d-042d-5425a3efba58@rock-chips.com>

On 22 September 2016 at 12:06, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hi ulf,
>
> 在 2016/9/22 17:38, Ulf Hansson 写道:
>>
>> On 21 September 2016 at 03:43, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>>
>>> Per JESD84-B51 P69, Host need to change frequency to <=52MHz after
>>> setting HS_TIMING to 0x1, and host may changes frequency to <= 200MHz
>>> after setting HS_TIMING to 0x3. It seems there is no difference if
>>> we don't change frequency to <= 52MHz as f_init is already less than
>>> 52MHz. But actually it does make difference. When doing compatibility
>>> test we see failures for some eMMC devices without changing the
>>> frequency to hs_max_dtr. And let's read the spec again, we could see
>>> that "Host may changes frequency to 200MHz" implies that it's not
>>> mandatory. But the "Host need to change frequency to <= 52MHz" implies
>>> that we should do this.
>>
>>
>> I don't get this. Are you saying that f_init > 52 MHz? That should not
>> be impossible, right!?
>
>
> nope, I was saying that the spec implies we to set clock after
> setting HS_TIMING to 0x1 when doing hs400es selection.
>
> I thought there is no difference because the spec says "Host need to
> change frequency to <= 52MHz", and the f_init(<=400k) is <= 52MHz,
> right? So I didn't set clock to hs_max_dtr. But I think I misunderstood
> the spec, so this patch will fix this.

Okay, I see what you mean now!

In other words:
The card expects the clock rate to increase from the current used
f_init (which is <= 400KHz), but still being <= 52MHz, when you have
set HS_TIMING to 0x1.

Okay, we can do that change! Could you try to improve the change log a
little bit or you want me to help?

Kind regards
Uffe

  reply	other threads:[~2016-09-22 10:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21  1:43 [PATCH 0/5] Some fixes for mmc core and sdhci/arasan Shawn Lin
2016-09-21  1:43 ` [PATCH 1/5] mmc: core: don't try to switch block size for dual rate mode Shawn Lin
2016-09-22  9:40   ` Ulf Hansson
2016-09-21  1:43 ` [PATCH 2/5] mmc: core: switch to 1V8 or 1V2 for hs400es mode Shawn Lin
2016-09-21  1:43   ` Shawn Lin
2016-09-22  9:39   ` Ulf Hansson
2016-09-21  1:43 ` [PATCH 3/5] mmc: core: changes frequency to hs_max_dtr when selecting hs400es Shawn Lin
2016-09-22  9:38   ` Ulf Hansson
2016-09-22 10:06     ` Shawn Lin
2016-09-22 10:21       ` Ulf Hansson [this message]
2016-09-22 23:34         ` Shawn Lin
2016-09-21  1:43 ` [PATCH 4/5] mmc: sdhci: Don't try to switch to unsupported voltage Shawn Lin
2016-09-21  1:45 ` [PATCH 5/5] mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan,5.1 Shawn Lin

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='CAPDyKFrNp=Y3BhVE_kxtggv7Qc6m=2kef2U8Dn2Bb3ANHPYV-Q@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=jh80.chung@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=shawn.lin@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.