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. -- With best wishes Dmitry
