From: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Krzysztof Kozlowski <krzk@kernel.org>
Cc: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Bryan O'Donoghue <bod@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Stephan Gerhold <stephan.gerhold@linaro.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
stable@vger.kernel.org, Daniel J Blueman <daniel@quora.org>
Subject: Re: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema
Date: Thu, 6 Aug 2026 17:26:51 +0530 [thread overview]
Message-ID: <d0dfd058-f0a0-41e3-a7ad-89eccd0571cb@oss.qualcomm.com> (raw)
In-Reply-To: <npojagmk7x24wpbqcmzg4mijscqz63aluh6lj5uaciztzl53wl@ld342uighqaa>
On 8/6/2026 4:05 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 06, 2026 at 11:36:45AM +0200, Krzysztof Kozlowski wrote:
>> On 06/08/2026 11:22, Dmitry Baryshkov wrote:
>>> On Thu, Aug 06, 2026 at 11:11:09AM +0200, Krzysztof Kozlowski wrote:
>>>> On 06/08/2026 10:46, Dmitry Baryshkov wrote:
>>>>>
>>>>>> dma-ranges tell how this bus - so venus/iris - performs DMA translation
>>>>>> in respective to parent. Address/size-cells are obviously also needed if
>>>>>> this is a bus with addressing.
>>>>>>
>>>>>> But there are no children with addressing, thus what sort of bus would
>>>>>> it be?
>>>>>>
>>>>>> It looks to me that having here both:
>>>>>> 1. dma-ranges + address/size-cells
>>>>>> 2. children without bus addressing
>>>>>> is some sort of abuse of the DT syntax. It is allowed, but does not
>>>>>> really represent hardware.
>>>>>>
>>>>>> IOW, dma-ranges alone feels okay, although unusual, and it states proper
>>>>>> DMA translation for this bus. If you add address/size-cells, it means
>>>>>> this bus HAS addressing and thus YOU MUST use addressing.
>>>>>>
>>>>>> If my understanding is correct, then solution would be to add addressing
>>>>>> to the children (so unit address and "reg" property) or drop
>>>>>> address/size-cells as Rob pointed out. [1]
>>>>>
>>>>> Doesn't dma-ranges require address/size cells? In the end, how can you
>>>>
>>>> I think it does not require, at least how I understood the DT spec,
>>>> unless you provide actual addresses to the property.
>>>>
>>>> IOW, this requires address/size-cells:
>>>> dma-ranges = <0 0 0 0 0x10 0>;
>>>>
>>>>> specify the DMA address if the device doesn't have addressing at all (or
>>>>> MMIO-style addressing)?
>>>>
>>>> Yeah, that's why having here children without bus addressing is
>>>> confusing. I would interpret it that, children are not on MMIO bus, thus
>>>> the venus/iris is some sort of proprietary bus with no mapping between
>>>> parent MMIO and children nodes.
>>>>
>>>> If there is no mapping, then we do not have 'ranges' property. But I
>>>> could imagine that such no-mapping bus still provides access to system RAM?
>>>>
>>>> Actually this feels like a huge stretch, so I tend to think that the
>>>> only reasonable option is to have children with MMIO, which would make
>>>> it explicit: Venus/iris is a bus which provides translation of both MMIO
>>>> and DMA addresses to the parent.
>>>
>>> But there are no separate addresses for those subnodes. Would you prefer
>>
>> There might be some or maybe these should be the addresses of DMA?
>>
>>> them to duplicate the addresses of the parent node? Or would the
>>> 'ranges' be enough?
>>
>> I made mistake earlier - 'dma-ranges' without values is not described in
>> DT spec explicitly, but should be treated as 'ranges' without values,
>> thus direct mapping from parent to the child.
>
> Documentation/devicetree/bindings/iommu/iommu.txt:
>
> An empty "dma-ranges" property means that there is a 1:1 mapping from
> IOMMU to memory.
>
>>
>> So it also requires address/size-cells, just like 'dma-ranges =
>> <mapping>'. And dtc checks/reports that.
>>
>> I think therefore now that the binding is unusual (because no bus
>> addresses of children) but actually correct.
>>
>>>
>>> Or, thinking about it, if Venus / Iris have 32-bit addressing, then
>>> dma-range should probably define the limited DMA range.
>>
>> That's another point which I also raised to Vikash already - mapping
>> should be restricted to 32-bit if this is how the child devices operate.
>
> Souds so. Then we need a non-empty dma-ranges.
>
>
based on this discussion, below works for schema check and dtc
schema:
'#address-cells':
const: 1
'#size-cells':
const: 1
dma-ranges:
maxItems: 1
Now in the schema examples, soc is added to match the reg/dma-ranges of
parent (iris)
examples
soc {
#address-cells = <2>;
#size-cells = <2>;
video-codec@aa00000 {
compatible = "qcom,sm8550-iris";
reg = <0x0 0x0aa00000 0x0 0xf0000>;
DTS
iris {
....
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x0 0x0 0x0 0xe0000000>;
iris_non_pixel: non-pixel {
iommus = <&apps_smmu 0x1940 0x0>;
memory-region = <&iris_resv>;
};
pixel {
iommus = <&apps_smmu 0x1947 0x0>;
};
Please review if anything is missed out.
Regards,
Vikash
next prev parent reply other threads:[~2026-08-06 11:57 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 18:22 [PATCH v2 00/12] media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-07-31 18:22 ` [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema Vikash Garodia
2026-07-31 18:36 ` sashiko-bot
2026-08-01 10:06 ` Bryan O'Donoghue
2026-08-06 5:21 ` Vikash Garodia
2026-08-06 7:54 ` Bryan O'Donoghue
2026-08-06 7:57 ` Vikash Garodia
2026-08-06 9:40 ` Bryan O'Donoghue
2026-08-06 10:07 ` Bryan O'Donoghue
2026-08-06 10:14 ` Krzysztof Kozlowski
2026-08-06 10:24 ` Bryan O'Donoghue
2026-08-06 10:32 ` Krzysztof Kozlowski
2026-08-06 10:50 ` Bryan O'Donoghue
2026-08-06 11:14 ` Dmitry Baryshkov
2026-08-06 11:19 ` Bryan O'Donoghue
2026-08-06 12:20 ` Vikash Garodia
2026-08-05 7:21 ` Krzysztof Kozlowski
2026-08-05 10:37 ` Krzysztof Kozlowski
2026-08-06 8:46 ` Dmitry Baryshkov
2026-08-06 9:11 ` Krzysztof Kozlowski
2026-08-06 9:20 ` Krzysztof Kozlowski
2026-08-06 9:22 ` Dmitry Baryshkov
2026-08-06 9:36 ` Krzysztof Kozlowski
2026-08-06 10:35 ` Dmitry Baryshkov
2026-08-06 11:56 ` Vikash Garodia [this message]
2026-08-06 12:10 ` Dmitry Baryshkov
2026-08-06 8:49 ` Dmitry Baryshkov
2026-08-06 9:52 ` Vikash Garodia
2026-08-06 10:38 ` Dmitry Baryshkov
2026-07-31 18:22 ` [PATCH v2 02/12] dt-bindings: media: qcom,sm8550-iris: Add context bank subnodes Vikash Garodia
2026-07-31 18:31 ` sashiko-bot
2026-07-31 20:36 ` Rob Herring (Arm)
2026-08-06 8:51 ` Dmitry Baryshkov
2026-08-05 7:21 ` Krzysztof Kozlowski
2026-07-31 18:22 ` [PATCH v2 03/12] media: iris: Add platform hooks for context bank device setup Vikash Garodia
2026-07-31 18:36 ` sashiko-bot
2026-08-06 8:53 ` Dmitry Baryshkov
2026-07-31 18:22 ` [PATCH v2 04/12] media: iris: Add helper to create a context bank device Vikash Garodia
2026-08-06 8:57 ` Dmitry Baryshkov
2026-08-06 10:08 ` Vikash Garodia
2026-08-06 10:18 ` Krzysztof Kozlowski
2026-07-31 18:22 ` [PATCH v2 05/12] media: iris: Route buffers to the matching " Vikash Garodia
2026-07-31 18:57 ` sashiko-bot
2026-08-06 9:03 ` Dmitry Baryshkov
2026-07-31 18:22 ` [PATCH v2 06/12] media: iris: Skip DMA mask setup when the core device has no IOMMU Vikash Garodia
2026-07-31 18:43 ` sashiko-bot
2026-07-31 18:22 ` [PATCH v2 07/12] media: iris: Create pixel and non-pixel context banks on VPU3x Vikash Garodia
2026-07-31 18:41 ` sashiko-bot
2026-08-06 9:07 ` Dmitry Baryshkov
2026-08-06 10:06 ` Vikash Garodia
2026-08-06 10:53 ` Dmitry Baryshkov
2026-07-31 18:22 ` [PATCH v2 08/12] arm64: dts: qcom: hamoa: Add Iris context bank subnodes Vikash Garodia
2026-07-31 18:22 ` [PATCH v2 09/12] arm64: dts: qcom: sm8550: " Vikash Garodia
2026-07-31 18:38 ` sashiko-bot
2026-07-31 18:22 ` [PATCH v2 10/12] arm64: dts: qcom: lemans: " Vikash Garodia
2026-07-31 18:22 ` [PATCH v2 11/12] arm64: dts: qcom: monaco: " Vikash Garodia
2026-07-31 18:22 ` [PATCH v2 12/12] arm64: dts: qcom: sm8650: " 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=d0dfd058-f0a0-41e3-a7ad-89eccd0571cb@oss.qualcomm.com \
--to=vikash.garodia@oss.qualcomm.com \
--cc=abhinav.kumar@linux.dev \
--cc=andersson@kernel.org \
--cc=bod@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=daniel@quora.org \
--cc=devicetree@vger.kernel.org \
--cc=dikshita.agarwal@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=robh@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stanimir.varbanov@linaro.org \
--cc=stephan.gerhold@linaro.org \
/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