[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <519138d9-2434-4357-abec-f400b87755c6@linaro.org>
Date: Wed, 20 Dec 2023 13:29:43 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Komal Bajaj <quic_kbajaj@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: qcom: qcm6490-idp: Enable various
remoteprocs
On 20.12.2023 13:18, Dmitry Baryshkov wrote:
> On Wed, 20 Dec 2023 at 13:46, Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 20/12/2023 12:42, Komal Bajaj wrote:
>>> Enable the ADSP, CDSP, MPSS and WPSS that are found on the SoC.
>>>
>>> Signed-off-by: Komal Bajaj <quic_kbajaj@...cinc.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 20 ++++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>>> index 03e97e27d16d..ad78efa9197d 100644
>>> --- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
>>> @@ -419,6 +419,26 @@ &qupv3_id_0 {
>>> status = "okay";
>>> };
>>>
>>> +&remoteproc_adsp {
>>> + firmware-name = "qcom/qcm6490/adsp.mdt";
>>
>> Why MDT not MBN?
>
> I agree here. NAK until this is .mbn. Please follow the example of
> other boards when you write patches.
>
>>
>> I don't see these files in linux-firmware and your cover letter did not
>> explain anything around their submission. What's the status on that part?
>
> This isn't usually required, is it? I mean, the firmware can come from
> linux-firmware, from the device partition or in any other way. With
> the FW_LOADER_USER_HELPER this becomes just the key string used to
> identify firmware to be loaded.
I think Krzysztof referenced the fact that the Qualcomm-made boards
usually came with redistributable firmware.
As far as my 5 cents go, not submitting the files to linux-firmware.git
only harms the user experience, so I'd always advocate for it, whenever
that is actually possible.
Konrad
Powered by blists - more mailing lists