From: Matti Lehtimäki <matti.lehtimaki@gmail.com>

Enable modem remoteproc on samsung,matisse-wifi & matisselte.

Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
index fbd568c7d6b7415d240aa1a2329d07cf9135274c..4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
@@ -225,6 +225,13 @@ &blsp1_uart3 {
 	status = "okay";
 };
 
+&modem {
+	mx-supply = <&pm8226_l3>;
+	pll-supply = <&pm8226_l8>;
+
+	status = "okay";
+};
+
 &rpm_requests {
 	regulators {
 		compatible = "qcom,rpm-pm8226-regulators";

-- 
2.48.1

On Sun, Jan 26, 2025 at 09:57:28PM +0100, Luca Weiss wrote:
> From: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> 
> Enable modem remoteproc on samsung,matisse-wifi & matisselte.
> 
> Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---
>  arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> index fbd568c7d6b7415d240aa1a2329d07cf9135274c..4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
> --- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> @@ -225,6 +225,13 @@ &blsp1_uart3 {
>  	status = "okay";
>  };
>  
> +&modem {
> +	mx-supply = <&pm8226_l3>;
> +	pll-supply = <&pm8226_l8>;

Hmmmmm, so I was looking at msm8926.dtsi downstream and it seems to
override the msm8226.dtsi modem/mss definition [1]:

 1. ext-bhs-reg is dropped
 2. vdd_mss-supply is added

This common include seems to cover both apq8026 (matissewifi) and
msm8926 (matisselte).

Do we need to handle this difference?

First time I see such a difference between variants of a single SoC.
Looking at all the overrides in msm8926.dtsi, it seems like they made
quite some rework for the "LTE variant".

Thanks,
Stephan

[1]: https://github.com/GalaxyTab4/android_kernel_samsung_matissewifi/blob/45f97bab323176fead18c8ddc20dc57d979904a3/arch/arm/boot/dts/msm8226/msm8926.dtsi#L32-L40

On maandag 27 januari 2025 10:44:19 Midden-Europese standaardtijd Stephan 
Gerhold wrote:
> On Sun, Jan 26, 2025 at 09:57:28PM +0100, Luca Weiss wrote:
> > From: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> > 
> > Enable modem remoteproc on samsung,matisse-wifi & matisselte.
> > 
> > Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > ---
> >  arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++
++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-
common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > index fbd568c7d6b7415d240aa1a2329d07cf9135274c..
4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
> > --- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > +++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > @@ -225,6 +225,13 @@ &blsp1_uart3 {
> >  	status = "okay";
> >  };
> >  
> > +&modem {
> > +	mx-supply = <&pm8226_l3>;
> > +	pll-supply = <&pm8226_l8>;
> 
> Hmmmmm, so I was looking at msm8926.dtsi downstream and it seems to
> override the msm8226.dtsi modem/mss definition [1]:
> 
>  1. ext-bhs-reg is dropped
>  2. vdd_mss-supply is added

That's the same what I found, and have working with more (currently hacky) 
patches on msm8926-htc-memul. I decided against introducing it with this 
series since these patches have been pending for too long and initially when I 
was doing 8926, I wasn't sure how to make this into a proper patch. Now my 
idea is to introduce a "static const struct rproc_hexagon_res msm8926_mss" 
with the compatible qcom,msm8926-mss-pil which has these two differences.
I think that's a better idea than adding some extra conditionals around to 
make the mss-supply optional and ext-bhs somehow optional in the driver based 
on dt.

> 
> This common include seems to cover both apq8026 (matissewifi) and
> msm8926 (matisselte).

That's a very good point. I didn't think much about the matisse patches since 
they were introduced by Matti but yes... Either I add the msm8926 support in 
the same series already, or we just enable modem for matissewifi for now. I 
think I'll opt for the latter since the series is already 9 patches long and I 
don't want to make it too complicated.

> 
> Do we need to handle this difference?
> 
> First time I see such a difference between variants of a single SoC.
> Looking at all the overrides in msm8926.dtsi, it seems like they made
> quite some rework for the "LTE variant".

Yeah, no clue what they did here. But also I think Qualcomm stopped making a 
thousand different variants of the same SoC (*cough* msm8974), nowadays they 
"only" make different variants which get different letters and numbers 
(sc7280=qcm6490=sm7325 etc).

> 
> Thanks,
> Stephan
> 
> [1]: https://github.com/GalaxyTab4/android_kernel_samsung_matissewifi/blob/
45f97bab323176fead18c8ddc20dc57d979904a3/arch/arm/boot/dts/msm8226/
msm8926.dtsi#L32-L40
> 

On 27.01.2025 2:34 PM, Luca Weiss wrote:
> On maandag 27 januari 2025 10:44:19 Midden-Europese standaardtijd Stephan 
> Gerhold wrote:
>> On Sun, Jan 26, 2025 at 09:57:28PM +0100, Luca Weiss wrote:
>>> From: Matti Lehtimäki <matti.lehtimaki@gmail.com>
>>>
>>> Enable modem remoteproc on samsung,matisse-wifi & matisselte.
>>>
>>> Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>> ---
>>>  arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++
> ++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-
> common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
>>> index fbd568c7d6b7415d240aa1a2329d07cf9135274c..
> 4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
>>> --- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
>>> +++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
>>> @@ -225,6 +225,13 @@ &blsp1_uart3 {
>>>  	status = "okay";
>>>  };
>>>  
>>> +&modem {
>>> +	mx-supply = <&pm8226_l3>;
>>> +	pll-supply = <&pm8226_l8>;
>>
>> Hmmmmm, so I was looking at msm8926.dtsi downstream and it seems to
>> override the msm8226.dtsi modem/mss definition [1]:
>>
>>  1. ext-bhs-reg is dropped
>>  2. vdd_mss-supply is added
> 
> That's the same what I found, and have working with more (currently hacky) 
> patches on msm8926-htc-memul. I decided against introducing it with this 
> series since these patches have been pending for too long and initially when I 
> was doing 8926, I wasn't sure how to make this into a proper patch. Now my 
> idea is to introduce a "static const struct rproc_hexagon_res msm8926_mss" 
> with the compatible qcom,msm8926-mss-pil which has these two differences.
> I think that's a better idea than adding some extra conditionals around to 
> make the mss-supply optional and ext-bhs somehow optional in the driver based 
> on dt.

Sounds good. It would then live in msm8926.dtsi which already exists

Konrad

On Mon, Jan 27, 2025 at 02:34:08PM +0100, Luca Weiss wrote:
> On maandag 27 januari 2025 10:44:19 Midden-Europese standaardtijd Stephan 
> Gerhold wrote:
> > On Sun, Jan 26, 2025 at 09:57:28PM +0100, Luca Weiss wrote:
> > > From: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> > > 
> > > Enable modem remoteproc on samsung,matisse-wifi & matisselte.
> > > 
> > > Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
> > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > > ---
> > >  arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi | 7 +++++
> ++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-
> common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > index fbd568c7d6b7415d240aa1a2329d07cf9135274c..
> 4155bfb2136022f2a85d69451c34f06ed2a700ac 100644
> > > --- a/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > +++ b/arch/arm/boot/dts/qcom/qcom-msm8226-samsung-matisse-common.dtsi
> > > @@ -225,6 +225,13 @@ &blsp1_uart3 {
> > >  	status = "okay";
> > >  };
> > >  
> > > +&modem {
> > > +	mx-supply = <&pm8226_l3>;
> > > +	pll-supply = <&pm8226_l8>;
> > 
> > Hmmmmm, so I was looking at msm8926.dtsi downstream and it seems to
> > override the msm8226.dtsi modem/mss definition [1]:
> > 
> >  1. ext-bhs-reg is dropped
> >  2. vdd_mss-supply is added
> 
> That's the same what I found, and have working with more (currently hacky) 
> patches on msm8926-htc-memul. I decided against introducing it with this 
> series since these patches have been pending for too long and initially when I 
> was doing 8926, I wasn't sure how to make this into a proper patch. Now my 
> idea is to introduce a "static const struct rproc_hexagon_res msm8926_mss" 
> with the compatible qcom,msm8926-mss-pil which has these two differences.
> I think that's a better idea than adding some extra conditionals around to 
> make the mss-supply optional and ext-bhs somehow optional in the driver based 
> on dt.
> 

Yeah, that sounds good. Could add a new qcom-msm8926.dtsi include that
overrides the compatible and /delete-property/ the ext-bhs-reg. Then
just #include that only for matisselte and add the mss-supply there.

> > 
> > This common include seems to cover both apq8026 (matissewifi) and
> > msm8926 (matisselte).
> 
> That's a very good point. I didn't think much about the matisse patches since 
> they were introduced by Matti but yes... Either I add the msm8926 support in 
> the same series already, or we just enable modem for matissewifi for now. I 
> think I'll opt for the latter since the series is already 9 patches long and I 
> don't want to make it too complicated.
> 

Either way is fine for me. I guess I'd personally throw it in one
series, just because it fits well together and it can take quite some
time to get patches applied. :-)

Thanks,
Stephan