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
