All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: shawn.lin@rock-chips.com, 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 18:06:52 +0800	[thread overview]
Message-ID: <62a8d622-39d2-db7d-042d-5425a3efba58@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFoHxSpFurgV9swN3MCTWUinPFNUHSzxgyKj+K3iqkGSbA@mail.gmail.com>

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.


>
> So either the core has changed the clock rate by mistake at some other
> execution path, or the host driver didn't set the correct clock rate
> the first time when invoked via mmc_power_up()?
>
> Kind regards
> Uffe
>
>>
>> Reported-by: Xiao Yao <xiaoyao@rock-chips.com>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>> ---
>>
>>  drivers/mmc/core/mmc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 3163bb9..989d37e 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1282,6 +1282,8 @@ static int mmc_select_hs400es(struct mmc_card *card)
>>         if (err)
>>                 goto out_err;
>>
>> +       mmc_set_clock(host, card->ext_csd.hs_max_dtr);
>> +
>>         err = mmc_switch_status(card);
>>         if (err)
>>                 goto out_err;
>> --
>> 2.3.7
>>
>>
>
>
>


-- 
Best Regards
Shawn Lin

  reply	other threads:[~2016-09-22 10:07 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 [this message]
2016-09-22 10:21       ` Ulf Hansson
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=62a8d622-39d2-db7d-042d-5425a3efba58@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --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=ulf.hansson@linaro.org \
    /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.