Re: [PATCH 02/19] remoteproc: qcom: pas: Add QCS8300 remoteproc support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/09/2024 06:30, Jingyi Wang wrote:
>>> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
>>> index ef82835e98a4..f92ccd4921b7 100644
>>> --- a/drivers/remoteproc/qcom_q6v5_pas.c
>>> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
>>> @@ -1416,6 +1416,9 @@ static const struct of_device_id adsp_of_match[] = {
>>>  	{ .compatible = "qcom,qcs404-adsp-pas", .data = &adsp_resource_init },
>>>  	{ .compatible = "qcom,qcs404-cdsp-pas", .data = &cdsp_resource_init },
>>>  	{ .compatible = "qcom,qcs404-wcss-pas", .data = &wcss_resource_init },
>>> +	{ .compatible = "qcom,qcs8300-adsp-pas", .data = &sa8775p_adsp_resource},
>>> +	{ .compatible = "qcom,qcs8300-cdsp-pas", .data = &sa8775p_cdsp0_resource},
>>> +	{ .compatible = "qcom,qcs8300-gpdsp-pas", .data = &sa8775p_gpdsp0_resource},
>>
>> What's the point of this? You have entire commit msg to explain such
>> weird duplication. Otherwise sorry, don't duplicate unnecessarily.
>> Devices are compatible, aren't they?
>>
>> Best regards,
>> Krzysztof
>>
>>
> I will drop this, could you please help us to understand what is the correct way to
> deal such situation, do we need to update the yaml and add qcs8300 bindings or just
> reference to sa8775p bindings in the device tree?

Above diff hunk suggests that devices are compatible, so should be made
compatible in the bindings (use fallback). There are plenty examples of
this for all Qualcomm devices.

Best regards,
Krzysztof





[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux