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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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