On 3/2/26 1:33 PM, Dmitry Baryshkov wrote: > On Mon, Mar 02, 2026 at 12:58:42PM +0100, Konrad Dybcio wrote: >> On 2/27/26 7:36 PM, Dmitry Baryshkov wrote: >>> Once Konrad asked, what is the use for VBIF_NRT. Answering to his >>> question revealed that it's not actually used by the DPU driver. >>> >>> There are two VBIF interfaces two memory, VBIF_RT and VBIF_NRT with >>> VBIF_NRT being used only for the offscreen rotator, a separate block >>> performing writeback operation with the optional 90 degree rotation. >>> This block will require a separate isntance of the DPU driver, and it is >>> not supported at this point. >> >> (in case someone interested is reading this - patches welcome!) >> >>> The only exception to that rule is MSM8996, where VBIF_NRT has also been >>> used for outputting all writeback data. The DPU driver don't support WB >>> on that platform and most likely will not in the close feature. >> >> Unfortunately, it seems that way. Fortunately, it seems like it's indeed >> isolated to MSM8996. >> >> This patchset is tearing out a lot of abstraction (which would only be >> useful for that SoC though) - if someone decides to work on it, do you >> think this should be effectively reverted, or should the NRT VBIF be >> instantiated in some other, more locallized way? > > I think it should be added as a separate vbif_nrt, added and handled > without touching the main catalog. The main difference point, xin_id, is > still in place, it will be easy to add dpu_kms->vbif_nrt as a > first-class object (instead of forcing the complexity of > vbif[VBIF_MAX]). In such a case I'd prefer if calling code passes VBIF > directly to dpu_vbif_set_*() functions instead of passing the index (or > it might be easier to have a separate wrapper around those functions). > > My opinion is that if something isn't applicable to 99% of cases, those > 99% should not care about the remaining 1% usecase.
Sure, that makes sense. I wanted to make sure your opinion is put in writing for the aforementioned "someone comes around to hack on this" case Konrad
