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. 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/[email protected]/ > > 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 -- -Mukesh Ojha
