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. > > > 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/[email protected]/ > > > > > > > > > > > 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 > > > > > > > > -- With best wishes Dmitry
