MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
which has cx under proxy_pd_names and is otherwise equivalent.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index b306f223127c452f8f2d85aa0fc98db2d684feae..b1ba5a2381c396e0ee071df1426dc610affbc6a8 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -1437,7 +1437,7 @@ static const struct adsp_data sm8750_mpss_resource = {
 static const struct of_device_id adsp_of_match[] = {
 	{ .compatible = "qcom,msm8226-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8953-adsp-pil", .data = &msm8996_adsp_resource},
-	{ .compatible = "qcom,msm8974-adsp-pil", .data = &adsp_resource_init},
+	{ .compatible = "qcom,msm8974-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8996-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8996-slpi-pil", .data = &msm8996_slpi_resource_init},
 	{ .compatible = "qcom,msm8998-adsp-pas", .data = &msm8996_adsp_resource},

-- 
2.50.0

On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> which has cx under proxy_pd_names and is otherwise equivalent.
> 
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---
>  drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hmm. You are modifying the ADSP configuration in the driver, but at the
same time you've dropped CX supply from the MSS remoteproc.

-- 
With best wishes
Dmitry

On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>> which has cx under proxy_pd_names and is otherwise equivalent.
>>
>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>> ---
>>   drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Hmm. You are modifying the ADSP configuration in the driver, but at the
> same time you've dropped CX supply from the MSS remoteproc.

The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, 
which are used in case the power domain is not specified.

So no driver change is necessary in the mss driver for both old and new 
devicetrees, but the adsp driver does not have this fallback, so that's 
why the adsp config is updated.

Does that make it clear?

Regards
Luca

On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> > On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> > > MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> > > which has cx under proxy_pd_names and is otherwise equivalent.
> > > 
> > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > > ---
> > >   drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Hmm. You are modifying the ADSP configuration in the driver, but at the
> > same time you've dropped CX supply from the MSS remoteproc.
> 
> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
> are used in case the power domain is not specified.
> 
> So no driver change is necessary in the mss driver for both old and new
> devicetrees, but the adsp driver does not have this fallback, so that's why
> the adsp config is updated.
> 
> Does that make it clear?

Yes. Would it make sense to implement fallback_proxy_supply for ADSP
too?

> 
> Regards
> Luca

-- 
With best wishes
Dmitry

On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
> On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
>> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
>>> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>>>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>>>> which has cx under proxy_pd_names and is otherwise equivalent.
>>>>
>>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>>> ---
>>>>    drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Hmm. You are modifying the ADSP configuration in the driver, but at the
>>> same time you've dropped CX supply from the MSS remoteproc.
>>
>> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
>> are used in case the power domain is not specified.
>>
>> So no driver change is necessary in the mss driver for both old and new
>> devicetrees, but the adsp driver does not have this fallback, so that's why
>> the adsp config is updated.
>>
>> Does that make it clear?
> 
> Yes. Would it make sense to implement fallback_proxy_supply for ADSP
> too?

Definitely would be possible, but I don't see the point in doing the 
work to implement this, to then carry around a bunch of legacy 
compatibility code that (very likely) won't really be used in practice.
I don't think any platform apart from msm8974 are going to be affected 
by this anyways.

Still same argument from my side, I think breaking compatibility here 
for this one driver outweighs the effort/code of implementing compatibility.

Regards
Luca

> 
>>
>> Regards
>> Luca
>

On Sun, Jul 06, 2025 at 02:32:26PM +0200, Luca Weiss wrote:
> On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
> > On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
> > > On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> > > > On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> > > > > MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> > > > > which has cx under proxy_pd_names and is otherwise equivalent.
> > > > > 
> > > > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > > > > ---
> > > > >    drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > Hmm. You are modifying the ADSP configuration in the driver, but at the
> > > > same time you've dropped CX supply from the MSS remoteproc.
> > > 
> > > The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
> > > are used in case the power domain is not specified.
> > > 
> > > So no driver change is necessary in the mss driver for both old and new
> > > devicetrees, but the adsp driver does not have this fallback, so that's why
> > > the adsp config is updated.
> > > 
> > > Does that make it clear?
> > 
> > Yes. Would it make sense to implement fallback_proxy_supply for ADSP
> > too?
> 
> Definitely would be possible, but I don't see the point in doing the work to
> implement this, to then carry around a bunch of legacy compatibility code
> that (very likely) won't really be used in practice.
> I don't think any platform apart from msm8974 are going to be affected by
> this anyways.
> 
> Still same argument from my side, I think breaking compatibility here for
> this one driver outweighs the effort/code of implementing compatibility.

Ack. You have my r-b for the series anyways.

-- 
With best wishes
Dmitry

On 06-07-2025 3:17 p.m., Dmitry Baryshkov wrote:
> On Sun, Jul 06, 2025 at 02:32:26PM +0200, Luca Weiss wrote:
>> On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
>>> On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
>>>> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
>>>>> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>>>>>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>>>>>> which has cx under proxy_pd_names and is otherwise equivalent.
>>>>>>
>>>>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>>>>> ---
>>>>>>     drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> Hmm. You are modifying the ADSP configuration in the driver, but at the
>>>>> same time you've dropped CX supply from the MSS remoteproc.
>>>>
>>>> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
>>>> are used in case the power domain is not specified.
>>>>
>>>> So no driver change is necessary in the mss driver for both old and new
>>>> devicetrees, but the adsp driver does not have this fallback, so that's why
>>>> the adsp config is updated.
>>>>
>>>> Does that make it clear?
>>>
>>> Yes. Would it make sense to implement fallback_proxy_supply for ADSP
>>> too?
>>
>> Definitely would be possible, but I don't see the point in doing the work to
>> implement this, to then carry around a bunch of legacy compatibility code
>> that (very likely) won't really be used in practice.
>> I don't think any platform apart from msm8974 are going to be affected by
>> this anyways.
>>
>> Still same argument from my side, I think breaking compatibility here for
>> this one driver outweighs the effort/code of implementing compatibility.
> 
> Ack. You have my r-b for the series anyways.

Thanks!