On Mon, Aug 31, 2026 at 10:56:55AM -0500, Bjorn Andersson wrote: > On Fri, Aug 28, 2026 at 11:43:11PM +0530, Mukesh Ojha wrote: > > The proxy power domain enable path currently requests INT_MAX performance > > state for every proxy PD. While this serves as a "take highest available" > > hint, some SoCs require specific per-domain RPMH levels for correct > > operation during firmware load rather than a blanket maximum. > > > > Introduce a proxy_pd_performance_states array in qcom_pas_data to allow > > each proxy PD to declare its required RPMH performance level explicitly. > > Platforms that do not populate this field retain the existing INT_MAX > > behaviour. > > > > Is it possible to encode this using an optional opp-table instead of > filling the driver with such details? (This is a question, not a direct > suggestion)
Technically yes, via required-opps, each proxy PD would need its own opp-table and the remoteproc node would reference specific OPP entries via phandles. That is heavyweight machinery for three scalar values used only during the transient firmware-load window. But let me know if you see the benefit. > > > Also propagate the return value of dev_pm_genpd_set_performance_state() > > and emit a warning on failure rather than silently ignoring it. > > Also remember that whenever you start a paragraph in a commit message > with the word "also"; it's probably a good sign that it would be better > to have a separate commit. Agreed. The dev_pm_genpd_set_performance_state() error propagation fix should be a separate commit. > > > > > Add Hawi CDSP remoteproc support using this infrastructure with the > > following proxy PD performance states: > > That is quite weird, because you already stated that we added Hawi CDSP > support in > https://lore.kernel.org/r/[email protected] > > > Note that the line: > > compatible = "qcom,hawi-cdsp-pas", "qcom,sm8550-cdsp-pas"; > > is supposed to tell an OS that "if you have an implementation for > qcom,hawi-cdsp-pas use that, if not you can use the implementation for > qcom,sm8550-cdsp-pas". Yes, the April series added qcom,hawi-cdsp-pas in DT as a fallback to qcom,sm8550-cdsp-pas. The NSP proxy PD requirement was discovered recently and I realize you are right. I initially thought nothing was changing between the HW description but the performance states, but I see from the point of view of someone who has the latest firmware or DT and is still running an older OS, it can result in a crash, which is broken. > > This patch tells me that you need to also fix the binding to not say > that - because hawi-cdsp is no longer compatible with sm8550-cdsp. > > I'm guessing that this issue might have been a late discovery, state > that in your commit message changing the binding. I will add a binding patch to v2 that removes qcom,hawi-cdsp-pas from the sm8550-cdsp-pas fallback list and makes it a standalone compatible, with a commit message that explains this was a late discovery. The DTS will be updated to drop the qcom,sm8550-cdsp-pas fallback string. > > > > > CX: RPMH_REGULATOR_LEVEL_TURBO > > MXC: RPMH_REGULATOR_LEVEL_TURBO > > NSP: RPMH_REGULATOR_LEVEL_NOM > > I'm guessing that what you describe above about INT_MAX being a problem > is only for NSP? Would be nice to not having to guess though. Yes, for NSP only. Will be explicit here. -Mukesh
