On 2021-05-28 09:35, Bjorn Andersson wrote:

On Tue 27 Apr 01:25 CDT 2021, Sibi Sankar wrote:

quoted

On 2021-04-18 07:31, Stephen Boyd wrote:

quoted

Quoting Sibi Sankar (2021-04-16 05:03:48)

quoted

The load state resources are expected to follow the life cycle of the
remote processor it tracks. However, modeling load state resources as
power-domains result in them getting turned off during system suspend
and thereby falling out of sync with the remote processors that are
still
on. Fix this by replacing load state resource control through the
generic
qmp message send interface instead.

Signed-off-by: Sibi Sankar <redacted>
---

Is it possible to keep this code around for a cycle so that there isn't
the chance that someone is using the deprecated DT bindings with a new
kernel? I worry that ripping the code out will cause them angst.

deprecated bindings with a newer kernel
shouldn't cause any problems since it is
the driver changes that make AOSS PD
mandatory or not. So the newer kernel will
just use qmp_send and leave the PD unused.

Maybe I'm missing something in your argument here, but I see two 
issues:
* The changes here requires that the new qcom,qmp property is defined,
  or the qcom_qmp_get() will be unable to find the qmp instance.
* Between patch 2 and 5 there's no load_state handling.

Perhaps we can carry the power-domain handling as a fallback i
qcom_qmp_get() fails, for a few releases?

The load_state implementation is currently
broken i.e. it currently sends that the
remoteproc is down during suspend. AFAIK it
can be safely dropped without side-effects.
I'll respin the series fixing Rob's comments.

Other than the ordering and backwards compatibility issue I think this
looks good. So can you please respin this based on the later revision 
of
the qmp patch? (And fix Rob's request on the commit message)

https://lore.kernel.org/linux-arm-msm/1620320818-2206-2-git-send-email-deesin@codeaurora.org/ (local)

Regards,
Bjorn

quoted

quoted

Certainly we have to keep the code in place until DT is updated, so this
patch should come last?

sure I don't mind, as long as it simplifies
the merge process.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.