[PATCH RFC v2 04/14] arm64: dts: qcom: sm8650: move smmu sid 1 to new lpac device
Konrad Dybcio
konrad.dybcio at oss.qualcomm.com
Fri Oct 30 06:10:01 PDT 2026
On 10/29/26 2:52 PM, Anna Maniscalco wrote:
> Previously both SID 0 and 1 where associated with the same domain.
>
> When LPAC is not used this is needed so firmware can acces memory when
> initializing using the same page table as GFX.
>
> To use LPAC however we need to move SID 1 to a different device.
>
> Signed-off-by: Anna Maniscalco <anna.maniscalco2000 at gmail.com>
> ---
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 1604bc8cff37..f47d1dbd06da 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -4144,8 +4144,7 @@ gpu: gpu at 3d00000 {
>
> interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH 0>;
>
> - iommus = <&adreno_smmu 0 0x0>,
> - <&adreno_smmu 1 0x0>;
> + iommus = <&adreno_smmu 0 0x0>;
>
> operating-points-v2 = <&gpu_opp_table>;
>
> @@ -4158,6 +4157,12 @@ gpu: gpu at 3d00000 {
>
> status = "disabled";
>
> + lpac: lpac {
> + compatible = "qcom,lpac";
I'm debating what to do with the compatible here.. On one hand they
shouldn't be generic (should be soc hw specific instead, but that
feels a little overkill here) and it may be that we even don't need
one, but the iommu driver needs to know what we need a 1:1 mapping
hmm..
Konrad
> +
> + iommus = <&adreno_smmu 1 0x0>;
> + };
> +
> gpu_zap_shader: zap-shader {
> memory-region = <&gpu_micro_code_mem>;
> };
>
More information about the linux-arm-kernel
mailing list