All of lore.kernel.org
 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 11:35:57 +0100	[thread overview]
Message-ID: <c5d190dc-1ba8-4cdf-ad8d-2f86fef4c93f@kernel.org> (raw)
In-Reply-To: <20260709-vpu_iommu_iova_handling-v1-0-72bb62cb2dfd@oss.qualcomm.com>

On 09/07/2026 13:35, Vikash Garodia wrote:
> Mapping a stream outside its expected range can cause unintended
> behavior, including device crashes, as reported at:
> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> 
> Daniel, who reported the crash issue, have also raised a patch to workaround
> the issue. While the patch partially handles the limitation, it is inefficient
> in a way that it keep iris hardwares away from using the 600MB address space
> for all the different streams.
> 
> To address this limitation, the subset of stream/s are now represented as
> sub nodes, so that they can be associated to the respective addressable
> range.
> In the past, this limitation was tried with iommu-map approach, with iris
> driver dynamically creating the devices. The approach was later concluded
> as an hack to avoid having sub nodes. It was discussed in detail in the
> discussionhttps://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
> 
> It was agreed by maintainers to proceed with sub node approach to address
> the VPU hardware limitation.

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 ?

---
bod

  parent reply	other threads:[~2026-07-10 10:36 UTC|newest]

Thread overview: 57+ 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-14 13:49       ` 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 13:43     ` sashiko-bot
2026-07-14 13:48       ` Vikash Garodia
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-14  7:23         ` Vikash Garodia
2026-07-14 13:39       ` Vikash Garodia
2026-07-14 13:43       ` Vikash Garodia
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
2026-07-14 13:02       ` Vikash Garodia
2026-07-10 10:48     ` Bryan O'Donoghue
2026-07-10 22:46     ` Bryan O'Donoghue
2026-07-12 12:19       ` Dmitry Baryshkov
2026-07-13  6:02         ` Vikash Garodia
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-14 13:01       ` Vikash Garodia
2026-07-09 12:35   ` [RFC PATCH 09/11] arm64: dts: qcom: lemans: " Vikash Garodia
2026-07-09 14:44     ` sashiko-bot
2026-07-14 11:08       ` Vikash Garodia
2026-07-09 12:35   ` [RFC PATCH 10/11] arm64: dts: qcom: monaco: " Vikash Garodia
2026-07-09 15:03     ` sashiko-bot
2026-07-14 11:07       ` Vikash Garodia
2026-07-09 12:35   ` [RFC PATCH 11/11] arm64: dts: qcom: sm8650: " Vikash Garodia
2026-07-09 15:29     ` sashiko-bot
2026-07-14 11:06       ` Vikash Garodia
2026-07-10 10:35   ` Bryan O'Donoghue [this message]
2026-07-10 13:36     ` [RFC PATCH 00/11] : media: iris: Migrate iommus to iris sub nodes Vikash Garodia
2026-07-10 13:38       ` Bryan O'Donoghue
2026-07-10 14:02         ` Vikash Garodia
2026-07-12 12:24           ` Dmitry Baryshkov
2026-07-13  5:59             ` Vikash Garodia
2026-07-12 11:51   ` Daniel J Blueman
2026-07-13  5:53     ` 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=c5d190dc-1ba8-4cdf-ad8d-2f86fef4c93f@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.