Message-ID: <mb2bv5oipbu2ibvxywgmjw3szzk2vulqxocgasxaxhgsxpblgy@mt55znew76ps>
Date: Thu, 18 Dec 2025 08:45:34 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Bryan O'Donoghue <bod@...nel.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, 
	Vikash Garodia <vikash.garodia@....qualcomm.com>, Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 
	Mukesh Ojha <mukesh.ojha@....qualcomm.com>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, 
	Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Manivannan Sadhasivam <mani@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm
 SoCs running Linux host at EL2

On Thu, Dec 18, 2025 at 04:32:01AM +0000, Bryan O'Donoghue wrote:
> On 17/12/2025 11:43, Konrad Dybcio wrote:
> > On 12/17/25 11:08 AM, Vikash Garodia wrote:
> > > 
> > > On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
> > > > On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
> > > > > 
> > > > > On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
> > > > > > On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
> > > > > > > 
> > > > > > > On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> > > > > > > > On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> > > > > > > > > On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > > > > > > > > > Sorry.
> > > > > > > > > > > 
> > > > > > > > > > > Did we actually come up with a cogent reason to omit the video firmware
> > > > > > > > > > > loading here ?
> > > > > > > > > > > 
> > > > > > > > > > > AFAIU it is required for Lemans and Glymur - leaving it out is blocking
> > > > > > > > > > > getting video stuff done and storing up trouble.
> > > > > > > > > > > 
> > > > > > > > > > > What exactly is the blockage - is it something you want help with ?
> > > > > > > > > > I replied to you here[1] and given my reason..till something concluded on
> > > > > > > > > > "multi-cell IOMMU[2]", I can not add video and block what is working
> > > > > > > > > > already.
> > > > > > > > > > 
> > > > > > > > > > [1]
> > > > > > > > > > https://lore.kernel.org/lkml/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > > > > > > > > > hyd.qualcomm.com/
> > > > > > > > > 
> > > > > > > > > Why though ?
> > > > > > > > > 
> > > > > > > > > You are mixing together the issue of multiple SIDs and the original loading
> > > > > > > > > of firmware which could easily reuse the venus method of
> > > > > > > > > 
> > > > > > > > > &iris {
> > > > > > > > >      video-firmware {
> > > > > > > > >          iommus = <&apss_smmu hex>;
> > > > > > > > >      };
> > > > > > > > > };
> > > > > > > > 
> > > > > > > > I completely understand what you are saying, and it would be very easy
> > > > > > > > for me to do that if it gets accepted. However, I doubt that the people
> > > > > > > > who raised this concern would agree with the approach.
> > > > > > > > 
> > > > > > > > I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> > > > > > > > banks separately. I’ll leave this to @Vikas to answer.
> > > > > > > 
> > > > > > > Not exactly as a separate sub-node, but i do like the idea of introducing a
> > > > > > > simple iommu property, something like this, which Stephan proposed earlier
> > > > > > > in the discussion [1]
> > > > > > > 
> > > > > > > firmware-iommus = <&apps_smmu ...>;
> > > > > > > 
> > > > > > > I understand that we are doing the iommu-map thing, but a property
> > > > > > > exclusively for firmware like above look much simpler to me.
> > > > > > > 
> > > > > > 
> > > > > > "We know we need to find a generic solution to this very problem, but
> > > > > > while we work on that let's add this quick hack to the ABI"?
> > > > > 
> > > > > I would not call that as hack, rather a simpler solution instead of packing
> > > > > everything into the generic iommu-map.
> > > > > 
> > > > > "firmware-iommus" is much more readable to interpret something running in
> > > > > el2 mode, than digging into function ids inside iommu-map and then matching
> > > > > it up with specific SIDs to confirm.
> > > > 
> > > > If you want it formally, NAK from my side for firmware-iommus. Either
> > > > reuse an existing approach (at least it makese sense from the historical
> > > > point of view) or introduce a generic approach, which is iommu-maps. The
> > > > proposed firmware-iommus is definitely a hack around the IOMMU
> > > > properties.
> > > > 
> > > > But it's really off-topic here.
> > > 
> > > Infact i see a concern with the iommu-map approach for firmware SIDs. Let say the hardware generates 10 SIDs, including firmware. So video binding should describe those 10 SIDs and the DTS should have all those 10 SIDs as well, including firmware SID.
> > > Given above, video driver cannot distinguish if the SOC is running in EL2 (KVM) mode or Gunyah mode.
> > 
> > EL2 vs Gunyah is not hard (something like is_hyp_mode_available()), but
> > again, this should all be calling some sort of is_gunyah() which would
> > come from the gunyah hyp drivers, which have seen no activity on lkml
> > for over a year..
> > 
> > Konrad
> 
> What exactly is the status of the iommu-map stuff and when is it likely to
> land ?
> 
> We _already_ have thanks to chromeos a way to define this stuff in venus.
> 

And we already know that the way we do iommu definitions for both venus
and iris is broken (the non-firmware part).

> My €0.02 is 100% fine with iommu-map as a solution for VPU but then,
> actually want to see it as part of the series solving the problem.
> 
> Else, we should reuse the venus approach.
> 
> Right now we have the worst of both worlds. Iris is blocked waiting on
> iommu-map but the iommu-map series has dropped Iris support because -
> reasons.
> 
> The very definition of being stuck between a rock and a hard place.
> 
> @Mukesh - can you add Iris support back into the series ? If so then is it
> perfectly reasonable to proceed with iommu-map for Iris.

Please no, this series adds remoteproc support and I think we're ready
to merge the next iteration thereof. There's no reason to conflate the
two topics and delay the introduction of the remoteprocs.

> 
> If not then we should just reuse the approach we have.
> 
> Either way I regard this series as broken right now, as it applies a
> solution that excludes one of the primary users of that solution with no
> view as to when that user gets enabled, worse still it requires adaptation
> to the new solution but the proposer won't do that work...

Yes, it requires adaptation, but that's not because of this series, but
because the world has changed.

> 
> It places Iris in a very invidious position.
> 
> So again I think if we can agree to add Iris support back into this series
> then we should go ahead with implementing in Iris.

No, we can merge this series and then turn around and decide to do
exactly what you suggest without further delays - if that's what we
want.

> 
> If not then the conclusion is Iris _won't_ use that solution and we go with
> the previous venus solution.
> 
> Either way, the proposed series as is, is an effective blocker for Iris so
> I'd like a commitment either to re-add or we agree it won't be added at all.
> 

Perhaps I'm misunderstanding what you're saying. How is this blocking
iris support? It adds the support pieces and doesn't touch iris, afaict
the thing blocking iris support is the agreement on how to model the
iommu for iris.

Regards,
Bjorn

> Either way Iris gets unblocked.
> 
> ---
> bod

Powered by blists - more mailing lists