On Wed, Jul 27, 2022 at 12:09:27PM +0300, Dmitry Baryshkov wrote: > Hi, > > Lately I have been working on improving the msm8996 platform support. > Vendor kernel seems to support domain-like idle (see [1], [2]). > However when I tried changing upstream msm8996.dtsi to use PSCI > domains, I faced the firmware reporting NOT_SUPPORTED to an attempt to > enable OSI (thus rendering PSCI domains useless, as they are now > marked with ALWAYS_ON). > That's not good to hear 🙁. > I noticed that vendor kernel makes a call to cpu_suspend() with > power_state following the original format (described in PSCI spec > 5.4.2.1). What would be the best way to support this? And why is this not possible with the existing code ? Not sure if I understood it right, I am assuming you are mentioning that it is not possible. > - Allow DTS forcing the PSCI power domains even if OSI enablement fails? Meaning DTS flag for this ? If OSI enable fails, why would you want to still proceed. It is non-compliant and must be fixed if the firmware supports OSI and expects OSPM to use the same. > - Add a separate cpuidle driver? I would avoid that. > - Just forget about it and use plain PSCI as we currently do? > Worst case yes. My main worry is how many of the old SDM SoC has such a behaviour and how much they wary from each other. The OSI mode was pushed after lengthy discussions to support all these platforms and now we have platforms needing separate idle driver ? > Additional topic: for one of idle states the vendor kernel uses a > proprietary call into the hypervisor ([3]). Again I would say it is not spec compliant. > Up to now we have ignored this, as 8996 seems to be the only platform using > it. I suppose that adding it to cpuidle-psci.c would be frowned upon. Indeed. > Is this assumption correct? Would it add another point for adding a separate > cpuidle driver? > I am getting a sense that this would be cleaner approach but I would like to understand how much of these non-compliance is carried to the other relatively newer SoCs. I understand this is atleast 5-6+ years old. I don't want this to set example to deviate from standard driver by adding new drivers though they all are supposedly using PSCI(and are not fully compliant) -- Regards, Sudeep
