On Thu, 28 Jul 2022 at 11:40, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > On Wed, Jul 27, 2022 at 04:24:22PM +0300, Dmitry Baryshkov 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. > > Yikes, fix the damn broken firmware. That is utter non-sense. I don't > understand why would the firmware authors enable some feature before it > is ready. > > > 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! > > > > Well it is simply broken then. Not tested firmware, so please don't > attempt to use OSI if it is so fundamentally broken. I find it hard to > accept the argument that well it works just that the query API is failing. > But what is the guarantee that it is tested well enough. We will end up > adding more quirks after adding one to enable it. > > > My logical assumption would be that the firmware reports support for > > OS_INITIATED, but then just fails to properly support > > SET_SUSPEND_MODE. > > I knew this argument was coming as I wrote above, sorry I don't buy that. > It is probably one of the early platforms supporting PSCI and not well tested > for conformance. So I am inclined to just say we can't support it. I have quoted the commit message from the vendor kernel (and the debugfs entries) in other messages in this thread. It definitely seems like the platform breaks strict standard conformance by supporting CPU_SUSPEND, but not the SET_SUSPEND_MODE. Vendor kernel still used the CPU_SUSPEND with a domain-like approach, expecting to find the PSCI already being running in the OSI mode. So I'd ask for the ability to add a flag to DT telling the PSCI_DOMAINS code that the platform is already running in the OSI mode despite set_osi_mode() returning NOT_SUPPORTED. I would not say that this firmware was not tested to work with the domains approach. The whole bunch of phones/tables were shipped with this issue being present and the vendor kernel using a tree-wide approach to cpu/cluster/system states. -- With best wishes Dmitry
