Re: [PATCH v2] arm64: dts: qcom: hamoa: Add remoteproc in EL2 device trees

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Wed, Mar 04, 2026 at 02:16:55PM -0600, Bjorn Andersson wrote:
> On Sun, Feb 01, 2026 at 09:54:36PM -0800, Xin Liu wrote:
> > All the existing variants Hamoa 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].
> > 
> 
> Lots of people are running Linux at EL2 on their Hamoa laptops, but
> then there's no PAS. I presume adding iommu properties won't "hurt" in
> that case, but can you confirm that with this change remoteproc is fully
> working somewhere (i.e. [1] refers to a firmware for which the Glymur
> PAS/PIL changes has been backported?)
> 

On the contrary, I would expect that this will break the existing EL2
setup people have on their Hamoa laptops. I have last tested this half a
year ago (and I don't have a suitable device for testing this anymore),
but I don't think much has changed in this area:

Since we can't start/stop remoteprocs without PAS, everyone using EL2
with the old (non-PAS) firmware currently relies on remoteprocs that are
already started by the boot firmware before Linux is started. This can
be just the "lite" ADSP that is started by UEFI for initial charging and
USB-C detection, or even the full ADSP/CDSP via a custom UEFI driver
(qebspil [1]). All of these will stay running even if we fail to
stop/start them via PAS. Without extra kernel patches, we can't make use
of the remoteprocs, but the lite ADSP firmware will probably continue
doing its work in the background, i.e. it will start/stop charging as
needed, you just won't be able to observe the status from Linux.

We manage the full IOMMU even when there is no PAS. The reason why
people are not running into issues is that the bootloader handover code
inside arm-smmu-qcom.c qcom_smmu_cfg_probe() configures bypass for all
SIDs used by the boot firmware, which includes the SIDs for all the
remoteprocs. Adding these SIDs in the "iommus" property of an actual
device will replace the bypass with a translated context, which
currently won't be set up anywhere for the non-PAS use case.

In addition, even on newer firmware with PAS support I would expect that
special care is required to "atomically" handover the IOMMU
configuration from the bootloader. If the lite ADSP remains running on
these firmware versions as well, the bypass or suitable mappings must be
maintained until the lite ADSP firmware is stopped.

Glymur does not have this problem because the same functionality is
implemented in the SoCCP, which does not have any "iommus" defined
(managed as secure context banks by TZ?).

[1]: https://github.com/stephan-gh/qebspil

> 
> > When running under Gunyah, the remote processor firmware IOMMU streams
> > are controlled by Gunyah. However, without Gunyah, the IOMMU is managed
> > by the consumer of this DeviceTree. Therefore, describe the firmware
> > streams for each remote processor.
> > 
> > Add remoteproc to the EL2 device trees to generate the corresponding
> > -el2.dtb files.
> > 
> > [1]
> > https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> > 
> > Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
> > ---
> > Changes in v2:
> > - Fix the adsp iommus mask
> > - Link to v1 : https://lore.kernel.org/all/20260130073113.3091884-1-xin.liu@oss.qualcomm.com/
> > 
> >  arch/arm64/boot/dts/qcom/x1-el2.dtso | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > index 175679be01eb..ee006742d6f3 100644
> > --- a/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> > @@ -52,6 +52,14 @@ &pcie_smmu {
> >  	status = "okay";
> >  };
> >  
> > +&remoteproc_adsp {
> > +	iommus = <&apps_smmu 0x1000 0x80>;
> > +};

I have seen the ADSP trigger some faults with SID 0x100c as well.
I don't know what exactly that represents, but do we need to handle
that somewhere?

Thanks,
Stephan