Re: PSCI domains without OSI support

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Vinod Koul <vinod.koul@linaro.org>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: PSCI domains without OSI support
Date: Wed, 27 Jul 2022 23:51:01 +0300	[thread overview]
Message-ID: <CAA8EJppWSQTrZgN7yBLhLepuxEiFsBnkhcXOgXrz2qjGj3GcLw@mail.gmail.com> (raw)
In-Reply-To: <CAA8EJpqP9XMcLP+Pmj5OnXD2_SJ9ULBZ_Q492+x56oQnPzqiUA@mail.gmail.com>

On Wed, 27 Jul 2022 at 16:39, Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> 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)

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.

-- 
With best wishes
Dmitry