From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Lina Iyer <lina.iyer@linaro.org>,
"khilman@linaro.org" <khilman@linaro.org>,
"sboyd@codeaurora.org" <sboyd@codeaurora.org>,
"galak@codeaurora.org" <galak@codeaurora.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"msivasub@codeaurora.org" <msivasub@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v14 03/10] qcom: spm: Add Subsystem Power Manager driver
Date: Wed, 17 Dec 2014 14:04:04 +0000 [thread overview]
Message-ID: <20141217140404.GB11998@red-moon> (raw)
In-Reply-To: <549181F0.3010408@linaro.org>
On Wed, Dec 17, 2014 at 01:15:28PM +0000, Daniel Lezcano wrote:
[...]
> > I would assume that the same can be done for most other platforms.
> >
> > There are probably cases where the same piece of hardware is responsible
> > for both cpuidle and cpufreq, but what that means is really that you
> > should have a single driver for it that does both things. Same for
> > SMP support: if you have one register block that does both the SMP
> > bringup and the cpuidle stuff, then have *one* driver for this block
> > that does it all. There are currently a few dependencies that require
> > doing SMP bringup early during boot, but we decided years ago that those
> > are all artificial dependencies and we should be able to boot secondary
> > CPUs much later than we currently do.
>
> I agree with this point and given the number of drivers, the easiest way
> to do that is to create cpu pm ops as I gave in the previous email and
> reuse them for cpu hotplug/bringup. And I believe that is possible if we
> continue our approach by splitting the low level pm code from the
> cpuidle driver.
>
> What about doing something simple ? Like creating a struct
> arm_cpu_pm_ops variable visible from everywhere and filled by the
> different platform ?
I agree with this approach, which by the way consists in defining
cpu operations as ARM64 does and use those from cpuidle, suspend and
hotplug code. The MCPM interface does that already, probably we should
enhance/rename it since people think it must be used for multicluster
power management whereas it is a pretty generic [drivers -> mach] code
interface (I am talking about the API, not the synchronization scheme),
and can certainly be extended/refactored according to new platforms need.
Thanks,
Lorenzo
next prev parent reply other threads:[~2014-12-17 14:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 17:39 [PATCH v14 00/10] cpuidle driver for QCOM SoCs: 8064, 8074, 8084 Lina Iyer
2014-12-02 17:39 ` [PATCH v14 01/10] qcom: scm: Move scm-boot files to drivers/soc/qcom/ and include/soc/qcom Lina Iyer
2014-12-02 17:39 ` [PATCH v14 02/10] qcom: scm: Add SCM warmboot support for quad core SoCs Lina Iyer
2014-12-02 17:39 ` [PATCH v14 03/10] qcom: spm: Add Subsystem Power Manager driver Lina Iyer
2014-12-02 23:05 ` Lina Iyer
2014-12-03 9:11 ` Daniel Lezcano
2014-12-03 14:31 ` Lina Iyer
2014-12-03 14:55 ` Lina Iyer
2014-12-03 20:35 ` Arnd Bergmann
2014-12-04 8:52 ` Daniel Lezcano
2014-12-04 9:01 ` Arnd Bergmann
2014-12-04 16:28 ` Lina Iyer
2014-12-04 18:20 ` Arnd Bergmann
2014-12-05 15:45 ` Lina Iyer
2014-12-16 14:39 ` Arnd Bergmann
2014-12-16 14:12 ` Daniel Lezcano
2014-12-16 14:38 ` Arnd Bergmann
2014-12-16 19:18 ` Stephen Boyd
2014-12-16 19:44 ` Arnd Bergmann
2014-12-17 15:22 ` Lina Iyer
2014-12-17 13:15 ` Daniel Lezcano
2014-12-17 14:04 ` Lorenzo Pieralisi [this message]
2014-12-02 17:39 ` [PATCH v14 04/10] arm: dts: qcom: Add power-controller device node for 8074 Krait CPUs Lina Iyer
2014-12-02 17:39 ` [PATCH v14 05/10] arm: dts: qcom: Add power-controller device node for 8084 " Lina Iyer
2014-12-02 17:39 ` [PATCH v14 06/10] arm: dts: qcom: Update power-controller device node for 8064 " Lina Iyer
2014-12-02 17:39 ` [PATCH v14 07/10] qcom: cpuidle: Add cpuidle driver for QCOM cpus Lina Iyer
2014-12-02 17:39 ` [PATCH v14 08/10] arm: dts: qcom: Add idle states device nodes for 8074 Lina Iyer
2014-12-02 17:39 ` [PATCH v14 09/10] arm: dts: qcom: Add idle states device nodes for 8084 Lina Iyer
2014-12-02 17:39 ` [PATCH v14 10/10] arm: dts: qcom: Add idle state device nodes for 8064 Lina Iyer
2014-12-17 18:14 ` [PATCH v14 00/10] cpuidle driver for QCOM SoCs: 8064, 8074, 8084 Kevin Hilman
2014-12-17 18:25 ` Lina Iyer
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=20141217140404.GB11998@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=arnd@arndb.de \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=khilman@linaro.org \
--cc=lina.iyer@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=msivasub@codeaurora.org \
--cc=sboyd@codeaurora.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).