From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Sibi Sankar <sibis@codeaurora.org>,
khilman@kernel.org, ulf.hansson@linaro.org, rjw@rjwysocki.net,
agross@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
gregkh@linuxfoundation.org, pavel@ucw.cz, len.brown@intel.com,
rnayak@codeaurora.org, dianders@chromium.org, mka@chromium.org
Subject: Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
Date: Mon, 24 Aug 2020 09:42:12 -0700 [thread overview]
Message-ID: <20200824164212.GA3715@yoga> (raw)
In-Reply-To: <159804608868.334488.2486130699850456264@swboyd.mtv.corp.google.com>
On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote:
> Quoting Sibi Sankar (2020-08-21 13:49:20)
> > Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the
> > status of the PM domain unaltered during suspend/resume respectively.
> > The flags are aimed at power domains coupled to co-processors which
> > enter low-power modes independent to that of the application processor.
> >
> > Specifically the flags are to be used by the power domains exposed
> > by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These
> > power domains are used to notify the Always on Subsystem (AOSS) that
> > a particular co-processor is up. AOSS uses this information to wait
> > for the co-processors to suspend before starting its sleep sequence.
> > The application processor powers off these power domains only if the
> > co-processor has crashed or powered off and remains unaltered during
> > system suspend/resume.
>
> Why are these power domains instead of some QMP message sent during
> remote proc power up?
The understanding I gained as I researched this, was that with this
property enabled resources related to the particular subsystem will be
kept enabled when the apss enters some power save mode. So my
interpretation was that it does "keep something powered".
> If this has been discussed before feel free to
> disregard and please link to prior mailing list discussions.
>
There where some discussions related to the "QDSS clk" in that series,
but I don't remember getting any feedback on modelling these things as
power-domains.
> I find it odd that this is modeled as a power domain instead of some
> Qualcomm specific message that the remoteproc driver sends to AOSS. Is
> there some sort of benefit the driver gets from using the power domain
> APIs for this vs. using a custom API?
We need to send "up" and "down" notifications and this needs to happen
at the same time as other standard resources are enabled/disabled.
Further more, at the time the all resources handled by the downstream
driver was either power-domains (per above understanding) or clocks, so
it made sense to me not to spin up a custom API.
Regards,
Bjorn
next prev parent reply other threads:[~2020-08-24 16:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 20:49 [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags Sibi Sankar
2020-08-21 20:49 ` [PATCH v2 2/2] soc: qcom: aoss: Use both " Sibi Sankar
2020-08-21 21:41 ` [PATCH v2 1/2] PM / Domains: Add " Stephen Boyd
2020-08-24 16:42 ` Bjorn Andersson [this message]
2020-08-25 7:20 ` Stephen Boyd
2020-08-25 16:37 ` Sibi Sankar
2020-08-25 17:53 ` Bjorn Andersson
2020-09-10 7:10 ` Sibi Sankar
2020-09-10 8:18 ` Ulf Hansson
2020-09-13 3:46 ` Bjorn Andersson
2020-08-24 11:11 ` Ulf Hansson
2020-09-21 16:18 ` Rafael J. Wysocki
[not found] ` <160071818317.4188128.15658877054019388462@swboyd.mtv.corp.google.com>
2020-09-22 4:51 ` Sibi Sankar
2020-09-22 7:31 ` Ulf Hansson
2020-09-22 15:35 ` Rafael J. Wysocki
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=20200824164212.GA3715@yoga \
--to=bjorn.andersson@linaro.org \
--cc=agross@kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=len.brown@intel.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mka@chromium.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=sibis@codeaurora.org \
--cc=swboyd@chromium.org \
--cc=ulf.hansson@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).