Re: PSCI domains without OSI support

[Dmitry Baryshkov <dmitry.baryshkov@linaro.org>]

On Wed, 27 Jul 2022 at 16:24, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Wed, 27 Jul 2022 at 14:14, Sudeep Holla <sudeep.holla@arm.com> 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