From: Krzysztof Kozlowski <krzk@kernel.org>
To: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Bryan O'Donoghue <bod@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
Vishnu Reddy <busanna.reddy@oss.qualcomm.com>,
Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Stephan Gerhold <stephan.gerhold@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Johan Hovold <johan+linaro@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Loic Poulain <loic.poulain@oss.qualcomm.com>,
Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>,
Mansur Alisha Shaik <mansur@codeaurora.org>,
Andy Gross <andy.gross@linaro.org>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Yassine Oudjana <y.oudjana@protonmail.com>,
Pierre-Hugues Husson <phhusson@freebox.fr>,
Marc Gonzalez <mgonzalez@freebox.fr>,
cros-qcom-dts-watchers@chromium.org,
Matthias Kaehlcke <mka@chromium.org>,
Douglas Anderson <dianders@chromium.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Aniket Masule <amasule@codeaurora.org>,
Malathi Gottam <quic_mgottam@quicinc.com>,
Rajendra Nayak <quic_rjendra@quicinc.com>,
Jonathan Marek <jonathan@marek.ca>,
Dikshita Agarwal <dikshita@qti.qualcomm.com>,
Renjiang Han <quic_renjiang@quicinc.com>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>,
Daniel J Blueman <daniel@quora.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
Date: Tue, 18 Aug 2026 10:05:13 +0200 [thread overview]
Message-ID: <662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org> (raw)
In-Reply-To: <c339cbff-490e-42fe-a461-042fdd6bfea6@oss.qualcomm.com>
On 18/08/2026 10:00, Vikash Garodia wrote:
>
> On 8/18/2026 1:21 PM, Vikash Garodia wrote:
>>
>> On 8/18/2026 11:53 AM, Dmitry Baryshkov wrote:
>>> On Mon, Aug 17, 2026 at 10:54:47AM +0100, Bryan O'Donoghue wrote:
>>>> On 10/08/2026 14:47, Rob Herring wrote:
>>>>>>> As per the reserved-memory.yaml schema document, the iommu-addresses
>>>>>>> property for IOVA reservation into /reserved-memory is allowed — it's
>>>>>>> documented for IOVA carveout reservations:
>>>>>>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/
>>>>>>> schemas/reserved-memory/reserved-memory.yaml#L56
>>>>>> I think that is an entirely reasonable reading of the text
>>>>>>
>>>>>> Quote:
>>>>>>
>>>>>> "If no "reg" property is specified, the "iommu-addresses" property
>>>>>> defines carveout regions in the IOVA space for the given
>>>>>> device. This
>>>>>> can be useful if a certain memory region should not be mapped
>>>>>> through
>>>>>> the IOMMU."
>>>>>>
>>>>>> Which is exactly what this series does. Excludes a specific IOVA range
>>>>>> from being allocated for this device.
>>>>> But if "iommu-addresses" is the only property of the reserved memory,
>>>>> why put this property in reserved-memory rather than directly in the
>>>>> device's node? I'm only questioning where is the right place to
>>>>> describe a reserved IOVA.
>>>>>
>>>>> Rob
>>>>
>>>> Back from the eclipse, sorry for the delayed response.
>>>>
>>>> Ah I get you.
>>>>
>>>> Yes.
>>>>
>>>> I take your point. This is a property of the node itself; the IOVA <
>>>> 600MB
>>>> only matters _if_ the venus or iris nodes are enabled - otherwise an
>>>> IOVA <
>>>> 600MB is perfectly fine.
>>>>
>>>> So it follows its a property specific to this node not specific to the
>>>> overall system.
>>>>
>>>> Yep, I agree - its a device/node property, not a top-level property.
>>>
>>> :-)
>>>
>>> FWIW, I think it's a proper way to describe it too.
>>>
>>
>> From my readings, a node defined under reserved-memory can have other
>> properties like "reg" alongwith "iommu-addresses". Are we saying when
>> *only* "iommu-addresses" is there, then move to the device and when
>> other property is there, then move to individual device ?
>
> sorry, typo. Pls read the last few words as ".., then keep under
> reserve-memory ?"
>
>>
>> Again the device may have the "reg" property already, in such case,
>> moving the iommu-addresses + reg in corresponding device might not be
>> feasible.
Your sub-devices do not have reg property, so there is no such case,
unless you meant the entire iris node?
Anyway, the point is that this does not describe anyhow system memory,
any reserved memory. You want to affect the device virtual memory
mappings and as such this is a property of the device itself, because
this is how we structure DT. Attributes of devices do not go to
top-level but to the devices themselves as properties.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-08-18 8:05 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5BXSXMNl656WiJPJAMmHvb3I2NzYMshRZuGuub3CxEXvdCUlIDKYbnv5jUq-pa6P1NibBLkO3njnKGxi7Al3jQ==@protonmail.internalid>
2026-08-07 8:24 ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Vikash Garodia
2026-08-07 8:24 ` [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region Vikash Garodia
2026-08-07 8:24 ` [PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: " Vikash Garodia
2026-08-07 9:01 ` Dmitry Baryshkov
2026-08-07 8:24 ` [PATCH 03/22] dt-bindings: media: qcom,sc7180-venus: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris Vikash Garodia
2026-08-07 9:03 ` Dmitry Baryshkov
2026-08-07 9:26 ` Vikash Garodia
2026-08-07 10:00 ` Dmitry Baryshkov
2026-08-07 10:22 ` Vikash Garodia
2026-08-07 13:18 ` Bryan O'Donoghue
2026-08-08 15:48 ` Vikash Garodia
2026-08-10 12:10 ` Dmitry Baryshkov
2026-08-10 16:57 ` Vikash Garodia
2026-08-11 0:17 ` Dmitry Baryshkov
2026-08-12 5:19 ` Bryan O'Donoghue
2026-08-12 11:04 ` Vikash Garodia
2026-08-12 5:02 ` Bryan O'Donoghue
2026-08-12 12:46 ` Dmitry Baryshkov
2026-08-12 15:45 ` Vikash Garodia
2026-08-12 16:24 ` Dmitry Baryshkov
2026-08-07 16:24 ` Rob Herring
2026-08-08 4:37 ` Vishnu Reddy
2026-08-08 9:55 ` Bryan O'Donoghue
2026-08-10 13:47 ` Rob Herring
2026-08-12 15:44 ` Vikash Garodia
2026-08-12 16:09 ` Krzysztof Kozlowski
2026-08-14 11:23 ` Dmitry Baryshkov
2026-08-17 9:54 ` Bryan O'Donoghue
2026-08-18 6:23 ` Dmitry Baryshkov
2026-08-18 7:51 ` Vikash Garodia
2026-08-18 8:00 ` Vikash Garodia
2026-08-18 8:05 ` Krzysztof Kozlowski [this message]
2026-08-07 8:24 ` [PATCH 05/22] arm64: dts: qcom: lemans: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 06/22] arm64: dts: qcom: monaco: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 07/22] arm64: dts: qcom: sc8280xp: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 08/22] arm64: dts: qcom: sm8350: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 09/22] arm64: dts: qcom: sm8550: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 10/22] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 11/22] arm64: dts: qcom: sm8750: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 12/22] arm64: dts: qcom: agatti: Reserve low IOVA range for Venus Vikash Garodia
2026-08-07 8:24 ` [PATCH 13/22] arm64: dts: qcom: kodiak: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 14/22] arm64: dts: qcom: msm8916: " Vikash Garodia
2026-08-07 8:24 ` [PATCH 15/22] arm64: dts: qcom: msm8996: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 16/22] arm64: dts: qcom: msm8998: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 17/22] arm64: dts: qcom: sc7180: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 18/22] arm64: dts: qcom: sdm630: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 19/22] arm64: dts: qcom: sdm845: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 20/22] arm64: dts: qcom: sm6115: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 21/22] arm64: dts: qcom: sm8250: " Vikash Garodia
2026-08-07 8:25 ` [PATCH 22/22] arm64: dts: qcom: talos: " Vikash Garodia
2026-08-07 8:51 ` [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs Bryan O'Donoghue
2026-08-07 8:59 ` Dmitry Baryshkov
2026-08-07 9:05 ` Vikash Garodia
2026-08-07 10:01 ` Dmitry Baryshkov
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=662f7093-fb0a-4564-9ca0-98e03e68ba9a@kernel.org \
--to=krzk@kernel.org \
--cc=abhinav.kumar@linux.dev \
--cc=amasule@codeaurora.org \
--cc=andersson@kernel.org \
--cc=andy.gross@linaro.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bod@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=busanna.reddy@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=daniel@quora.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dikshita.agarwal@oss.qualcomm.com \
--cc=dikshita@qti.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=johan+linaro@kernel.org \
--cc=jonathan@marek.ca \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=mansur@codeaurora.org \
--cc=mchehab+huawei@kernel.org \
--cc=mchehab@kernel.org \
--cc=mgonzalez@freebox.fr \
--cc=mka@chromium.org \
--cc=neil.armstrong@linaro.org \
--cc=phhusson@freebox.fr \
--cc=quic_mgottam@quicinc.com \
--cc=quic_renjiang@quicinc.com \
--cc=quic_rjendra@quicinc.com \
--cc=robh@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sakari.ailus@linux.intel.com \
--cc=sboyd@codeaurora.org \
--cc=stable@vger.kernel.org \
--cc=stanimir.k.varbanov@gmail.com \
--cc=stanimir.varbanov@linaro.org \
--cc=stephan.gerhold@linaro.org \
--cc=vikash.garodia@oss.qualcomm.com \
--cc=y.oudjana@protonmail.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
all inboxes | Powered by JetHome®