mbox series

[v9,00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

Message ID 20181003143824.13059-1-ulf.hansson@linaro.org
Headers show
Series PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset) | expand

Message

Ulf Hansson Oct. 3, 2018, 2:38 p.m. UTC
I have digested the review comments so far, including a recent offlist chat
with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
have a plan for how to move forward.

However, to avoid re-posting non-changed patches over and over again, I decided
to withhold the more debatable part from this v9, hence this is not the complete
series to make things play. In v9, I have just included the trivial changes,
which are either already acked/reviewed or hopefully can be rather soon/easily.

My hope is to get this queued for v4.20, to move things forward. I know it's
late, but there are more or less nothing new here since v8.

Kind regards
Ulf Hansson

Changes in v9:
 - Collect only a subset from the changes in v8.
 - Patch 3 is new, documenting existing genpd flags. Future wise, this means
when a new genpd flag is invented, we must also properly document it.
 - No changes have been made to the patches picked from v8.
 - Dropped the text from v8 cover-letter[1], to avoid confusion. When posting v10
(or whatever the next version containing the rest becomes), I am going re-write
the cover-letter to clarify, more exactly, the problems this series intends to
solve. The earlier text was simply too vague.

[1]
https://lwn.net/Articles/758091/

Changes in v8:
 - Added some tags for reviews and acks.
 - Cleanup timer patch (patch6) according to comments from Rafael.
 - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5.
 - While adopting patch 5 to new genpd changes, I took the opportunity to
   improve the new function description a bit.
 - Corrected malformed SPDX-License-Identifier in patch20.

Changes in v7:
 - Addressed comments concerning the PSCI changes from Mark Rutland, which moves
   the psci firmware driver to a new firmware subdir and change to force PSCI PC
   mode during boot to cope with kexec'ed booted kernels.
 - Added some maintainers in cc for the timer/nohz patches.
 - Minor update to the new genpd governor, taking into account the state's
   poweroff latency while validating the sleep duration time.
 - Addressed a problem pointed out by Geert Uytterhoeven, around calling
   pm_runtime_get|put() for CPUs that has not been attached to a CPU PM domain.
 - Re-based on Linus' latest master.


Lina Iyer (3):
  dt: psci: Update DT bindings to support hierarchical PSCI states
  cpuidle: dt: Support hierarchical CPU idle states
  drivers: firmware: psci: Support hierarchical CPU idle states

Ulf Hansson (8):
  PM / Domains: Don't treat zero found compatible idle states as an
    error
  PM / Domains: Deal with multiple states but no governor in genpd
  PM / Domains: Document flags for genpd
  of: base: Add of_get_cpu_state_node() to get idle states for a CPU
    node
  drivers: firmware: psci: Move psci to separate directory
  MAINTAINERS: Update files for PSCI
  drivers: firmware: psci: Split psci_dt_cpu_init_idle()
  drivers: firmware: psci: Simplify error path of psci_dt_init()

 .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
 MAINTAINERS                                   |   2 +-
 drivers/base/power/domain.c                   |  20 ++-
 drivers/cpuidle/dt_idle_states.c              |   5 +-
 drivers/firmware/Kconfig                      |  15 +-
 drivers/firmware/Makefile                     |   3 +-
 drivers/firmware/psci/Kconfig                 |  13 ++
 drivers/firmware/psci/Makefile                |   4 +
 drivers/firmware/{ => psci}/psci.c            |  70 ++++----
 drivers/firmware/{ => psci}/psci_checker.c    |   0
 drivers/of/base.c                             |  35 ++++
 include/linux/of.h                            |   8 +
 include/linux/pm_domain.h                     |  35 +++-
 13 files changed, 302 insertions(+), 64 deletions(-)
 create mode 100644 drivers/firmware/psci/Kconfig
 create mode 100644 drivers/firmware/psci/Makefile
 rename drivers/firmware/{ => psci}/psci.c (95%)
 rename drivers/firmware/{ => psci}/psci_checker.c (100%)

-- 
2.17.1

Comments

Rafael J. Wysocki Oct. 4, 2018, 8:39 a.m. UTC | #1
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>

> I have digested the review comments so far, including a recent offlist chat

> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I

> have a plan for how to move forward.

>

> However, to avoid re-posting non-changed patches over and over again, I decided

> to withhold the more debatable part from this v9, hence this is not the complete

> series to make things play. In v9, I have just included the trivial changes,

> which are either already acked/reviewed or hopefully can be rather soon/easily.

>

> My hope is to get this queued for v4.20, to move things forward. I know it's

> late, but there are more or less nothing new here since v8.


I have no problems with the first three patches in this series, so I
can apply them right away.  Do you want me to do that?

As for the rest, the cpuidle driver patch looks OK to me, but the
PSCI-related ones need ACKs.

Thanks,
Rafael
Lorenzo Pieralisi Oct. 4, 2018, 5:21 p.m. UTC | #2
On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:

[...]

> > > I don't see any dependency there, so I'll queue up the 1-3 in

> > > pm-domains and the 4-6 in pm-cpuidle.

> >

> > I do not see why we should merge patches 4-6 for v4.20; they add legacy

> > (DT bindings and related parsing code) with no user in the kernel; we

> > may still want to tweak them, in particular PSCI DT bindings.

> 

> My impression was that 4-6 have been agreed on due to the ACKs they

> carry.  I'll drop them if that's not the case.


I have not expressed myself correctly: they have been agreed (even
though as I said they may require some tweaking) but I see no urgency
of merging them in v4.20 since they have no user. They contain DT
bindings, that create ABI/legacy, I think it is better to have code
that uses them in the kernel before merging them and creating a
dependency that is not needed.

> > Likewise, it makes no sense to merge patches 7-8 without the rest of

> > the PSCI patches.

> 

> OK

> 

> I'll let the ARM camp sort out the PSCI material then.


We will do.

Thanks,
Lorenzo
Ulf Hansson Oct. 5, 2018, 11:49 a.m. UTC | #3
On 5 October 2018 at 12:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Oct 04, 2018 at 08:36:24PM +0200, Ulf Hansson wrote:

>> On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:

>> > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:

>> >

>> > [...]

>> >

>> >> > > I don't see any dependency there, so I'll queue up the 1-3 in

>> >> > > pm-domains and the 4-6 in pm-cpuidle.

>> >> >

>> >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy

>> >> > (DT bindings and related parsing code) with no user in the kernel; we

>> >> > may still want to tweak them, in particular PSCI DT bindings.

>> >>

>> >> My impression was that 4-6 have been agreed on due to the ACKs they

>> >> carry.  I'll drop them if that's not the case.

>> >

>> > I have not expressed myself correctly: they have been agreed (even

>> > though as I said they may require some tweaking) but I see no urgency

>> > of merging them in v4.20 since they have no user. They contain DT

>> > bindings, that create ABI/legacy, I think it is better to have code

>> > that uses them in the kernel before merging them and creating a

>> > dependency that is not needed.

>>

>> There is already code using the new bindings, for the idle states.

>> Please have look at patch 5, 6 and 11.

>

> I had a look before replying and I reiterate the point, there is

> no reason to merge those patches without the rest of the series,

> none. There is already a way to describe idle states in the kernel

> and it works very well, we will add one when we need it not before.


Okay, let's defer them.

>

>> Moreover, you have had plenty on time to look at the series, as those

>> patches haven't changed since a very long time.

>

> So ?

>

>> May I suggest you do the review instead, so we can move things

>> forward, please. The changes in the v9 series should be trivial to

>> review.

>

> There is no reason to merge patches [4, 5, 6, 10] stand-alone, they

> are not solving any problem and they do not provide any benefit

> other than adding useless ABI/legacy, they make sense when we look

> at the whole series.


Okay, let's defer them.

>

>> >> > Likewise, it makes no sense to merge patches 7-8 without the rest of

>> >> > the PSCI patches.

>>

>> Well, those patches are part of this series, because Mark wanted me to

>> move the files. Is really such a big deal? I think it makes sense, no

>> matter what happens afterwards.

>

> We can merge patches [7-8] even if there is no urgency at all to do so,

> usually PSCI patches go via arm-soc whose patches queue is now closed

> and I do not think that's a problem at all.


Okay, let's defer them.

That said, can please review the patches?

Kind regards
Uffe