From: Sibi Sankar <firstname.lastname@example.org> To: Ulf Hansson <email@example.com> Cc: Bjorn Andersson <firstname.lastname@example.org>, "Rafael J. Wysocki" <email@example.com>, Andy Gross <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, linux-arm-msm <firstname.lastname@example.org>, Linux PM <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Pavel Machek <email@example.com>, Len Brown <firstname.lastname@example.org>, Rajendra Nayak <email@example.com>, Doug Anderson <firstname.lastname@example.org>, email@example.com, Kevin Hilman <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag Date: Mon, 17 Aug 2020 22:19:20 +0530 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAPDyKFrqxRrWSX5VaMy4DSjFNaMikKBYsZy5NiPMJvUybYttsw@mail.gmail.com> On 2020-08-17 14:14, Ulf Hansson wrote: > On Thu, 13 Aug 2020 at 19:26, Sibi Sankar <email@example.com> wrote: >> >> On 2020-08-13 18:04, Ulf Hansson wrote: >> > On Wed, 12 Aug 2020 at 19:03, Sibi Sankar <firstname.lastname@example.org> wrote: >> >> >> >> Uffe, >> >> Thanks for taking time to review the >> >> series! >> >> >> >> On 2020-08-12 15:15, Ulf Hansson wrote: >> >> > On Tue, 11 Aug 2020 at 21:03, Sibi Sankar <email@example.com> wrote: >> >> >> >> >> >> This is for power domains which needs to stay powered on for suspend >> >> >> but can be powered on/off as part of runtime PM. This flag is aimed at >> >> >> power domains coupled to remote processors which enter suspend states >> >> >> independent to that of the application processor. Such power domains >> >> >> are turned off only on remote processor crash/shutdown. >> >> > >> >> > As Kevin also requested, please elaborate more on the use case. >> >> > >> >> > Why exactly must the PM domain stay powered on during system suspend? >> >> > Is there a wakeup configured that needs to be managed - or is there a >> >> > co-processor/FW behaviour that needs to be obeyed to? >> >> >> >> Yes this is a co-processor behavior that >> >> needs to be obeyed. Specifically application >> >> processor notifies the Always on Subsystem >> >> (AOSS) that a particular co-processor is up >> >> using the power domains exposed by AOSS QMP >> >> driver. 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. >> > >> > Thanks for clarifying! >> > >> > Although, can you please elaborate a bit more on the actual use case? >> > What are the typical co-processor and what drivers are involved in >> > managing it? >> >> The co-processors using the power domains >> exposed by qcom_aoss driver are modem, >> audio dsp, compute dsp managed using >> qcom_q6v5_mss and qcom_q6v5_pas driver. >> >> > >> > As you may know, runtime PM becomes disabled during system suspend of >> > a device. Which means, if the driver tries to power off the >> > coprocessor (via calling pm_runtime_put() for example), somewhere in >> > the system suspend phase of the corresponding device, its attached PM >> > domain stays powered on when managed by genpd. >> >> The drivers aren't really expected >> do anything during suspend/resume >> pretty much because the co-processors >> enter low-power modes independent to >> that of the application processor. On >> co-processor crash the remoteproc core >> does a pm_stay_awake followed by a >> pm_relax after crash recovery. > > Okay, thanks again for clarifying. You have convinced me about the > need for a new flag to cope with these use cases. > > Would you mind updating the commit message with some of the > information you just provided? > > Additionally, to make it clear that the flag should be used to keep > the PM domain powered on during system suspend, but only if it's > already powered on - please rename the flag to GENPD_FLAG_NO_SUSPEND, > and update the corresponding description of it in the header file. Thanks, naming it ^^ makes more sense :) https://firstname.lastname@example.org/ Also we wouldn't want to power on runtime suspended power domains with the NO_SUSPEND flag set, on resume as explained ^^. Do you agree with that as well? > > [...] > > Kind regards > Uffe -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply index Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-11 19:02 Sibi Sankar 2020-08-11 19:02 ` [PATCH 2/2] soc: qcom: aoss: Use " Sibi Sankar 2020-08-11 21:16 ` Doug Anderson 2020-08-11 21:17 ` [PATCH 1/2] PM / Domains: Add " Doug Anderson 2020-08-11 21:38 ` Stephen Boyd 2020-08-12 13:36 ` Sibi Sankar 2020-08-12 0:19 ` Kevin Hilman 2020-08-12 16:12 ` Sibi Sankar 2020-08-12 9:45 ` Ulf Hansson 2020-08-12 17:02 ` Sibi Sankar 2020-08-13 12:34 ` Ulf Hansson 2020-08-13 17:26 ` Sibi Sankar 2020-08-17 8:44 ` Ulf Hansson 2020-08-17 16:49 ` Sibi Sankar [this message] 2020-08-18 8:31 ` Ulf Hansson 2020-08-18 9:03 ` Sibi Sankar
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git