Re: [PATCH 1/2] arm64: dts: qcom: qcm6490-idp: Enable various remoteprocs

From: Dmitry Baryshkov
Date: Fri Dec 22 2023 - 09:26:23 EST


On Fri, 22 Dec 2023 at 15:25, Komal Bajaj <quic_kbajaj@xxxxxxxxxxx> wrote:
>
>
>
> On 12/20/2023 6:04 PM, Dmitry Baryshkov wrote:
> > On Wed, 20 Dec 2023 at 14:29, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote:
> >>
> >> On 20.12.2023 13:18, Dmitry Baryshkov wrote:
> >>> On Wed, 20 Dec 2023 at 13:46, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxxx>
> >>>>> ---
> >>>>> 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.
> >
> > Me too. I think this is work in progress on the Qualcomm side, see the
> > discussion at https://github.com/Linaro/meta-qcom/pull/551 .
> >
>
> I was searching for MBN files pushed for SM8550 at
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/,
> but could not find it. Am I missing something?

Nobody handed out the files for sm8550 yet. So we could push only the
audio topology files.

> Are we maintaining it somewhere else asking just out of curiosity and
> learning and do similar for QCM/QCS6490.

That repo contains existing firmware for older platforms.
The firmware signed with the test keys goes to the SoC directory,
vendor-signed firmware goes to the subdir.

See qcom/sm8250 (RB5), qcom/sdm845 (RB3 aka db845c), qcom/qrb4210
(RB2), qcom/qcm2290 (RB1), qcom/apq8096 (db820c) and qcom/apq8016
(db410c).

For X13s there is a vendor-signed firmware at qcom/sc8280xp/LENOVO/21BX/

Venus / VPU firmware, being chip agnostic, goes to qcom/venus-* and
qcom/vpu-* Vendor-signed venus firmware should go to the same subdir
as all other device-specific files.

Generic Adreno firmware (SQE, GMU, GPMU, etc.) goes to qcom/ directly.
Signed ZAP shaders go to the qcom/SOC or device subdirs.

WiFI firmware goes to ath10k, ath11k or ath12k dirs. But please
coordinate with Kalle Valo, he maintains those subdirs.

BT firmware is piled up in qca subdir.

All mentioned files except the WiFi have migrated to .mbn format.

All licences are documented in the WHENCE file.

--
With best wishes
Dmitry