diff mbox series

[2/8] arm64: dts: qcom: sc7180: Add specific APPS RSC compatible

Message ID 20250318-topic-more_dt_bindings_fixes-v1-2-cb36882ea9cc@oss.qualcomm.com
State Superseded
Headers show
Series More more dt-bindings fixes for arm64/qcom | expand

Commit Message

Konrad Dybcio March 18, 2025, 6:35 p.m. UTC 
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.

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(-)

Comments

Konrad Dybcio March 19, 2025, 2:14 p.m. UTC | #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
Dmitry Baryshkov March 19, 2025, 5:25 p.m. UTC | #2 
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?
Konrad Dybcio March 19, 2025, 5:28 p.m. UTC | #3 
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
Dmitry Baryshkov March 19, 2025, 6:51 p.m. UTC | #4 
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 mbox series

Patch

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>;