[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <537jfsochzicr6pha6jt46ngltk2z4jjm5se7sti3klcgjd66u@wawpyrsihqeq>
Date: Fri, 5 Dec 2025 17:00:20 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
Cc: Mathieu Poirier <mathieu.poirier@...aro.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Manivannan Sadhasivam <mani@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 14/14] arm64: dts: qcom: Add EL2 overlay for Lemans
On Fri, Nov 21, 2025 at 04:31:16PM +0530, Mukesh Ojha wrote:
> All the Lemans IOT variants boards are using Gunyah hypervisor which
> means that, so far, Linux-based OS could only boot in EL1 on those
> devices. However, it is possible for us to boot Linux at EL2 on these
> devices [1].
>
> When running under Gunyah, remote processor firmware IOMMU streams is
> controlled by the Gunyah however when Linux take ownership of it in EL2,
> It need to configure it properly to use remote processor.
>
> Add a EL2-specific DT overlay and apply it to Lemans IOT variant
> devices to create -el2.dtb for each of them alongside "normal" dtb.
>
> [1]
> https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 10 ++++++++
> arch/arm64/boot/dts/qcom/lemans-el2.dtso | 41 ++++++++++++++++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 6f34d5ed331c..56efd90b7a5e 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -37,6 +37,10 @@ lemans-evk-camera-dtbs := lemans-evk.dtb lemans-evk-camera.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera-csi1-imx577.dtb
> dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-camera.dtb
> +
> +lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
> +
> +dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += monaco-evk.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
> @@ -142,6 +146,12 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> +
> +qcs9100-ride-el2-dtbs := qcs9100-ride.dtb lemans-el2.dtbo
> +qcs9100-ride-r3-el2-dtbs := qcs9100-ride-r3.dtb lemans-el2.dtbo
> +
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-el2.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3-el2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qrb2210-rb1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qrb4210-rb2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/lemans-el2.dtso b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> new file mode 100644
> index 000000000000..af35039946e3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/lemans-el2.dtso
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/*
> + * Lemans specific modifications required to boot in EL2.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&iris {
> + /* More driver work is needed */
You can write this comment without referring to some particular
implementation (as DeviceTree should).
/* The binding doesn't allow for describing the firmware IOMMU stream yet */
> + status = "disabled";
> +};
> +
> +/*
> + * When running under Gunyah, remote processor firmware IOMMU streams is
> + * controlled by the Gunyah however when we take ownership of it in EL2,
> + * we need to configure it properly to use remote processor.
The comment describes how things work with Gunyah, and then from that
angle explains why we need this. I'd find it preferable to keep the
perspective of not having Gunyah. Something as simple as:
/*
* Without Gunyah, the IOMMU is managed by the consumer of this DeviceTree,
* so describe the firmware streams for each remoteproc.
*/
That said, once the iris binding (and others) allow us to describe the
firmware stream, this comment will be misplaced. So perhaps apply my
feedback to the commit message and omit the comment here. If someone
wonders why it looks like it does, the commit message in the git history
will tell them.
Regards,
Bjorn
> + */
> +&remoteproc_adsp {
> + iommus = <&apps_smmu 0x3000 0x0>;
> +};
> +
> +&remoteproc_cdsp0 {
> + iommus = <&apps_smmu 0x21c0 0x0400>;
> +};
> +
> +&remoteproc_cdsp1 {
> + iommus = <&apps_smmu 0x29c0 0x0400>;
> +};
> +
> +&remoteproc_gpdsp0 {
> + iommus = <&apps_smmu 0x38a0 0x0>;
> +};
> +
> +&remoteproc_gpdsp1 {
> + iommus = <&apps_smmu 0x38c0 0x0>;
> +};
>
> --
> 2.50.1
>
Powered by blists - more mailing lists