linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Chunyan Zhang <zhang.chunyan@linaro.org>,
	Faiz Abbas <faiz_abbas@ti.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Rob Herring <robh@kernel.org>, DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH 4/5] mmc: sdhci-omap: Implement PM runtime functions
Date: Mon, 11 Oct 2021 08:23:42 +0300	[thread overview]
Message-ID: <YWPKXvPCTIir+TzG@atomide.com> (raw)
In-Reply-To: <CAPDyKFpybVPeYy-FsXnzDXNri+f7rhPmKa6vBF8NMUc3dQCZRw@mail.gmail.com>

* Ulf Hansson <ulf.hansson@linaro.org> [211008 14:44]:
> On Thu, 30 Sept 2021 at 08:57, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Implement PM runtime functions and enable MMC_CAP_AGGRESSIVE_PM.
> 
> I suggest you split this change into two pieces. MMC_CAP_AGGRESSIVE_PM
> is about enabling runtime PM management for the eMMC/SD card device,
> which is perfectly fine to use independently of whether runtime PM is
> supported for the host device.

OK

> > @@ -1350,6 +1357,11 @@ static int sdhci_omap_probe(struct platform_device *pdev)
> >         if (ret)
> >                 goto err_cleanup_host;
> >
> > +       sdhci_omap_context_save(omap_host);
> > +       omap_host->context_valid = 1;
> 
> Looks like you can remove this flag, it's not being used.

Hmm I think it is needed as otherwise we end up trying to restore
an invalid context on probe on the first pm_runtime_get(). Do you
have some nicer solution for that in mind?

> > +
> > +       pm_runtime_put_sync(dev);
> 
> I recommend to use the PM runtime autosuspend feature, as to avoid an
> initial latency for every I/O request to the host driver. The mmc core
> already supports that, see mmc_release_host().
> 
> The typical default timeout value for autosuspend, is usually set
> ~50-200ms, by host drivers (if I recall correctly).

OK I have a patch to also enable autosuspend too, I'll add that
too for the next revision.

> > @@ -1371,6 +1383,7 @@ static int sdhci_omap_remove(struct platform_device *pdev)
> >         struct device *dev = &pdev->dev;
> >         struct sdhci_host *host = platform_get_drvdata(pdev);
> >
> > +       pm_runtime_get_sync(dev);
> >         sdhci_remove_host(host, true);
> >         pm_runtime_put_sync(dev);
> 
> There is no guarantee that this triggers a call to
> ->sdhci_omap_runtime_suspend(), which I guess is what we want.
> Userspace via sysfs may have increase the RPM usage count
> (pm_runtime_forbid(), for example.
> 
> To address this, I would call pm_runtime_disable() first and then
> explicitly put the device into low power state, rather than relying on
> runtime PM to do it. Another option could be to use
> pm_runtime_force_suspend().

OK I'll take a look.

> > @@ -1402,42 +1415,75 @@ static void sdhci_omap_context_restore(struct sdhci_omap_host *omap_host)
> >         sdhci_omap_writel(omap_host, SDHCI_OMAP_ISE, omap_host->ise);
> >  }
> >
> > -static int __maybe_unused sdhci_omap_suspend(struct device *dev)
> > +static int __maybe_unused sdhci_omap_runtime_suspend(struct device *dev)
> >  {
> >         struct sdhci_host *host = dev_get_drvdata(dev);
> >         struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> >         struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> >
> > -       sdhci_suspend_host(host);
> > -
> 
> Shouldn't you call sdhci_runtime_suspend_host() somewhere here?

I'm pretty sure I tried, but runtime resume did not seem to work after
doing that.. I'll take a look again.

> > +static int __maybe_unused sdhci_omap_suspend(struct device *dev)
> > +{
> > +       struct sdhci_host *host = dev_get_drvdata(dev);
> > +       struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > +       struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> > +
> > +       if (omap_host->is_runtime_suspended)
> > +               return 0;
> 
> So if the host is already runtime suspended, it's okay to just leave it as is?

Ideally yeah there should not be anything left to do for suspesnd at
that point. But sounds like I may be missing something.

> In a way that sounds like you could call pm_runtime_force_suspend()
> instead, assuming the sdhci_omap_runtime_suspend() can be extended to
> do the right thing for system suspend as well.

OK I'll check.

> It looks a bit odd that sdhci_suspend_host() is called only when the
> host is runtime resumed. Perhaps you can elaborate a bit more on why
> this is, so I can understand better what you want to achieve here.

I guess I'm not clear on what's left for sdhci_suspend_host() to do if
the host is already runtime suspended :)

Regards,

Tony

  reply	other threads:[~2021-10-11  5:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  6:57 [PATCHv2 0/5] More SoCs for sdhci-omap to deprecate omap_hsmmc Tony Lindgren
2021-09-30  6:57 ` [PATCH 1/5] dt-bindings: sdhci-omap: Update binding for legacy SoCs Tony Lindgren
2021-10-02 13:29   ` Adam Ford
2021-10-05  8:04     ` Tony Lindgren
2021-10-05 10:45       ` Adam Ford
2021-10-06  5:03         ` Tony Lindgren
2021-10-02 16:15   ` Adam Ford
2021-09-30  6:57 ` [PATCH 2/5] mmc: sdhci-omap: Handle voltages to add support omap4 Tony Lindgren
2021-09-30  6:57 ` [PATCH 3/5] mmc: sdhci-omap: Add omap_offset to support omap3 and earlier Tony Lindgren
2021-09-30  6:57 ` [PATCH 4/5] mmc: sdhci-omap: Implement PM runtime functions Tony Lindgren
2021-10-08 14:43   ` Ulf Hansson
2021-10-11  5:23     ` Tony Lindgren [this message]
2021-10-12  9:05       ` Ulf Hansson
2021-10-12  9:18         ` Tony Lindgren
2021-09-30  6:57 ` [PATCH 5/5] mmc: sdhci-omap: Configure optional wakeirq Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2021-09-21 11:15 [PATCH 0/5] More SoCs for sdhci-omap to deprecate omap_hsmmc Tony Lindgren
2021-09-21 11:15 ` [PATCH 4/5] mmc: sdhci-omap: Implement PM runtime functions Tony Lindgren

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=YWPKXvPCTIir+TzG@atomide.com \
    --to=tony@atomide.com \
    --cc=adrian.hunter@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=faiz_abbas@ti.com \
    --cc=kishon@ti.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=zhang.chunyan@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).