Linux Media Controller development
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bod@kernel.org>
To: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
	Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	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>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Subject: Re: [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes
Date: Fri, 10 Jul 2026 14:38:33 +0100	[thread overview]
Message-ID: <1c652464-32b7-4411-8ed2-2885234513cc@kernel.org> (raw)
In-Reply-To: <f0fa6acb-2d70-4154-96e0-09e88af129e3@oss.qualcomm.com>

On 10/07/2026 14:36, Vikash Garodia wrote:
>> What's the addressable range with sub-nodes ?
>>
>> The original problem you were trying to solve was the total addressable
>> size - this other problem here segmenting the linear allocation space is
>> adjacent but not the same thing.
>>
>> Without digging through all of the patches here - my question is does
>> the original sub-node addressable space problem get resolved in your
>> proposal here ?
> The proposal solves both the problem we have so far - total addressable
> size as well as which segment (or range) in that is_not_ addressable.

So if I can distill this.

You're proposing two objects in the DT one for each relevant IOMMU SID 
and then the driver will register two different devices to get the full 
range addresses ?

---
bod

  reply	other threads:[~2026-07-10 13:38 UTC|newest]

Thread overview: 30+ 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: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:35   ` [RFC PATCH 03/11] media: iris: Add helper to create a context bank device Vikash Garodia
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 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 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-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 12:35   ` [RFC PATCH 09/11] arm64: dts: qcom: lemans: " Vikash Garodia
2026-07-09 12:35   ` [RFC PATCH 10/11] arm64: dts: qcom: monaco: " Vikash Garodia
2026-07-09 12:35   ` [RFC PATCH 11/11] arm64: dts: qcom: sm8650: " Vikash Garodia
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 [this message]
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=1c652464-32b7-4411-8ed2-2885234513cc@kernel.org \
    --to=bod@kernel.org \
    --cc=abhinav.kumar@linux.dev \
    --cc=andersson@kernel.org \
    --cc=busanna.reddy@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dikshita.agarwal@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@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=robh@kernel.org \
    --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