From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Andy Gross <andy.gross@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
stanimir.varbanov@linaro.org
Subject: Re: [PATCH 3/5] arm64: dts: msm8916: Add spc compat tag
Date: Fri, 10 Jun 2016 21:59:48 +0100 [thread overview]
Message-ID: <20160610205948.GD24178@red-moon> (raw)
In-Reply-To: <20160610172716.GR13357@hector.attlocal.net>
On Fri, Jun 10, 2016 at 12:27:16PM -0500, Andy Gross wrote:
> On Fri, Jun 10, 2016 at 06:06:56PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:
> >
> > [...]
> >
> > > > (1) enter_freeze() hooks are not strictly necessary to enable
> > > > suspend-to-idle (they are if we want the tick to be frozen
> > > > on suspend-to-idle, which is different)
> > >
> > > I'd think that you'd want the tick frozen. Even if you are going to
> > > just call the deepest freezable idle state in your freeze_function,
> > > you don't want to keep getting woken up as this costs some power usage
> >
> > As I said, that's a separate issue from these bindings.
>
> I kind of see that coupled with the determination that a idle state
> supports freeze. Or are you wanting to have something else that
> decides whether or not to configure the enter_freeze?
All PSCI based idle state support freeze, as long as most of the
other idle routines for ARM 32-bit, I do not even think we should
bother with defining DT bindings for it.
[...]
> > For 64-bit you do not have to have add any facility.
> >
> > 1) we should change core code to make PM_SUSPEND_FREEZE independent
> > of suspend_set_ops()
>
> So then, if cpuidle is active and you have idle states supporting
> freeze, then you can always implicitly freeze the system. This would
> infer then that the system will always indicate it can do freeze. I
> am good with that.
>
> For now, we can get away with just implementing the changes you are
> suggesting.
Cracking.
> > 2) we should define which idle states are freezable (99% of them are
> > minus coupled idle states), through generic bindings
>
> This would be in the form of a DT property? And given this property
> then we'd just assign a enter_freeze() function that calls the enter()
> for that state. Or would we have something else that we need to key
> off of to decide to configure the enter_freeze?
See above, I will give it more thought. I take an action to change
core code as per discussion above.
Thanks for raising the point.
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] arm64: dts: msm8916: Add spc compat tag
Date: Fri, 10 Jun 2016 21:59:48 +0100 [thread overview]
Message-ID: <20160610205948.GD24178@red-moon> (raw)
In-Reply-To: <20160610172716.GR13357@hector.attlocal.net>
On Fri, Jun 10, 2016 at 12:27:16PM -0500, Andy Gross wrote:
> On Fri, Jun 10, 2016 at 06:06:56PM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:
> >
> > [...]
> >
> > > > (1) enter_freeze() hooks are not strictly necessary to enable
> > > > suspend-to-idle (they are if we want the tick to be frozen
> > > > on suspend-to-idle, which is different)
> > >
> > > I'd think that you'd want the tick frozen. Even if you are going to
> > > just call the deepest freezable idle state in your freeze_function,
> > > you don't want to keep getting woken up as this costs some power usage
> >
> > As I said, that's a separate issue from these bindings.
>
> I kind of see that coupled with the determination that a idle state
> supports freeze. Or are you wanting to have something else that
> decides whether or not to configure the enter_freeze?
All PSCI based idle state support freeze, as long as most of the
other idle routines for ARM 32-bit, I do not even think we should
bother with defining DT bindings for it.
[...]
> > For 64-bit you do not have to have add any facility.
> >
> > 1) we should change core code to make PM_SUSPEND_FREEZE independent
> > of suspend_set_ops()
>
> So then, if cpuidle is active and you have idle states supporting
> freeze, then you can always implicitly freeze the system. This would
> infer then that the system will always indicate it can do freeze. I
> am good with that.
>
> For now, we can get away with just implementing the changes you are
> suggesting.
Cracking.
> > 2) we should define which idle states are freezable (99% of them are
> > minus coupled idle states), through generic bindings
>
> This would be in the form of a DT property? And given this property
> then we'd just assign a enter_freeze() function that calls the enter()
> for that state. Or would we have something else that we need to key
> off of to decide to configure the enter_freeze?
See above, I will give it more thought. I take an action to change
core code as per discussion above.
Thanks for raising the point.
Lorenzo
next prev parent reply other threads:[~2016-06-10 20:59 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 5:00 [PATCH 0/5] Qualcomm Suspend to Idle Support Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-05-19 5:00 ` [PATCH 1/5] soc: qcom: Add suspend to idle support Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-06-09 7:39 ` Ulf Hansson
2016-06-09 7:39 ` Ulf Hansson
2016-06-09 18:09 ` Andy Gross
2016-06-09 18:09 ` Andy Gross
2016-06-10 8:47 ` Ulf Hansson
2016-06-10 8:47 ` Ulf Hansson
2016-06-10 15:26 ` Andy Gross
2016-06-10 15:26 ` Andy Gross
2016-06-13 16:12 ` Daniel Lezcano
2016-06-13 16:12 ` Daniel Lezcano
2016-05-19 5:00 ` [PATCH 2/5] arm: defconfig: Enable PM8941 pwr key Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-06-10 20:25 ` Bjorn Andersson
2016-06-10 20:25 ` Bjorn Andersson
2016-05-19 5:00 ` [PATCH 3/5] arm64: dts: msm8916: Add spc compat tag Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-05-19 19:52 ` Stanimir Varbanov
2016-05-19 19:52 ` Stanimir Varbanov
2016-05-19 20:16 ` Andy Gross
2016-05-19 20:16 ` Andy Gross
2016-06-10 15:48 ` Mark Rutland
2016-06-10 15:48 ` Mark Rutland
2016-06-10 16:12 ` Andy Gross
2016-06-10 16:12 ` Andy Gross
2016-06-10 16:25 ` Mark Rutland
2016-06-10 16:25 ` Mark Rutland
2016-06-10 16:47 ` Andy Gross
2016-06-10 16:47 ` Andy Gross
2016-06-10 21:16 ` Lina Iyer
2016-06-10 21:16 ` Lina Iyer
2016-06-10 21:52 ` Andy Gross
2016-06-10 21:52 ` Andy Gross
2016-06-13 11:00 ` Mark Rutland
2016-06-13 11:00 ` Mark Rutland
2016-06-13 13:48 ` Lorenzo Pieralisi
2016-06-13 13:48 ` Lorenzo Pieralisi
2016-06-16 8:12 ` Andy Gross
2016-06-16 8:12 ` Andy Gross
2016-06-10 16:31 ` Lorenzo Pieralisi
2016-06-10 16:31 ` Lorenzo Pieralisi
2016-06-10 16:52 ` Andy Gross
2016-06-10 16:52 ` Andy Gross
2016-06-10 17:06 ` Lorenzo Pieralisi
2016-06-10 17:06 ` Lorenzo Pieralisi
2016-06-10 17:27 ` Andy Gross
2016-06-10 17:27 ` Andy Gross
2016-06-10 20:59 ` Lorenzo Pieralisi [this message]
2016-06-10 20:59 ` Lorenzo Pieralisi
2016-05-19 5:00 ` [PATCH 4/5] ARM: dts: qcom: Remove size elements from pmic reg Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-06-10 20:26 ` Bjorn Andersson
2016-06-10 20:26 ` Bjorn Andersson
2016-05-19 5:00 ` [PATCH 5/5] ARM: dts: qcom: pma8084: Add pwrkey entry Andy Gross
2016-05-19 5:00 ` Andy Gross
2016-06-10 20:29 ` Bjorn Andersson
2016-06-10 20:29 ` Bjorn Andersson
2016-05-20 6:09 ` [PATCH 0/5] Qualcomm Suspend to Idle Support Pramod Gurav
2016-05-20 6:09 ` Pramod Gurav
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=20160610205948.GD24178@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=andy.gross@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=stanimir.varbanov@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 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.