Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751619AbdDLFBz (ORCPT ); Wed, 12 Apr 2017 01:01:55 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:57856 "EHLO epoutp01.samsung.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751042AbdDLFBw (ORCPT ); Wed, 12 Apr 2017 01:01:52 -0400 X-AuditID: b6c32a36-f79446d000002bcd-30-58edb4bd52d3 Subject: Re: [PATCH] mmc: dw_mmc: Don't allow Runtime PM for SDIO cards To: Douglas Anderson , Ulf Hansson Cc: briannorris@chromium.org, linux-rockchip@lists.infradead.org, Shawn Lin , Heiko Stuebner , kevin@archlinuxarm.org, amstan@chromium.org, xzy.xu@rock-chips.com, stable@vger.kernel.org, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org From: Jaehoon Chung Message-id: <395baac5-d53b-f4bf-b044-73ee790cbc23@samsung.com> Date: Wed, 12 Apr 2017 14:01:49 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-version: 1.0 In-reply-to: <20170411225543.987-1-dianders@chromium.org> Content-type: text/plain; charset="windows-1252" Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGJsWRmVeSWpSXmKPExsWy7bCmvu7eLW8jDK7MV7JoeDGJ1WLTx/es FmeXHWSz+P/oNatF4zIRi8u75rBZHPnfz2jx6cF/Zos7T9azWizY+IjR4vjacIsl80MdeDyu XDzA6DG74SKLx51re9g8Ni+p9/g7az+Lx/Zr85g9Pm+SC2CPSrXJSE1MSS1SSM1Lzk/JzEu3 VfIOjneONzUzMNQ1tLQwV1LIS8xNtVVy8QnQdcvMAbpSSaEsMacUKBSQWFyspG9nU5RfWpKq kJFfXGKrFG1oaKRnaGCuZ2RkpGdiHGtlZApUkpCasfWGe8Fv+YrH35axNjA+kOxi5OSQEDCR 2DF7AjuELSZx4d56ti5GLg4hgR2MEou6pjNBOO1MEn8mN7DBdHx//4cRIjGHUeLYpT5WCOce o8SumbPAqoQF3CW2/7nECmKLCIRIvN+1BSzOLLCUSeLChEwQm01AR2L7t+NMIDavgJ3EyQdr WUBsFgFViS8XJjOC2KICYRKb779kh6gRlPgx+R5QDQcHp4ClxI/PnBAjDSRmTDnMBGHLS2xe 85YZ5B4JgVvsEhMvPmUCqZcQkJXYdIAZ4gEXidUbTkLZwhKvjm+Bel9aYtW/W0wQve2MErd+ 7GODcDoYJQ7+3MsKUWUscf/BPWaIbXwS7772sEIs4JXoaBOCKPGQ6N9wB2qvo8TZmYWQ8Olh lFj79AjrBEb5WUjemYXkh1lIfljAyLyKUSy1oDg3PbXYsMBIrzgxt7g0L10vOT93EyM4jWqZ 7WBcdM7nEKMAB6MSD++Cc28ihFgTy4orcw8xSnAwK4nw1m14GyHEm5JYWZValB9fVJqTWnyI 0RQYxBOZpUST84EpPq8k3tDE0sDEzAiY1CwNDZXEeUXXX4sQEkhPLEnNTk0tSC2C6WPi4JRq YMxL5OF65Dptdvikrcpxc7bmJL/J7ln5qvDx6/Dp88/suDLXIPXPQ+VYwe0L9Gs21O858Nte c79C3W0dMSPpRfmnLhptknYUDd5wMmvGPhWLn3I/Q37yz3ikLBR5u0Q5qeiYieUHrTVLph69 vGF/Zi4Pv/m6WIP51ftidi3Ju/4+Z44Eny13RY0SS3FGoqEWc1FxIgCxwetbuQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsVy+t9jQd29W95GGHS8ErFoeDGJ1WLTx/es FmeXHWSz+P/oNatF4zIRi8u75rBZHPnfz2jx6cF/Zos7T9azWizY+IjR4vjacIsl80MdeDyu XDzA6DG74SKLx51re9g8Ni+p9/g7az+Lx/Zr85g9Pm+SC2CPcrPJSE1MSS1SSM1Lzk/JzEu3 VQoNcdO1UFLIS8xNtVWK0PUNCVJSKEvMKQXyjAzQgINzgHuwkr5dglvG1hvuBb/lKx5/W8ba wPhAsouRk0NCwETi+/s/jBC2mMSFe+vZuhi5OIQEZjFK3Dl2gRHCecAo8XjVClaQKmEBd4nt fy6B2SICIRLvPq8Bs4UE+hglNl5LBWlgFljMJHH2zDYmkASbgI7E9m/HwWxeATuJkw/WsoDY LAKqEl8uTAbawMEhKhAm8bzRCaJEUOLH5HssIGFOAUuJH585QUxmAT2J+xe1QCqYBeQlNq95 yzyBEehIhIZZCFWzkFQtYGRexSiRWpBcUJyUnmuYl1quV5yYW1yal66XnJ+7iREcm8+kdjAe 3OV+iFGAg1GJh9fjzJsIIdbEsuLK3EOMEhzMSiK8dRveRgjxpiRWVqUW5ccXleakFh9iNAV6 YiKzlGhyPjBt5JXEG5qYm5gbG1iYW1qaGCmJ8zbOfhYuJJCeWJKanZpakFoE08fEwSnVwCj8 dMH6Sw86Ny4Wz9n3+dCXf4bF0mLHZRefL1hmsenCgtgo670nnws0MV9Zwz6Hr6CqyVlHav9L H+fHLbOXrfj3dq9n2R/vYLv4rAcHMyuu5/QGrFn+26HYwMPcrKpB8n1cl/PjSP8PPzQfTWBZ 5Lh7b9C89HkiZ34tOvXm+x2OLXMdtv+7UiysxFKckWioxVxUnAgAQshgjOMCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170412050149epcas1p3ccb6b2b21a4bcb8f4d8256d0e0645eac X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 X-Local-Sender: =?UTF-8?B?7KCV7J6s7ZuIG1RpemVuIFBsYXRmb3JtIExhYihTL1fshLw=?= =?UTF-8?B?7YSwKRvsgrzshLHsoITsnpAbU2VuaW9yIEVuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?SmFlaG9vbiBDaHVuZxtUaXplbiBQbGF0Zm9ybSBMYWIuG1Nh?= =?UTF-8?B?bXN1bmcgRWxlY3Ryb25pY3MbU2VuaW9yIEVuZ2luZWVy?= X-Sender-Code: =?UTF-8?B?QzEwG1NUQUYbQzEwVjgxMTE=?= CMS-TYPE: 101P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20170411225640epcas2p44720be993462ea13ae585bbb7e60315d X-RootMTR: 20170411225640epcas2p44720be993462ea13ae585bbb7e60315d References: <20170411225543.987-1-dianders@chromium.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3999 Lines: 90 On 04/12/2017 07:55 AM, Douglas Anderson wrote: > According to the SDIO standard interrupts are normally signalled in a > very complicated way. They require the card clock to be running and > require the controller to be paying close attention to the signals > coming from the card. This simply can't happen with the clock stopped > or with the controller in a low power mode. > > To that end, we'll disable runtime_pm when we detect that an SDIO card > was inserted. This is much like with what we do with the special > "SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports. > > NOTE: we specifically do this Runtime PM disabling at card init time > rather than in the enable_sdio_irq() callback. This is _different_ > than how SDHCI does it. Why do we do it differently? > > - Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA > dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD). > - Because we use the standard sdio_irq code: > - We see a constant stream of enable_sdio_irq(0) and > enable_sdio_irq(1) calls. This is because the standard code > disables interrupts while processing and re-enables them after. > - While interrupts are disabled, there's technically a period where > we could get runtime disabled while processing interrupts. > - If we are runtime disabled while processing interrupts, we'll > reset the controller at resume time (see dw_mci_runtime_resume), > which seems like a terrible idea because we could possibly have > another interrupt pending. > > To fix the above isues we'd want to put something in the standard > sdio_irq code that makes sure to call pm_runtime get/put when > interrupts are being actively being processed. That's possible to do, > but it seems like a more complicated mechanism when we really just > want the runtime pm disabled always for SDIO cards given that all the > other bits needed to get Runtime PM vs. SDIO just aren't there. > > NOTE: at some point in time someone might come up with a fancy way to > do SDIO interrupts and still allow (some) amount of runtime PM. > Technically we could turn off the card clock if we used an alternate > way of signaling SDIO interrupts (and out of band interrupt is one way > to do this). We probably wouldn't actually want to fully runtime > suspend in this case though--at least not with the current > dw_mci_runtime_resume() which basically fully resets the controller at > resume time. > > Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback") > Cc: > Reported-by: Brian Norris > Signed-off-by: Douglas Anderson Acked-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > drivers/mmc/host/dw_mmc.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 249ded65192e..e45129f48174 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1620,10 +1621,16 @@ static void dw_mci_init_card(struct mmc_host *mmc, struct mmc_card *card) > > if (card->type == MMC_TYPE_SDIO || > card->type == MMC_TYPE_SD_COMBO) { > - set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); > + if (!test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) { > + pm_runtime_get_noresume(mmc->parent); > + set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); > + } > clk_en_a = clk_en_a_old & ~clken_low_pwr; > } else { > - clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); > + if (test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) { > + pm_runtime_put_noidle(mmc->parent); > + clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags); > + } > clk_en_a = clk_en_a_old | clken_low_pwr; > } > >