| Message ID | 20250318-topic-more_dt_bindings_fixes-v1-2-cb36882ea9cc@oss.qualcomm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | More more dt-bindings fixes for arm64/qcom | expand |
On Tue, Mar 18, 2025 at 07:35:15PM +0100, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > SC7180 comes in a couple firmware flavors, some of which don't support > PSCI in OSI mode. That prevents the power domain exepcted by the RSC > node from providing useful information on system power collapse. Is this behaviour specific to SC7180 or only to ChromeBooks? For example TCL Book 14 Go or ECS Liva QC710, would they also use this compat? > > Use the platform-specific compatible to allow not passing one. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi > index 87c432c12a240f8035753ad10ce8662584a3f1f3..c79b256690fee8a20853e1662503e1f4250611af 100644 > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi > @@ -3720,7 +3720,7 @@ frame@17c2d000 { > }; > > apps_rsc: rsc@18200000 { > - compatible = "qcom,rpmh-rsc"; > + compatible = "qcom,sc7180-rpmh-apps-rsc", "qcom,rpmh-rsc"; > reg = <0 0x18200000 0 0x10000>, > <0 0x18210000 0 0x10000>, > <0 0x18220000 0 0x10000>; > > -- > 2.48.1 >
On 3/18/25 10:30 PM, Dmitry Baryshkov wrote: > On Tue, Mar 18, 2025 at 07:35:15PM +0100, Konrad Dybcio wrote: >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >> >> SC7180 comes in a couple firmware flavors, some of which don't support >> PSCI in OSI mode. That prevents the power domain exepcted by the RSC >> node from providing useful information on system power collapse. > > Is this behaviour specific to SC7180 or only to ChromeBooks? For example > TCL Book 14 Go or ECS Liva QC710, would they also use this compat? The hardware and firmware representation of the RSC is identical, but I wanted to alter the bindings required properties based on the specific possibly-chrome platforms. Konrad
On Wed, Mar 19, 2025 at 03:14:42PM +0100, Konrad Dybcio wrote: > On 3/18/25 10:30 PM, Dmitry Baryshkov wrote: > > On Tue, Mar 18, 2025 at 07:35:15PM +0100, Konrad Dybcio wrote: > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >> > >> SC7180 comes in a couple firmware flavors, some of which don't support > >> PSCI in OSI mode. That prevents the power domain exepcted by the RSC > >> node from providing useful information on system power collapse. > > > > Is this behaviour specific to SC7180 or only to ChromeBooks? For example > > TCL Book 14 Go or ECS Liva QC710, would they also use this compat? > > The hardware and firmware representation of the RSC is identical, but > I wanted to alter the bindings required properties based on the specific > possibly-chrome platforms. Should we instead have a separate compatible (?) for ChromeOS platforms only?
On 3/19/25 6:25 PM, Dmitry Baryshkov wrote: > On Wed, Mar 19, 2025 at 03:14:42PM +0100, Konrad Dybcio wrote: >> On 3/18/25 10:30 PM, Dmitry Baryshkov wrote: >>> On Tue, Mar 18, 2025 at 07:35:15PM +0100, Konrad Dybcio wrote: >>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>> >>>> SC7180 comes in a couple firmware flavors, some of which don't support >>>> PSCI in OSI mode. That prevents the power domain exepcted by the RSC >>>> node from providing useful information on system power collapse. >>> >>> Is this behaviour specific to SC7180 or only to ChromeBooks? For example >>> TCL Book 14 Go or ECS Liva QC710, would they also use this compat? >> >> The hardware and firmware representation of the RSC is identical, but >> I wanted to alter the bindings required properties based on the specific >> possibly-chrome platforms. > > Should we instead have a separate compatible (?) for ChromeOS platforms > only? No, the RSC is exactly the same. Quite frankly, the expected power-domains entry is just a way that's convenient to Linux to signal the platform going off between the drivers I don't think there is much to overthink here. Konrad
On Wed, Mar 19, 2025 at 06:28:46PM +0100, Konrad Dybcio wrote: > On 3/19/25 6:25 PM, Dmitry Baryshkov wrote: > > On Wed, Mar 19, 2025 at 03:14:42PM +0100, Konrad Dybcio wrote: > >> On 3/18/25 10:30 PM, Dmitry Baryshkov wrote: > >>> On Tue, Mar 18, 2025 at 07:35:15PM +0100, Konrad Dybcio wrote: > >>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >>>> > >>>> SC7180 comes in a couple firmware flavors, some of which don't support > >>>> PSCI in OSI mode. That prevents the power domain exepcted by the RSC > >>>> node from providing useful information on system power collapse. > >>> > >>> Is this behaviour specific to SC7180 or only to ChromeBooks? For example > >>> TCL Book 14 Go or ECS Liva QC710, would they also use this compat? > >> > >> The hardware and firmware representation of the RSC is identical, but > >> I wanted to alter the bindings required properties based on the specific > >> possibly-chrome platforms. > > > > Should we instead have a separate compatible (?) for ChromeOS platforms > > only? > > No, the RSC is exactly the same. Quite frankly, the expected power-domains > entry is just a way that's convenient to Linux to signal the platform going > off between the drivers > > I don't think there is much to overthink here. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi index 87c432c12a240f8035753ad10ce8662584a3f1f3..c79b256690fee8a20853e1662503e1f4250611af 100644 --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi @@ -3720,7 +3720,7 @@ frame@17c2d000 { }; apps_rsc: rsc@18200000 { - compatible = "qcom,rpmh-rsc"; + compatible = "qcom,sc7180-rpmh-apps-rsc", "qcom,rpmh-rsc"; reg = <0 0x18200000 0 0x10000>, <0 0x18210000 0 0x10000>, <0 0x18220000 0 0x10000>;