The Qualcomm SM7225 is practically identical to SM6350, so add an entry
using that data.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
I double checked and the Android builds for this platform also have a
.jsn file for the equivalent of &mpss_root_pd_gps but this is not part
of sm6350_domains upstream.

But I actually can't find any evidence of this actually being used in
the AMSS sources. Just some Android proprietary user space seems to try
and find 'gps/gps_service' but nothing relevant for 'msm/modem/root_pd'

Should we still correct this? Everything appears to work as expected and
"#define DEBUG" in the driver also doesn't show anything being wrong.
---
 drivers/soc/qcom/qcom_pd_mapper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/qcom/qcom_pd_mapper.c b/drivers/soc/qcom/qcom_pd_mapper.c
index 6e30f08761aa43da131a00885b2cc5e95960bc7c..d98738fd7c6456eb6c4ae265437363d2b8fb952a 100644
--- a/drivers/soc/qcom/qcom_pd_mapper.c
+++ b/drivers/soc/qcom/qcom_pd_mapper.c
@@ -553,6 +553,7 @@ static const struct of_device_id qcom_pdm_domains[] __maybe_unused = {
 	{ .compatible = "qcom,sm4250", .data = sm6115_domains, },
 	{ .compatible = "qcom,sm6115", .data = sm6115_domains, },
 	{ .compatible = "qcom,sm6350", .data = sm6350_domains, },
+	{ .compatible = "qcom,sm7225", .data = sm6350_domains, },
 	{ .compatible = "qcom,sm7325", .data = sc7280_domains, },
 	{ .compatible = "qcom,sm8150", .data = sm8150_domains, },
 	{ .compatible = "qcom,sm8250", .data = sm8250_domains, },

---
base-commit: 8155b4ef3466f0e289e8fcc9e6e62f3f4dceeac2
change-id: 20241220-pd-mapper-sm7225-8bd30fa6cb07

Best regards,
-- 
Luca Weiss <luca.weiss@fairphone.com>

On Fri, 20 Dec 2024 09:39:44 +0100, Luca Weiss wrote:
> The Qualcomm SM7225 is practically identical to SM6350, so add an entry
> using that data.
> 
> 

Applied, thanks!

[1/1] soc: qcom: pd_mapper: Add SM7225 compatible
      commit: 8e6854efd4738d3c9e6fdfeff8df726d454d4c7d

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>

On 20.12.2024 9:39 AM, Luca Weiss wrote:
> The Qualcomm SM7225 is practically identical to SM6350, so add an entry
> using that data.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---

I think we should instead add the fallback compatible, like

- enum:
      - asdf,asdf
- const: qcom,sm7225
- const: qcom,sm6350

as we've done for speedbin/rename variants of SoCs lately, with separate
entries being added for "actually different" sillicon.

Konrad

On Fri Dec 20, 2024 at 10:39 AM CET, Konrad Dybcio wrote:
> On 20.12.2024 9:39 AM, Luca Weiss wrote:
> > The Qualcomm SM7225 is practically identical to SM6350, so add an entry
> > using that data.
> > 
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
>
> I think we should instead add the fallback compatible, like
>
> - enum:
>       - asdf,asdf
> - const: qcom,sm7225
> - const: qcom,sm6350
>
> as we've done for speedbin/rename variants of SoCs lately, with separate
> entries being added for "actually different" sillicon.

We also have currently for example sm7325=sc7280=qcm6490, would that
fall into this category as well for you, or are they more different?

But do you think it's worth trying to also change existing platforms
like that? We also have basically the same list in
drivers/cpufreq/cpufreq-dt-platdev.c where we have both sm6350 and
sm7225 right now.

Regards
Luca

>
> Konrad

On 20.12.2024 11:15 AM, Luca Weiss wrote:
> On Fri Dec 20, 2024 at 10:39 AM CET, Konrad Dybcio wrote:
>> On 20.12.2024 9:39 AM, Luca Weiss wrote:
>>> The Qualcomm SM7225 is practically identical to SM6350, so add an entry
>>> using that data.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>> ---
>>
>> I think we should instead add the fallback compatible, like
>>
>> - enum:
>>       - asdf,asdf
>> - const: qcom,sm7225
>> - const: qcom,sm6350
>>
>> as we've done for speedbin/rename variants of SoCs lately, with separate
>> entries being added for "actually different" sillicon.
> 
> We also have currently for example sm7325=sc7280=qcm6490, would that
> fall into this category as well for you, or are they more different?
> 
> But do you think it's worth trying to also change existing platforms
> like that? We also have basically the same list in
> drivers/cpufreq/cpufreq-dt-platdev.c where we have both sm6350 and
> sm7225 right now.

Hm, with existing boards, I guess that's a question for dt-bindings folks

Konrad