Re: [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2

[Bryan O'Donoghue <bod@kernel.org>]

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.

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.

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...

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.

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