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

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

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.

>> Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back video
>> in this series. Please share your thoughts on this.
>>
> 
> Please let's keep these concerns separate, so that we don't hold this
> series up further. Even if we choose to go by the subnode approach, in
> the same time frame, it's better to discuss it separately.
> 

ACK.

> Regards,
> Bjorn
> 
>> Regards,
>> Vikash
>>
>> [1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
>>
>>>
>>> Also, I do not want the video PIL discussion to be part of this series, as it could
>>> unnecessarily give the impression that this series depends on it.
>>>
>>>>
>>>> That binding got dropped because it was unused in Iris.
>>>>
>>>> https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
>>>>
>>>> I still fail to see why we are waiting for multi-cell IOMMU to land, when it
>>>> is expected to and what the VPU enablement story is upstream in the
>>>> meantime.
>>>>
>>>> Blocked it seems.
>>>
>>> No, it is ongoing, there will be next version coming.
>>>
>>>>
>>>> ---
>>>> bod
>>>
>>