All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>,
	Brian Norris <briannorris@chromium.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	kevin@archlinuxarm.org, Alexandru Stan <amstan@chromium.org>,
	Ziyuan Xu <xzy.xu@rock-chips.com>,
	"# 4.0+" <stable@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: dw_mmc: Don't allow Runtime PM for SDIO cards
Date: Thu, 13 Apr 2017 08:05:52 -0700	[thread overview]
Message-ID: <CAD=FV=Udz1-9ptu8FdGJGZZw-T_pCF2nnm7AfB=GaA4-wzuKAQ@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFo4FMu0F5DwBNb4b5JTp5UwHAUBQdvk00J5zzvbk6OZSQ@mail.gmail.com>

Hi,

On Thu, Apr 13, 2017 at 2:32 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 12 April 2017 at 00:55, Douglas Anderson <dianders@chromium.org> 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.
>
> Right - unless we have a possibility to re-route the SDIO irq line to
> GPIO irq for wake-up when the controller enters low power state.

Yup.  Hence the "normally signalled".  ;)


>> 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.
>
> I wonder whether this is related to SDIO IRQs but not generic to SDIO.
>
> For example, when we have a WIFI chip with a dedicated and separate
> IRQ line, enabling SDMMC_CLKEN_LOW_PWR could make sense.

Yes, I believe this to be the case too.  It has always been on my TODO
list to see if I could figure out how to make this work, but it never
rose to the top.

One thing I wasn't sure about: is SDIO truly stateless enough that you
could fully power down the controller while you were waiting for an
interrupt?  I've never dug down that far into the protocol.

For certain, though, you wouldn't want to remove VMMC from an SDIO
card while waiting for an interrupt.  This contrasts to an SD or eMMC
memory card where you could plausibly do that if you're not actively
reading from or writing to the card (though I think some cards may do
background garbage collection, so maybe?? you could interfere with
that?)


>> 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.
>
> I understand this "quick" fix in dw_mmc takes care of the problem.
> However, allow me to try to make this a bit more generic. I intend to
> post something within a few days. If I fail, let's go with this
> solution.

Most certainly!  If you can come up with something better then I'd be happy!

-Doug

  reply	other threads:[~2017-04-13 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170411225640epcas2p44720be993462ea13ae585bbb7e60315d@epcas2p4.samsung.com>
2017-04-11 22:55 ` [PATCH] mmc: dw_mmc: Don't allow Runtime PM for SDIO cards Douglas Anderson
2017-04-12  5:01   ` Jaehoon Chung
2017-04-13  8:33   ` Shawn Lin
2017-04-13  9:32   ` Ulf Hansson
2017-04-13 15:05     ` Doug Anderson [this message]
2017-04-18 19:15   ` Ulf Hansson
2017-04-19 17:55     ` Brian Norris

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='CAD=FV=Udz1-9ptu8FdGJGZZw-T_pCF2nnm7AfB=GaA4-wzuKAQ@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=amstan@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=heiko@sntech.de \
    --cc=jh80.chung@samsung.com \
    --cc=kevin@archlinuxarm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=stable@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=xzy.xu@rock-chips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.