From: "Fang Hongjie(方洪杰)" <hongjiefang@asrmicro.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
Linus Walleij <linus.walleij@linaro.org>,
Bastian Stender <bst@pengutronix.de>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Chanho Min <chanho.min@lge.com>,
Kyle Roeschley <kyle.roeschley@ni.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] mmc: core: improve rationality of bus width setting for HS400es
Date: Tue, 10 Jul 2018 05:04:53 +0000 [thread overview]
Message-ID: <86aa8215d6e44e578cd34f0625c5ebef@mail2012.asrmicro.com> (raw)
In-Reply-To: <CAPDyKFpzJV-UQbMa7_tHms7o3hMn9_g=H_M0jW+ZN9G=8XCqRg@mail.gmail.com>
> On 9 July 2018 at 08:47, Hongjie Fang <hongjiefang@asrmicro.com> wrote:
> > mmc_select_hs400es() calls mmc_select_bus_width() which will try to
> > set 4bit transfer mode if fail to set 8bit mode. The problem is that
> > the bus width should not be set to 4bit in HS400es mode.
>
> I guess it fails because there is something wrong. Can you please
> elaborate under what circumstance the problem occurs?
>
This problem very occasionally occurred when system resume from
suspend state. The card stuck in the programming state after setting
8bit mode. After that, mmc_select_bus_width() will continue to set
4bit mode and return without errors. Of course, the following R/W
requests will be all failing.
The problem scene is hard to reproduce. Maybe it happened
because there is something wrong about bus clock or core voltage
stability when system do resume.
> >
> > Signed-off-by: Hongjie Fang <hongjiefang@asrmicro.com>
> > ---
> > drivers/mmc/core/mmc.c | 23 +++++++++++++++++++++--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 4466f5d..94c3cc5 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1337,9 +1337,28 @@ static int mmc_select_hs400es(struct mmc_card *card)
> > if (err)
> > goto out_err;
> >
> > - err = mmc_select_bus_width(card);
> > - if (err < 0)
> > + /* Switch card to 8 bit mode */
> > + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> > + EXT_CSD_BUS_WIDTH,
> > + EXT_CSD_BUS_WIDTH_8,
> > + card->ext_csd.generic_cmd6_time);
> > + if (err) {
> > + pr_err("%s: switch to 8 bit mode for hs400es failed, err:%d\n",
> > + mmc_hostname(host), err);
> > + goto out_err;
> > + }
> > +
> > + mmc_set_bus_width(host, MMC_BUS_WIDTH_8);
> > +
> > + if (!(host->caps & MMC_CAP_BUS_WIDTH_TEST))
> > + err = mmc_compare_ext_csds(card, MMC_BUS_WIDTH_8);
> > + else
> > + err = mmc_bus_test(card, MMC_BUS_WIDTH_8);
> > + if (err) {
> > + pr_err("%s: test 8 bit mode for hs400es failed, err:%d\n",
> > + mmc_hostname(host), err);
> > goto out_err;
>
> Lot's open coding, no I don't like it.
>
> Wouldn't it instead be possible to check the return value from
> mmc_select_bus_width(), as it should tell what width it manage to
> select. Then if it isn't 8-bit, then we should bail out. Does that
> work?
>
After setting 4bit mode, it can't work because it cannot back to
HS200 mode like the HS400 mode.
For HS400es, if fail to set 8bit mode, maybe it is more reasonable
that return error directly.
> > + }
> >
> > /* Switch card to HS mode */
> > err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> > --
> > 1.9.1
> >
>
> Kind regards
> Uffe
B&R
Hongjie
next prev parent reply other threads:[~2018-07-10 5:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 6:47 [PATCH] mmc: core: improve rationality of bus width setting for HS400es Hongjie Fang
2018-07-09 11:31 ` Ulf Hansson
2018-07-10 5:04 ` Fang Hongjie(方洪杰) [this message]
2018-07-10 8:14 ` Ulf Hansson
2018-07-10 10:44 ` Fang Hongjie(方洪杰)
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=86aa8215d6e44e578cd34f0625c5ebef@mail2012.asrmicro.com \
--to=hongjiefang@asrmicro.com \
--cc=adrian.hunter@intel.com \
--cc=bst@pengutronix.de \
--cc=chanho.min@lge.com \
--cc=kyle.roeschley@ni.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=ulf.hansson@linaro.org \
--cc=wsa+renesas@sang-engineering.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 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).