linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chaotian Jing <chaotian.jing@mediatek.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	"Seo, Kyungmin" <kyungmin.seo@intel.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: mmc: Fix the timing for clock changing in mmc
Date: Wed, 11 Mar 2020 10:13:26 +0800	[thread overview]
Message-ID: <1583892806.24941.7.camel@mhfsdcap03> (raw)
In-Reply-To: <CAPDyKFosrju6y5mOKePsNwqgDr=QeBozFTrWKz4MNpsMmeZdCA@mail.gmail.com>

On Tue, 2020-03-10 at 16:41 +0100, Ulf Hansson wrote:
> On Tue, 10 Mar 2020 at 11:44, Adrian Hunter <adrian.hunter@intel.com> wrote:
> >
> > On 10/03/20 11:05 am, Ulf Hansson wrote:
> > > On Tue, 10 Mar 2020 at 05:28, Seo, Kyungmin <kyungmin.seo@intel.com> wrote:
> > >>
> > >> I read the link and patch of Chaotian Jing.
> > >> I also point out what Chaotian said.
> > >> Most host controllers have DLL tuning values for each mode. When host controller is set as HS400 mode with 50MHz clock, host controller uses DLL value which is tuned with 200MHz clock.
> > >>
> > >> If DLL value in HS400 mode doesn't have the pass range in HS mode, command transfer failing may fail.
> > >> In order to make robust sdhci driver, I think the patch needs to be considered.
> > >
> > > I have, but I am not picking it up in its current form.
> > >
> > >> Of course, CMD6 with HS400 mode and 200MHz clock should not cause any problem because it's correct configuration.
> > >
> > > Yes, but not for all cases, as I said in my reply in those email-threads.
> > >
> > > What I had in mind, is that I I think we should inform
> > > mmc_hs400_to_hs200() about under what situation it's getting called.
> > > Depending on that, we should either decrease the clock rate before or
> > > after we send the CMD6.
> > >
> > > Would that work for your case?
> >
> > Ulf, would you consider a new call back e.g.
> 
> That could work, but I am not sure what's best, honestly.
> 
> The problem may be generic or it could be specific to some host
> controller? I think we need to answer that question first.
> 
> What do you think?
> 
> Br
> Uffe
> 
When start to send CMD6 to switch to HS mode, both Host & eMMC device
are working on HS400 mode, so the timing used is MUST at HS400 mode and
the clock MUST keep at current clock(usually 200Mhz). after received the
response of CMD6, Never use CMD13 to polling card status for timing
switch. if host has ops->card_busy() or caps WAIT_WHILE_BUSY, then use
it, if not,just do mmc_delay() for specific time.

the next step is that call mmc_set_ios() to set current timing to HS
mode and clock to 50Mhz to let Host driver that eMMC device has been
switched to HS mode and Host can switch to HS mode at 50Mhz(may apply
parameters for this low speed).
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index c2abd417a84a..1bc18fe2632f 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1237,7 +1237,10 @@ int mmc_hs400_to_hs200(struct mmc_card *card)
> >
> >         /* Reduce frequency to HS */
> >         max_dtr = card->ext_csd.hs_max_dtr;
> > -       mmc_set_clock(host, max_dtr);
> > +       if (host->ops->hs400_to_hs200_prep)
> > +               host->ops->hs400_to_hs200_prep(host, max_dtr);
> > +       else
> > +               mmc_set_clock(host, max_dtr);
> >
> >         /* Switch HS400 to HS DDR */
> >         val = EXT_CSD_TIMING_HS;
> >
> >
> 
> [...]
> 
> Kind regards
> Uffe


  reply	other threads:[~2020-03-11  2:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12  2:42 [PATCH] mmc: mmc: Fix the timing for clock changing in mmc Kyungmin Seo
2020-03-04 11:08 ` Ulf Hansson
2020-03-05  8:57   ` Seo, Kyungmin
2020-03-05 15:17     ` Ulf Hansson
2020-03-10  4:27       ` Seo, Kyungmin
2020-03-10  9:05         ` Ulf Hansson
2020-03-10 10:44           ` Adrian Hunter
2020-03-10 15:41             ` Ulf Hansson
2020-03-11  2:13               ` Chaotian Jing [this message]
2020-03-11  8:57                 ` Ulf Hansson
2020-03-11  9:59                   ` Adrian Hunter
2020-03-11 14:06                     ` Ulf Hansson
2020-03-11 14:43                       ` Adrian Hunter

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=1583892806.24941.7.camel@mhfsdcap03 \
    --to=chaotian.jing@mediatek.com \
    --cc=adrian.hunter@intel.com \
    --cc=kyungmin.seo@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).