On Wed, Aug 08, 2018 at 12:02:48PM -0600, Lina Iyer wrote: > On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote: > >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@xxxxxxxxxx> 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. > > > I will not speak to any comparison of benchmarks between OSI and PC. > AFAIK, there are no platforms supporting both. PSCI specifications, 5.20.1: "The platform will boot in platform-coordinated mode." So all platforms implementing OSI have to support both. > But, the OSI feature is critical for QCOM mobile platforms. The > last man activities during cpuidle save quite a lot of power. What I expressed above was that, in PSCI based systems (OSI or PC alike), it is up to firmware/hardware to detect "the last man" not the kernel. I need to understand what you mean by "last man activities" to provide feedback here. > Powering off the clocks, busses, regulators and even the oscillator is > very important to have a reasonable battery life when using the phone. > Platform coordinated approach falls quite short of the needs of a > powerful processor with a desired battery efficiency. I am sorry but if you want us to merge PSCI patches in this series you will have to back the claim above with a detailed technical explanation of *why* platform-coordination falls short of QCOM (or whoever else) needs wrt PSCI OSI. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
