From: "Bao D. Nguyen" <nguyenb@codeaurora.org>
To: ulf.hansson@linaro.org, robh+dt@kernel.org
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
asutoshd@codeaurora.org, cang@codeaurora.org,
Vijay Viswanath <vviswana@codeaurora.org>,
Ram Prakash Gupta <rampraka@codeaurora.org>,
"Bao D. Nguyen" <nguyenb@codeaurora.org>
Subject: [<PATCH v1> 3/9] mmc: host: Add device_prepare pm for mmc_host
Date: Mon, 16 Dec 2019 18:50:36 -0800 [thread overview]
Message-ID: <7dede0ae6c0574ea38cc71b166f3ca0b05856931.1576540907.git.nguyenb@codeaurora.org> (raw)
In-Reply-To: <cover.1576540906.git.nguyenb@codeaurora.org>
In-Reply-To: <cover.1576540906.git.nguyenb@codeaurora.org>
From: Vijay Viswanath <vviswana@codeaurora.org>
mmc_host is a virtual device and it doesn't have any pm ops and so during
pm registration of device, no_pm_callback gets set as true. The
mmc_host device is not runtime enabled as it is a virtual device and
mmc_host is the parent device of mmc_card. As the mmc_host is runtime
disabled, mmc_card can runtime suspend/resume without depending on
state of mmc_host during normal operations. During system suspend, the
direct_complete flag of mmc_host device gets set as it has no pm_ops.
When mmc_card successfully suspends, it clears the direct_complete flag
of its parent (mmc_host).
But in certain cases during dpm_suspend, an async error can occur after
suspend work for mmc_card is scheduled and before it gets executed. In
that case, mmc_card suspend work will not clear the direct_complete flag
of mmc_host. When mmc_host suspend comes after that of mmc_card,
it too will skip all actions.
But by this time, the mmc_host device has been added to device_suspended
list. So during resume, mmc_host resume will do dpm resume of mmc_host.
In dpm_resume, all devices which has direct_complete flag set will be
runtime_enabled. This is because, in dpm_suspend, any device with
direct_complete flag will be runtime_disabled. Thus, mmc_host which has
direct_complete flag set, will get runtime enabled during dpm_resume.
This is a problem in pm framework with direct_complete flag
(runtime enabling a device in resume when it was not runtime disabled
in suspend path).
Now that mmc_host device is runtime enabled, to runtime resume the
mmc_card, the pm framework will try to runtime resume the mmc_host
device as well and will fail. This prevents mmc_card from runtime
resuming after a runtime_suspend.
Fix this by adding a dummy suspend_prepare() fn for mmc_host. This
prevents the direct_complete flag of mmc_host device from getting set.
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
---
drivers/mmc/core/host.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 105b7a7..242657b 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -40,9 +40,28 @@ static void mmc_host_classdev_release(struct device *dev)
kfree(host);
}
+static int mmc_host_prepare(struct device *dev)
+{
+ /*
+ * Since mmc_host is a virtual device, we don't have to do anything.
+ * If we return a positive value, the pm framework will consider that
+ * the runtime suspend and system suspend of this device is same and
+ * will set direct_complete flag as true. We don't want this as the
+ * mmc_host always has positive disable_depth and setting the flag
+ * will not speed up the suspend process.
+ * So return 0.
+ */
+ return 0;
+}
+
+static const struct dev_pm_ops mmc_pm_ops = {
+ .prepare = mmc_host_prepare,
+};
+
static struct class mmc_host_class = {
.name = "mmc_host",
.dev_release = mmc_host_classdev_release,
+ .pm = &mmc_pm_ops,
};
int mmc_register_host_class(void)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2019-12-17 2:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 2:50 [<PATCH v1> 0/9] SD card bug fixes Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 1/9] mmc: core: Add a cap to use long discard size Bao D. Nguyen
2019-12-17 7:09 ` Ulf Hansson
2019-12-17 2:50 ` [<PATCH v1> 2/9] mmc: core: allow hosts to specify a large " Bao D. Nguyen
2019-12-17 2:50 ` Bao D. Nguyen [this message]
2019-12-17 2:50 ` [<PATCH v1> 4/9] mmc: core: fix SD card request queue refcount underflow during shutdown Bao D. Nguyen
2019-12-18 8:33 ` Greg KH
2019-12-17 2:50 ` [<PATCH v1> 5/9] mmc: core: fix one NULL pointer dereference after SD card is removed Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 6/9] mmc: sdhci-msm: Ignore data timeout error for R1B commands Bao D. Nguyen
2019-12-18 8:34 ` Greg KH
2019-12-17 2:50 ` [<PATCH v1> 7/9] mmc: core: Skip frequency retries for SDCC slots Bao D. Nguyen
2019-12-18 8:34 ` Greg KH
2019-12-18 11:48 ` Ulf Hansson
2019-12-18 12:04 ` Greg Kroah-Hartman
2019-12-18 13:12 ` Ulf Hansson
2019-12-17 2:50 ` [<PATCH v1> 8/9] mmc: core: remove shutdown handler Bao D. Nguyen
2019-12-17 2:50 ` [<PATCH v1> 9/9] mmc: sd: Fix trivial SD card issues Bao D. Nguyen
2019-12-18 8:29 ` Greg KH
2019-12-18 20:16 ` nguyenb
2019-12-18 8:21 ` [<PATCH v1> 0/9] SD card bug fixes Greg KH
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=7dede0ae6c0574ea38cc71b166f3ca0b05856931.1576540907.git.nguyenb@codeaurora.org \
--to=nguyenb@codeaurora.org \
--cc=asutoshd@codeaurora.org \
--cc=cang@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rampraka@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=vviswana@codeaurora.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).