On Wed, 27 Jul 2022 at 16:24, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On Wed, 27 Jul 2022 at 14:14, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > On Wed, Jul 27, 2022 at 12:09:27PM +0300, Dmitry Baryshkov wrote: > > > - 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. > > I'm not sure at this moment. PSCI firmware reports that OSI mode is > supported, but then when psci_pd_try_set_osi_mode() tries to switch > into OSI mode, it gets NOT_SUPPORTED. > Just for the sake of completeness, I added a print to the psci.c to > dump the result of the psci_set_osi_mode(false). It also returns > NOT_SUPPORTED! > > My logical assumption would be that the firmware reports support for > OS_INITIATED, but then just fails to properly support > SET_SUSPEND_MODE. Okay. From the msm-3.14 commit log: Add support to terminate all low power modes in PSCI. The lpm-levels will work with version 1.0 of PSCI specification using the OS initiated scheme. The lpm-levels driver would determine the last man standing and vote into TZ accordingly. Which means that the vendor kernel expected to work in the OSI mode without calling SET_SUSPEND (such call doesn't exist in 3.14) So, this looks like the "force-psci-domains" or "ignore-osi-error" flag would be logical. The question about testing still holds. > I should probably try ignoring the error psci-domain.c and continue > with binding power domains. What would be the best way to check that > the domains setup works as expected? -- With best wishes Dmitry
