lkml.org 
[lkml]   [2018]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v8 09/26] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs
    On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
    > On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
    > > [...]
    > >
    > >>>
    > >>> Assuming that I have got that right, there are concerns, mostly regarding
    > >>> patch [07/26], but I will reply to that directly.
    > >>
    > >> Well, I haven't got that right, so never mind.
    > >>
    > >> There are a few minor things to address, but apart from that the general
    > >> genpd patches look ready.
    > >
    > > Alright, thanks!
    > >
    > > I will re-spin the series and post a new version once 4.19 rc1 is out.
    > > Hopefully we can queue it up early in next cycle to get it tested in
    > > next for a while.
    > >
    > >>
    > >>> The $subject patch is fine by me by itself, but it obviously depends on the
    > >>> previous ones. Patches [01-02/26] are fine too, but they don't seem to be
    > >>> particularly useful without the rest of the series.
    > >>>
    > >>> As far as patches [10-26/26] go, I'd like to see some review comments and/or
    > >>> tags from the people with vested interest in there, in particular from Daniel
    > >>> on patch [12/26] and from Sudeep on the PSCI ones.
    > >>
    > >> But this still holds.
    > >
    > > Actually, patch 10 and patch11 is ready to go as well. I ping Daniel
    > > on patch 12.
    > >
    > > In regards to the rest of the series, some of the PSCI/ARM changes
    > > have been reviewed by Mark Rutland, however several changes have not
    > > been acked.
    > >
    > > On the other hand, one can also interpret the long silence in regards
    > > to PSCI/ARM changes as they are good to go. :-)
    >
    > Well, in that case giving an ACK to them should not be an issue for
    > the people with a vested interest I suppose.

    Apologies to everyone for the delay in replying.

    Side note: cpu_pm_enter()/exit() are also called through syscore ops in
    s2RAM/IDLE, you know that but I just wanted to mention it to compound
    the discussion.

    As for PSCI patches I do not personally think PSCI OSI enablement is
    beneficial (and my position has always been the same since PSCI OSI was
    added to the specification, I am not even talking about this patchset)
    and Arm Trusted Firmware does not currently support it for the same
    reason.

    We (if Mark and Sudeep agree) will enable PSCI OSI if and when we have a
    definitive and constructive answer to *why* we have to do that that is
    not a dogmatic "the kernel knows better" but rather a comprehensive
    power benchmark evaluation - I thought that was the agreement reached
    at OSPM but apparently I was mistaken.

    As a reminder - PSCI firmware implementation has to have state machines
    and locking to guarantee safe power down operations (and to flush caches
    only if necessary - which requires cpu masks for power domains) and
    that's true whether we enable PSCI OSI or not, the coordination logic
    must be in firmware/hardware _already_ - the cpumasks, the power domain
    topology, etc.

    I agree with the power-domains representation of idle-states (since
    that's the correct HW description) and I thought and hoped that runtime
    PM could help _remove_ the CPU PM notifiers (by making the notifiers
    callbacks a runtime PM one) even though I have to say that's quite
    complex, given that only few (ie one instance :)) CPU PM notifiers
    callbacks are backed by a struct device (eg an ARM PMU is a device but
    for instance the GIC is not a device so its save/restore code I am not
    sure it can be implemented with runtime PM callbacks).

    Lorenzo

    \
     
     \ /
      Last update: 2018-08-08 12:56    [W:3.461 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site