linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: hieagle <chgokhl@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kehuanlin@fishsemi.com
Subject: Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks
Date: Tue, 23 Mar 2021 18:49:24 +0800	[thread overview]
Message-ID: <CAMjpFAW0D12vxNSYLcwSWxf-zB+toT5cmiQ8mtUUE+nzWMJZ3g@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFqXtKPngfnQZXXaF=rvqw0=nWzDc7P++QxNHPwGHHSxUA@mail.gmail.com>

We encounter a resume issue in our device sometimes. The mmc device's
parent list is
mmc0:0001->mmc_host mmc0->fa630000.mmc->soc in our soc. We found in the blow
case with mmc0->power.disable_depth=0 the mmc_runtime_resume will be skipped,
which cause subsequent mmc command fail.

mmc_get_card(mmc0:0001)->pm_runtime_get_sync->rpm_resume(mmc0:0001)->rpm_resume(mmc0)
The rpm_resume(mmc0) return -ENOSYS due to no callback and
mmc0->power.runtime_status
keep RPM_SUSPENDED. This lead to rpm_resume(mmc0:0001) return -EBUSY and skip
rpm_callback which call mmc_runtime_resume, the mmc is still in
suspended and the
subsequent mmc command fail.

[  198.856157] Call trace:
[  198.858917] [<ffffff800808bd9c>] dump_backtrace+0x0/0x1cc
[  198.864966] [<ffffff800808bf7c>] show_stack+0x14/0x1c
[  198.870627] [<ffffff8008400e88>] dump_stack+0xa8/0xe0
[  198.876288] [<ffffff800854d38c>] rpm_resume+0x850/0x938
[  198.882141] [<ffffff800854cd8c>] rpm_resume+0x250/0x938
[  198.887994] [<ffffff800854d4c4>] __pm_runtime_resume+0x50/0x74
[  198.894530] [<ffffff80087b9e64>] mmc_get_card+0x3c/0xb8
[  198.900388] [<ffffff80087cd2e0>] mmc_blk_issue_rq+0x2b0/0x4d8
[  198.906824] [<ffffff80087cd5e4>] mmc_queue_thread+0xdc/0x198
[  198.913165] [<ffffff80080d4b2c>] kthread+0xec/0x100
[  198.918632] [<ffffff8008083890>] ret_from_fork+0x10/0x40
[  198.924582] mmc0  callback           (null)
[  198.935837] mmcblk mmc0:0001: __pm_runtime_resume ret -16

Mark mmc_host device with pm_runtime_no_callbacks will solve the issue.
Thanks.
Huanlin Ke

Ulf Hansson <ulf.hansson@linaro.org> 于2021年3月22日周一 下午6:26写道:
>
> On Sat, 20 Mar 2021 at 05:57, kehuanlin <chgokhl@gmail.com> wrote:
> >
> > The rpm_resume() will call parent's resume callback recursively.
> > Since mmc_host has no its own pm_runtime callbacks, the mmc devices
> > may fail to resume (-ENOSYS in rpm_callback) sometimes. Mark mmc_host
> > device with pm_runtime_no_callbacks can fix the issue.
>
> Can you please elaborate more on this? What do you mean by "sometimes"?
>
> More precisely, how do you trigger the rpm_callback() for mmc class
> device to return -ENOSYS?
>
> Don't get me wrong, the patch is fine, but I want to understand if it
> actually solves a problem for you - or that it's better considered as
> an optimization?
>
> Kind regards
> Uffe
>
> >
> > Signed-off-by: kehuanlin <chgokhl@gmail.com>
> > ---
> >  drivers/mmc/core/host.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > index 9b89a91b6b47..177bebd9a6c4 100644
> > --- a/drivers/mmc/core/host.c
> > +++ b/drivers/mmc/core/host.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/of.h>
> >  #include <linux/of_gpio.h>
> >  #include <linux/pagemap.h>
> > +#include <linux/pm_runtime.h>
> >  #include <linux/pm_wakeup.h>
> >  #include <linux/export.h>
> >  #include <linux/leds.h>
> > @@ -480,6 +481,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
> >         host->class_dev.class = &mmc_host_class;
> >         device_initialize(&host->class_dev);
> >         device_enable_async_suspend(&host->class_dev);
> > +       pm_runtime_no_callbacks(&host->class_dev);
> >
> >         if (mmc_gpio_alloc(host)) {
> >                 put_device(&host->class_dev);
> > --
> > 2.30.0
> >

  reply	other threads:[~2021-03-23 10:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20  4:57 [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks kehuanlin
2021-03-22 10:25 ` Ulf Hansson
2021-03-23 10:49   ` hieagle [this message]
2021-03-23 14:00     ` Ulf Hansson
2021-05-07 11:38       ` Ulf Hansson
2021-05-26 12:18       ` Ulf Hansson
2021-06-21  1:38   ` hieagle
2021-06-21  9:20     ` Ulf Hansson

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=CAMjpFAW0D12vxNSYLcwSWxf-zB+toT5cmiQ8mtUUE+nzWMJZ3g@mail.gmail.com \
    --to=chgokhl@gmail.com \
    --cc=chgokhl@163.com \
    --cc=kehuanlin@fishsemi.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).