On 12/18/25 5:32 AM, 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 ?
I don't know. This is unrelated to the issue this patchset is solving.
> We _already_ have thanks to chromeos a way to define this stuff in venus.
Which was.. heavily debated, let's call it, after Krzysztof noticed it exists
and you agreed it should not spread by leaving your r-b on:
6d3926a237b6 ("dt-bindings: media: qcom,sm8550-iris: Do not reference legacy
venus properties")
> 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.
I think you're replying to the wrong series.
> 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.
>
> 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...
Why should Mukesh be required to carry your burden?
You (as the Iris maintainer) are a consumer of this new set of APIs provided in
this series, so one would expect that you can help test it by creating a
downstream patch (that would be nice to share), rebased on new revisions as
necessary and sharing feedback based on the drawbacks you notice.
> 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.
>
> If not then the conclusion is Iris _won't_ use that solution and we go with
> the previous venus solution.
Because that surely won't get any pushback..
Konrad
> 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.
>
> Either way Iris gets unblocked.
>
> ---
> bod
