linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mmc: sdhci: Map more voltage level to SDHCI_POWER_330
Date: Wed, 6 Oct 2021 17:17:59 +0200	[thread overview]
Message-ID: <CAPDyKFog+LoH1c7xobb6YeDDNN5n-eqxc_RfjZCY9phKocKzQg@mail.gmail.com> (raw)
In-Reply-To: <20211003135822.GA13320@dragon>

On Sun, 3 Oct 2021 at 15:58, Shawn Guo <shawn.guo@linaro.org> wrote:
>
> On Thu, Sep 30, 2021 at 01:00:03PM +0200, Ulf Hansson wrote:
> > On Sun, 26 Sept 2021 at 15:28, Shawn Guo <shawn.guo@linaro.org> wrote:
> > >
> > > On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
> > > which is being treated as an invalid value by sdhci_set_power_noreg().
> > > And thus eMMC is totally broken on the platform.
> > >
> > > [    1.436599] ------------[ cut here ]------------
> > > [    1.436606] mmc0: Invalid vdd 0x17
> > > [    1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
> > > [    1.436655] Modules linked in:
> > > [    1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G        W         5.15.0-rc1+ #137
> > > [    1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
> > > [    1.436674] Workqueue: events_unbound async_run_entry_fn
> > > [    1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [    1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
> > > [    1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
> > > [    1.436703] sp : ffff800010803a60
> > > [    1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
> > > [    1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
> > > [    1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
> > > [    1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
> > > [    1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
> > > [    1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
> > > [    1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
> > > [    1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
> > > [    1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
> > > [    1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
> > > [    1.436797] Call trace:
> > > [    1.436800]  sdhci_set_power_noreg+0x168/0x2b4
> > > [    1.436805]  sdhci_set_ios+0xa0/0x7fc
> > > [    1.436811]  mmc_power_up.part.0+0xc4/0x164
> > > [    1.436818]  mmc_start_host+0xa0/0xb0
> > > [    1.436824]  mmc_add_host+0x60/0x90
> > > [    1.436830]  __sdhci_add_host+0x174/0x330
> > > [    1.436836]  sdhci_msm_probe+0x7c0/0x920
> > > [    1.436842]  platform_probe+0x68/0xe0
> > > [    1.436850]  really_probe.part.0+0x9c/0x31c
> > > [    1.436857]  __driver_probe_device+0x98/0x144
> > > [    1.436863]  driver_probe_device+0xc8/0x15c
> > > [    1.436869]  __device_attach_driver+0xb4/0x120
> > > [    1.436875]  bus_for_each_drv+0x78/0xd0
> > > [    1.436881]  __device_attach_async_helper+0xac/0xd0
> > > [    1.436888]  async_run_entry_fn+0x34/0x110
> > > [    1.436895]  process_one_work+0x1d0/0x354
> > > [    1.436903]  worker_thread+0x13c/0x470
> > > [    1.436910]  kthread+0x150/0x160
> > > [    1.436915]  ret_from_fork+0x10/0x20
> > > [    1.436923] ---[ end trace fcfac44cb045c3a8 ]---
> > >
> > > Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
> > > SDHCI_POWER_330 as well.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > ---
> > > I'm not sure if this is the right solution, as I do not have SDHCI
> > > specification.  Hence it's a RFC.
> > >
> > >  drivers/mmc/host/sdhci.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > index 8eefa7d5fe85..2427481535a3 100644
> > > --- a/drivers/mmc/host/sdhci.c
> > > +++ b/drivers/mmc/host/sdhci.c
> > > @@ -2042,6 +2042,8 @@ void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
> > >                         break;
> > >                 case MMC_VDD_32_33:
> > >                 case MMC_VDD_33_34:
> > > +               case MMC_VDD_34_35:
> > > +               case MMC_VDD_35_36:
> > >                         pwr = SDHCI_POWER_330;
> >
> > The SDHCI specification doesn't state exactly what level
> > SDHCI_POWER_330 corresponds to. It's 3.3V typically.
> >
> > I don't have any strong opinion about this change, although I am a
> > little bit puzzled over why this solves the problem for you.
> >
> > Unless the host (sdhci) announces that it supports MMC_VDD_34_35 or
> > MMC_VDD_35_36 through its mmc->ocr_avail mask, the mmc core shouldn't
> > try to use it. Can you perhaps check what value the mmc->ocr_avail
> > gets assigned to in sdhci_setup_host() for your mmc host?
>
> Hi Ulf,
>
> Thanks for the comment!
>
> ocr_avail is 0xfff800, which is a result of mmc_regulator_get_ocrmask()
> call.  On this platform, the vmmc has a 3.6V max voltage.  I can enforce
> `regulator-max-microvolt` to be 3.3V to fix the problem, but I'm not
> sure it's more correct than this RFC change.

I see, thanks for clarifying.

Kind regards
Uffe

      parent reply	other threads:[~2021-10-06 15:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-26 13:28 [RFC PATCH] mmc: sdhci: Map more voltage level to SDHCI_POWER_330 Shawn Guo
2021-09-30 11:00 ` Ulf Hansson
2021-10-03 13:58   ` Shawn Guo
2021-10-03 15:47     ` Adrian Hunter
2021-10-04  2:33       ` Shawn Guo
2021-10-06 15:17     ` Ulf Hansson [this message]

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=CAPDyKFog+LoH1c7xobb6YeDDNN5n-eqxc_RfjZCY9phKocKzQg@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=shawn.guo@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).