All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Linux MMC List <linux-mmc@vger.kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Ulrich Hecht <uli+renesas@fpond.eu>,
	Simon Horman <horms+renesas@verge.net.au>,
	Niklas Soderlund <niklas.soderlund@ragnatech.se>,
	Geert Uytterhoeven <geert+renesas@glider.be>
Subject: Re: [PATCH 2/2] mmc: tmio: Make sure the PM domain is 'started' while probing
Date: Wed, 20 May 2020 17:57:00 +0200	[thread overview]
Message-ID: <CAMuHMdXc8jzLoKbb_heX-Ftb+3RNOQRtEX=7NS4KxWdxUfBcwA@mail.gmail.com> (raw)
In-Reply-To: <20200519152445.6922-1-ulf.hansson@linaro.org>

Hi Ulf,

On Tue, May 19, 2020 at 5:24 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> If the tmio device is attached to a genpd (PM domain), that genpd may have
> ->start|stop() callback assigned to it. To make sure the device is
> accessible during ->probe(), genpd's ->start() callback must be invoked,
> which is currently managed by tmio_mmc_host_probe(). However, it's likely
> that may be too late for some cases, as registers may be read and written
> way before that point.
>
> To fix the behaviour, let's move the call to dev_pm_domain_start() from
> tmio_mmc_host_probe() into those clients that needs it. From discussions at
> linux-mmc mailing list, it turned out that it should be sufficient to do
> this for the SDHI renesas variants, hence the call is move to
> renesas_sdhi_probe().
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>  drivers/mmc/host/renesas_sdhi_core.c | 3 +++
>  drivers/mmc/host/tmio_mmc_core.c     | 2 --
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
> index ff72b381a6b3..dcba9ad35dd1 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -24,6 +24,7 @@
>  #include <linux/module.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
>  #include <linux/mmc/host.h>
>  #include <linux/mmc/slot-gpio.h>
>  #include <linux/mfd/tmio.h>
> @@ -905,6 +906,8 @@ int renesas_sdhi_probe(struct platform_device *pdev,
>         /* All SDHI have SDIO status bits which must be 1 */
>         mmc_data->flags |= TMIO_MMC_SDIO_STATUS_SETBITS;
>
> +       dev_pm_domain_start(&pdev->dev);
> +


I have debug prints at the top of genpd_stop_dev():

    pr_info("==== %s/%s: stop\n", genpd->name, dev_name(dev));

and genpd_start_dev():

    pr_info("==== %s/%s: start\n", genpd->name, dev_name(dev));

On Koelsch (R-Car M2-W), the three SDHI devices are started twice:

    PM: ==== always-on/ee100000.sd: start
    PM: ==== always-on/ee140000.sd: start
    PM: ==== always-on/ee160000.sd: start
    PM: ==== always-on/ee100000.sd: start
    PM: ==== always-on/ee140000.sd: start
    PM: ==== always-on/ee160000.sd: start

The first time, the probe is deferred, because the regulator needed in
tmio_mmc_init_ocr() hasn't been instantiated yet. The SDHI device is
detached from the PM domain, but not stopped.
Interestingly, I see no clock imbalances afterwards.

On R-Car Gen3, R-Mobile A1, and RZ/A systems, they are started once,
as expected.

On R-Mobile APE6 and SH-Mobile AG5, one device is stopped and started
again:

    PM: ==== a3sp/ee100000.sd: start
    PM: ==== a3sp/ee120000.sd: start
    PM: ==== a3sp/ee120000.sd: stop
    PM: ==== a3sp/ee120000.sd: start

But here no probe deferral is involved.
Just Runtime PM kicking in, I guess.

>         ret = renesas_sdhi_clk_enable(host);
>         if (ret)
>                 goto efree;
> diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
> index ba301fb7656b..d7fde57c78c1 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -39,7 +39,6 @@
>  #include <linux/module.h>
>  #include <linux/pagemap.h>
>  #include <linux/platform_device.h>
> -#include <linux/pm_domain.h>
>  #include <linux/pm_qos.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/regulator/consumer.h>
> @@ -1192,7 +1191,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host)
>         /* See if we also get DMA */
>         tmio_mmc_request_dma(_host, pdata);
>
> -       dev_pm_domain_start(&pdev->dev);

Before, the issue on probe deferral didn't happen, as the device was only
started after the regulator was found.

>         pm_runtime_get_noresume(&pdev->dev);
>         pm_runtime_set_active(&pdev->dev);
>         pm_runtime_set_autosuspend_delay(&pdev->dev, 50);

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  parent reply	other threads:[~2020-05-20 15:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 15:24 [PATCH 2/2] mmc: tmio: Make sure the PM domain is 'started' while probing Ulf Hansson
2020-05-19 16:38 ` Wolfram Sang
2020-05-20 11:35   ` Ulf Hansson
2020-05-20 15:57 ` Geert Uytterhoeven [this message]
2020-05-20 16:11   ` Ulf Hansson
2020-05-20 17:42     ` Geert Uytterhoeven
2020-05-25  8:47       ` Ulf Hansson
2020-05-25 10:04         ` Wolfram Sang
  -- strict thread matches above, loose matches on Subject: below --
2020-05-15 14:04 Ulf Hansson
2020-05-18 20:22 ` Wolfram Sang
2020-05-19  7:50   ` Ulf Hansson
2020-05-19  8:46     ` Wolfram Sang
2020-05-19  8:53       ` Geert Uytterhoeven
2020-05-19  9:09         ` Wolfram Sang
2020-05-19  9:15         ` Ulf Hansson
2020-05-19  9:21           ` Ulf Hansson
2020-05-19 11:32             ` Wolfram Sang
2020-05-19 11:35           ` Wolfram Sang
2020-05-19 13:54             ` Ulf Hansson
2020-05-18 21:07 ` Geert Uytterhoeven
2020-05-19  8:18   ` Ulf Hansson
2020-05-19  8:29     ` Geert Uytterhoeven

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='CAMuHMdXc8jzLoKbb_heX-Ftb+3RNOQRtEX=7NS4KxWdxUfBcwA@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=geert+renesas@glider.be \
    --cc=horms+renesas@verge.net.au \
    --cc=linux-mmc@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=ulf.hansson@linaro.org \
    --cc=uli+renesas@fpond.eu \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=yamada.masahiro@socionext.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.