linux-omap.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@vger.kernel.org, linux-omap@vger.kernel.org,
	Yegor Yefremov <yegorslists@googlemail.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v2 1/1] mmc: sdhci-omap: Fix a lockdep warning for PM runtime init
Date: Tue, 12 Jul 2022 15:18:57 +0300	[thread overview]
Message-ID: <Ys1msXeqPipP7J5g@atomide.com> (raw)
In-Reply-To: <CAPDyKFqxSuuMtmfqwSojPqfHhv4RDLtRQf+JbOGZJkxVhDDAtQ@mail.gmail.com>

* Ulf Hansson <ulf.hansson@linaro.org> [220712 09:52]:
> On Mon, 27 Jun 2022 at 08:13, Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Ulf Hansson <ulf.hansson@linaro.org> [220623 12:55]:
> > > On Wed, 22 Jun 2022 at 07:12, Tony Lindgren <tony@atomide.com> wrote:
> > > >
> > > > We need runtime PM enabled early in probe before sdhci_setup_host() for
> > > > sdhci_omap_set_capabilities(). But on the first runtime resume we must
> > > > not call sdhci_runtime_resume_host() as sdhci_setup_host() has not been
> > > > called yet. Let's check for an initialized controller like we already do
> > > > for context restore to fix a lockdep warning.
> > >
> > > Thanks for explaining the background to the problem. However, looking
> > > a bit closer I am worried that the error path in ->probe() is broken
> > > too.
> > >
> > > It seems in the error path, at the label "err_rpm_put", there is a
> > > call to pm_runtime_put_autosuspend(). This doesn't really guarantee
> > > that the ->runtime_suspend() callback will be invoked, which I guess
> > > is the assumption, don't you think?
> >
> > OK I'll check and send a separate patch for that.
> >
> > > That said, I wonder if it would not be easier to convert the ->probe()
> > > function to make use of pm_runtime_get_noresume() and
> > > pm_runtime_set_active() instead. In this way the ->probe() function
> > > becomes responsible of turning on/off the resources "manually" that it
> > > requires to probe (and when it fails to probe), while we can keep the
> > > ->runtime_suspend|resume() callbacks simpler.
> > >
> > > Did that make sense to you?
> >
> > Simpler would be better :) We need to call pm_runtime_get_sync() at some
> > point though to enable the parent device hierarchy.
> 
> Is there a parent device that has runtime PM enabled?

Yes there is the interconnect target module device as the parent with
runtime PM enabled. So the sdhci-omap driver needs the parent enabled.

> In other cases, it should be fine to use pm_runtime_set_active()
> during ->probe().

Yup, this can't be done here though AFAIK. Something needs to enable
runtime PM for the parent device to have the sdhci registers accessible.

> > Just calling the
> > sdhci_omap runtime functions is not enough. And we still need to check
> > for the valid context too. Also I'm not convinced that calling
> > pm_runtime_get_sync() on the parent device would do the right thing on
> > old omap3 devices without bigger changes..
> 
> I certainly agree. The parent should not be managed directly by the
> sdhci driver.

OK

> One thing that can be discussed though, is whether
> pm_runtime_set_active() actually should runtime resume the parent,
> which would make the behaviour consistent with how suppliers are being
> treated.

Hmm yeah that's an interesting idea.

> > But maybe you have some better
> > ideas that I'm not considering.
> 
> I can try to draft a patch, if that would help? But, let's finalize
> the discussion above first (apologize for the delay).

OK. Should we apply the $subject patch to fix the splat meanwhile
though? Seems like what you're suggesting may take some more discussion
on the mailing lists.

Regrads,

Tony

  reply	other threads:[~2022-07-12 12:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22  5:12 [PATCH v2 1/1] mmc: sdhci-omap: Fix a lockdep warning for PM runtime init Tony Lindgren
2022-06-22  7:32 ` Adrian Hunter
2022-06-23 13:00 ` Ulf Hansson
2022-06-27  6:13   ` Tony Lindgren
2022-07-12  9:57     ` Ulf Hansson
2022-07-12 12:18       ` Tony Lindgren [this message]
2022-07-13 10:54         ` Ulf Hansson

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=Ys1msXeqPipP7J5g@atomide.com \
    --to=tony@atomide.com \
    --cc=adrian.hunter@intel.com \
    --cc=arnd@arndb.de \
    --cc=faiz_abbas@ti.com \
    --cc=kishon@ti.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=yegorslists@googlemail.com \
    --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).