From: sashiko-bot@kernel.org
To: "Vikash Garodia" <vikash.garodia@oss.qualcomm.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
Date: Thu, 09 Jul 2026 14:10:33 +0000 [thread overview]
Message-ID: <20260709141034.15E201F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709-vpu_iommu_iova_handling-v1-7-72bb62cb2dfd@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `iommu-addresses` property is incorrectly used to limit the non-pixel stream's IOVA space. Instead of restricting allocations to the 0-600 MB range, it marks the range as an IOMMU reservation (`IOMMU_RESV_RESERVED`), which forces the allocator to skip it and allocate IOVAs above 600 MB, directly violating hardware constraints.
--
--- Patch [7]: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes ---
commit 96b940efc5fae7db37d762be78144fc901472a7b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes
This commit splits the Iris VPU into non-pixel and pixel sub-nodes to
describe separate IOVA constraints. It uses a reserved memory region with
iommu-addresses to attempt limiting the non-pixel stream to the 0-600 MB
range.
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -657,6 +657,10 @@ smem_mem: smem@ffe00000 {
> hwlocks = <&tcsr_mutex 3>;
> no-map;
> };
> +
> + iris_resv: reservation-iris {
> + iommu-addresses = <&iris_non_pixel 0x0 0x0 0x0 0x25800000>;
> + };
[Severity: High]
Does this iommu-addresses property actually restrict allocations to the
0-600 MB range, or does it do the exact opposite?
Because this reservation node lacks a physical reg property,
of_iommu_get_resv_regions() parses it as an IOMMU_RESV_RESERVED region.
When iova_reserve_iommu_regions() processes this, it permanently blocks
the 0-600 MB range from the device's IOVA allocator.
Could this force the allocator to fall back to IOVAs above 600 MB (or
fail entirely), directly violating the hardware constraint and leading to
the device crashes mentioned in the commit message?
> };
>
[ ... ]
> @@ -5446,6 +5451,15 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> */
> status = "disabled";
>
> + iris_non_pixel: non-pixel {
> + iommus = <&apps_smmu 0x1940 0x0>;
> + memory-region = <&iris_resv>;
> + };
> +
> + iris_pixel: pixel {
> + iommus = <&apps_smmu 0x1947 0x0>;
> + };
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com?part=7
next prev parent reply other threads:[~2026-07-09 14:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7GAZnP6jPoRrcDnaVzeaB98cONLhtvbiEXV1yD5MJJrA9pCnC9lmlSiCGA8vlDezSXADjmFiqo3ZdClO5SxCFA==@protonmail.internalid>
2026-07-09 12:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 01/11] dt-bindings: media: qcom,sm8550-iris: Add vpu " Vikash Garodia
2026-07-09 12:46 ` sashiko-bot
2026-07-09 12:50 ` Dmitry Baryshkov
2026-07-10 6:02 ` Vikash Garodia
2026-07-10 15:53 ` Dmitry Baryshkov
2026-07-11 5:46 ` Vikash Garodia
2026-07-10 22:02 ` Bryan O'Donoghue
2026-07-09 12:35 ` [RFC PATCH 02/11] media: iris: Add hooks to initialize and tear down context banks Vikash Garodia
2026-07-09 12:57 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 03/11] media: iris: Add helper to create a context bank device Vikash Garodia
2026-07-09 13:10 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 04/11] media: iris: Add helper to select relevant " Vikash Garodia
2026-07-09 12:35 ` [RFC PATCH 05/11] media: iris: Skip DMA mask setting to core device when IOMMU is not mapped Vikash Garodia
2026-07-09 13:10 ` Dmitry Baryshkov
2026-07-09 13:43 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 06/11] media: iris: Add hooks for pixel and non-pixel context banks Vikash Garodia
2026-07-09 13:14 ` Dmitry Baryshkov
2026-07-10 6:32 ` Vikash Garodia
2026-07-10 16:03 ` Dmitry Baryshkov
2026-07-09 13:54 ` sashiko-bot
2026-07-10 16:12 ` Dmitry Baryshkov
2026-07-09 12:35 ` [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes Vikash Garodia
2026-07-09 13:03 ` Dmitry Baryshkov
2026-07-10 6:05 ` Vikash Garodia
2026-07-10 21:05 ` Dmitry Baryshkov
2026-07-09 14:10 ` sashiko-bot [this message]
2026-07-10 10:48 ` Bryan O'Donoghue
2026-07-10 22:46 ` Bryan O'Donoghue
2026-07-09 12:35 ` [RFC PATCH 08/11] arm64: dts: qcom: sm8550: Move Iris IOMMUs to child nodes Vikash Garodia
2026-07-09 14:30 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 09/11] arm64: dts: qcom: lemans: " Vikash Garodia
2026-07-09 14:44 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 10/11] arm64: dts: qcom: monaco: " Vikash Garodia
2026-07-09 15:03 ` sashiko-bot
2026-07-09 12:35 ` [RFC PATCH 11/11] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-07-09 15:29 ` sashiko-bot
2026-07-10 10:35 ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Bryan O'Donoghue
2026-07-10 13:36 ` Vikash Garodia
2026-07-10 13:38 ` Bryan O'Donoghue
2026-07-10 14:02 ` Vikash Garodia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260709141034.15E201F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vikash.garodia@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox