On Wed, 27 Jul 2022 at 22:51, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On Wed, 27 Jul 2022 at 16:39, Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > 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) > > After adding the debugfs file, it's clear that this is the case. > > Compare msm8996: > PSCIv1.0 > SMC Calling Convention v1.0 is assumed > OSI is supported > Extended StateID format is used > > vs sdm845: > PSCIv1.1 > SMC Calling Convention v1.2 > OSI is supported > Extended StateID format is used > CPU_FREEZE is supported > SET_SUSPEND_MODE is supported > > Judging by people reporting 'failure to enable OSI mode' on several > other Qualcomm SoCs (msm8976, msm8953), this bug is present on several > older Qualcomm platforms. > > > > > So, this looks like the "force-psci-domains" or "ignore-osi-error" > > flag would be logical. > > The question about testing still holds. Alright, so this looks like a deviation from the spec. Nevertheless, it seems quite simple for us to fix by overriding the FW error, by adding a new DT flag, in the way you propose. In principle, I think the new DT flag should avoid us to call psci_set_osi_mode() in psci_pd_try_set_osi_mode(), but rather just return true when the flag is set. In this way, the GENPD_FLAG_ALWAYS_ON will not be set for the genpds that are created, so things should work as the PSCI FW has OSI mode enabled. Kind regards Uffe
