All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH] mmc: renesas_sdhi: don't lose RPM savings because of manual clk handling
Date: Sat, 16 May 2020 01:48:16 +0900	[thread overview]
Message-ID: <CAK7LNAR0THa--b7GDtip1JehiOZCiLWs1VygJfNo1_nSHEj1RA@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFpaaVdpv22VO_OS7a2rw67xmD7qXcxUqD_g5CDdqiZiHA@mail.gmail.com>

On Fri, May 15, 2020 at 6:26 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> + Niklas, Geert, Yamada-san,
>
>
> On Wed, 13 May 2020 at 19:31, Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> >
> > The SDHI driver en-/disabled clocks on its own during probe() and
> > remove(). This basically killed all potential RPM power savings. Now, we
> > just enable the clocks for a short time when we access registers in
> > probe(). We otherwise leave all handling to RPM. That means, we need to
> > shift the RPM enabling code in the TMIO core a bit up, so we can access
> > registers there, too.
>
> No, this doesn't sound entirely right to me.
>
> However, I do admit that we may need to move the pm_runtime
> initialization earlier (perhaps even out of tmio_mmc_core), but for
> slightly different reasons. Let me elaborate.
>
> For uniphier-sd, renesas_sdhi_sys_dmac and renesas_sdhi_internal_dmac
> - they all have assigned the ->clk_enable|disable() ops. Which means
> they have internal clock management (calling clk_prepare|enable()
> etc). For tmio_mmc, that's not the case.
>
> On top of this, the device may also have a potential PM domain
> attached. If that is the case, the PM domain may or may not have clock
> management implemented through genpd's ->start|stop() callbacks.
>
> So, in the end we are going to have to rely on clock enable/prepare
> reference counting, as we have to manage the clock(s) at both the
> driver and the PM domain level. Taking into account all various
> combinations (and that CONFIG_PM may not always be set). I have
> started to hack on some patches, but before I share them, let me ask a
> few questions.
>
> 1. tmio_mmc: - is that used solely with clock management through
> genpd? Or has no clock management at all?
> 2. uniphier-sd: Don't have runtime PM callbacks assigned. It looks
> like it doesn't care about runtime PM, but maybe it does through a PM
> domain? Can we skip to enable runtime PM for uniphier-sd, no?


Right, uniphier-sd does not care about runtime PM.
UniPhier SoCs do not have separate power domains.



-- 
Best Regards
Masahiro Yamada

  parent reply	other threads:[~2020-05-15 16:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 17:31 [PATCH] mmc: renesas_sdhi: don't lose RPM savings because of manual clk handling Wolfram Sang
2020-05-15  9:26 ` Ulf Hansson
2020-05-15 14:30   ` Niklas Söderlund
2020-05-15 16:48   ` Masahiro Yamada [this message]
2020-05-15 14:35 ` 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=CAK7LNAR0THa--b7GDtip1JehiOZCiLWs1VygJfNo1_nSHEj1RA@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.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.