[PATCH 0/7] drm/msm/dpu: simplify VBIF handling

Dmitry Baryshkov posted 7 patches 1 month, 2 weeks ago
.../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h    |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_12_0_sm8750.h    |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_12_2_glymur.h    |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_13_0_kaanapali.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h   |   3 +-
.../drm/msm/disp/dpu1/catalog/dpu_1_15_msm8917.h   |   3 +-
.../drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h   |   3 +-
.../drm/msm/disp/dpu1/catalog/dpu_1_7_msm8996.h    |   3 +-
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h    |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_3_3_sdm630.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h    |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_3_sm6150.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h    |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   |   3 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h    |   4 +-
.../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_9_1_sar2130p.h   |   4 +-
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h   |   4 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c    |   7 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c     |  35 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h     |   8 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h        |   6 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c        |   3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h        |   1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c            |  70 +++------
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h            |   4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c          |   5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h          |  19 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c           | 163 ++++++++-------------
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.h           |   4 -
44 files changed, 144 insertions(+), 296 deletions(-)
[PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Dmitry Baryshkov 1 month, 2 weeks ago
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.

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.

The missing features don't match the extra complexity required to
support two VBIF interfaces, so drop the second one and all the options
to support it.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Dmitry Baryshkov (7):
      drm/msm/dpu: drop VBIF_NRT handling
      drm/msm/dpu: stop declaring VBIFs as an array in catalog
      drm/msm/dpu: replace VBIF-related array with bare pointers
      drm/msm/dpu: drop VBIF id, base and name from the catalog
      drm/msm/dpu: drop vbif_idx from WB configuration
      drm/msm/dpu: drop VBIF index from the VBIF params
      drm/msm/dpu: drop VBIF index from the struct dpu_hw_vbif

 .../drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h    |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_12_0_sm8750.h    |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_12_2_glymur.h    |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_13_0_kaanapali.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h   |   3 +-
 .../drm/msm/disp/dpu1/catalog/dpu_1_15_msm8917.h   |   3 +-
 .../drm/msm/disp/dpu1/catalog/dpu_1_16_msm8953.h   |   3 +-
 .../drm/msm/disp/dpu1/catalog/dpu_1_7_msm8996.h    |   3 +-
 .../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h    |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_2_sdm660.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_3_3_sdm630.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_4_1_sdm670.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h    |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_3_sm6150.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h    |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h   |   3 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_8_4_sa8775p.h    |   4 +-
 .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_9_1_sar2130p.h   |   4 +-
 .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h   |   4 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c    |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c     |  35 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h     |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h        |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c        |   3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h        |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c            |  70 +++------
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h            |   4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c          |   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h          |  19 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c           | 163 ++++++++-------------
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.h           |   4 -
 44 files changed, 144 insertions(+), 296 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260219-drop-vbif-nrt-cb7da190f6f4

Best regards,
-- 
With best wishes
Dmitry
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Konrad Dybcio 1 month, 2 weeks ago
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?

Konrad
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Dmitry Baryshkov 1 month, 2 weeks ago
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
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Konrad Dybcio 1 month, 2 weeks ago
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
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Konrad Dybcio 1 month, 2 weeks ago
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.
> 
> 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.
> 
> The missing features don't match the extra complexity required to
> support two VBIF interfaces, so drop the second one and all the options
> to support it.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---

This leaves a trailing 'bool is_rt' in struct dpu_vbif_set_qos_params.

I'm not sure whether/if we're going to use that specific set of functions
with rotator support, but we should probably retain (and at some point
recheck) the dpu_vbif_cfg->qos_nrt_tbl data that the catalog houses

Konrad
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Dmitry Baryshkov 1 month, 2 weeks ago
On Mon, Mar 02, 2026 at 01:45:39PM +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.
> > 
> > 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.
> > 
> > The missing features don't match the extra complexity required to
> > support two VBIF interfaces, so drop the second one and all the options
> > to support it.
> > 
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> 
> This leaves a trailing 'bool is_rt' in struct dpu_vbif_set_qos_params.
> 
> I'm not sure whether/if we're going to use that specific set of functions
> with rotator support, but we should probably retain (and at some point
> recheck) the dpu_vbif_cfg->qos_nrt_tbl data that the catalog houses

is_rt and qos_nrt_tbl are related to the WB support, so they can't go
away.

> 
> Konrad

-- 
With best wishes
Dmitry
Re: [PATCH 0/7] drm/msm/dpu: simplify VBIF handling
Posted by Dmitry Baryshkov 2 weeks, 5 days ago
On Fri, 27 Feb 2026 20:36:39 +0200, 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.
> 
> [...]

Applied to msm-next, thanks!

[1/7] drm/msm/dpu: drop VBIF_NRT handling
      https://gitlab.freedesktop.org/lumag/msm/-/commit/cfb64b092617
[2/7] drm/msm/dpu: stop declaring VBIFs as an array in catalog
      https://gitlab.freedesktop.org/lumag/msm/-/commit/2c0c3d9d95ca
[3/7] drm/msm/dpu: replace VBIF-related array with bare pointers
      https://gitlab.freedesktop.org/lumag/msm/-/commit/014390e30a74
[4/7] drm/msm/dpu: drop VBIF id, base and name from the catalog
      https://gitlab.freedesktop.org/lumag/msm/-/commit/b26bfb5bf1aa
[5/7] drm/msm/dpu: drop vbif_idx from WB configuration
      https://gitlab.freedesktop.org/lumag/msm/-/commit/021fd8ca0cdc
[6/7] drm/msm/dpu: drop VBIF index from the VBIF params
      https://gitlab.freedesktop.org/lumag/msm/-/commit/1ce61688875d
[7/7] drm/msm/dpu: drop VBIF index from the struct dpu_hw_vbif
      https://gitlab.freedesktop.org/lumag/msm/-/commit/7c5166fd79fc

Best regards,
-- 
With best wishes
Dmitry