drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 314 ------------------------------- drivers/gpu/drm/msm/msm_drv.c | 16 +- 2 files changed, 13 insertions(+), 317 deletions(-)
Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support
by both DPU and MDP5 drivers. Support for them in the DPU driver is
mature enough, so it's no longer sensible to keep them enabled in the
MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible
string. Drop support for the MDP5 3.x genration inside the MDP5
driver and migrate those to the DPU driver only.
Note: this will break if one uses the DT generated before v6.3 as they
had only the generic, "qcom,mdp5" compatible string for SDM630 and
SDM660. However granted that we had two LTS releases inbetween I don't
think it is an issue.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 314 -------------------------------
drivers/gpu/drm/msm/msm_drv.c | 16 +-
2 files changed, 13 insertions(+), 317 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index df464f7c05bf..69fef034d0df 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -1097,310 +1097,6 @@ static const struct mdp5_cfg_hw msm8937_config = {
.max_clk = 320000000,
};
-static const struct mdp5_cfg_hw msm8998_config = {
- .name = "msm8998",
- .mdp = {
- .count = 1,
- .caps = MDP_CAP_DSC |
- MDP_CAP_CDM |
- MDP_CAP_SRC_SPLIT |
- 0,
- },
- .ctl = {
- .count = 5,
- .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
- .flush_hw_mask = 0xf7ffffff,
- },
- .pipe_vig = {
- .count = 4,
- .base = { 0x04000, 0x06000, 0x08000, 0x0a000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_CSC |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_rgb = {
- .count = 4,
- .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_dma = {
- .count = 2, /* driver supports max of 2 currently */
- .base = { 0x24000, 0x26000, 0x28000, 0x2a000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_cursor = {
- .count = 2,
- .base = { 0x34000, 0x36000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- MDP_PIPE_CAP_CURSOR |
- 0,
- },
-
- .lm = {
- .count = 6,
- .base = { 0x44000, 0x45000, 0x46000, 0x47000, 0x48000, 0x49000 },
- .instances = {
- { .id = 0, .pp = 0, .dspp = 0,
- .caps = MDP_LM_CAP_DISPLAY |
- MDP_LM_CAP_PAIR, },
- { .id = 1, .pp = 1, .dspp = 1,
- .caps = MDP_LM_CAP_DISPLAY, },
- { .id = 2, .pp = 2, .dspp = -1,
- .caps = MDP_LM_CAP_DISPLAY |
- MDP_LM_CAP_PAIR, },
- { .id = 3, .pp = -1, .dspp = -1,
- .caps = MDP_LM_CAP_WB, },
- { .id = 4, .pp = -1, .dspp = -1,
- .caps = MDP_LM_CAP_WB, },
- { .id = 5, .pp = 3, .dspp = -1,
- .caps = MDP_LM_CAP_DISPLAY, },
- },
- .nb_stages = 8,
- .max_width = 2560,
- .max_height = 0xFFFF,
- },
- .dspp = {
- .count = 2,
- .base = { 0x54000, 0x56000 },
- },
- .ad = {
- .count = 3,
- .base = { 0x78000, 0x78800, 0x79000 },
- },
- .pp = {
- .count = 4,
- .base = { 0x70000, 0x70800, 0x71000, 0x71800 },
- },
- .cdm = {
- .count = 1,
- .base = { 0x79200 },
- },
- .dsc = {
- .count = 2,
- .base = { 0x80000, 0x80400 },
- },
- .intf = {
- .base = { 0x6a000, 0x6a800, 0x6b000, 0x6b800, 0x6c000 },
- .connect = {
- [0] = INTF_eDP,
- [1] = INTF_DSI,
- [2] = INTF_DSI,
- [3] = INTF_HDMI,
- },
- },
- .max_clk = 412500000,
-};
-
-static const struct mdp5_cfg_hw sdm630_config = {
- .name = "sdm630",
- .mdp = {
- .count = 1,
- .caps = MDP_CAP_CDM |
- MDP_CAP_SRC_SPLIT |
- 0,
- },
- .ctl = {
- .count = 5,
- .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
- .flush_hw_mask = 0xf4ffffff,
- },
- .pipe_vig = {
- .count = 1,
- .base = { 0x04000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_CSC |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_rgb = {
- .count = 4,
- .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_dma = {
- .count = 2, /* driver supports max of 2 currently */
- .base = { 0x24000, 0x26000, 0x28000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_cursor = {
- .count = 1,
- .base = { 0x34000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- MDP_PIPE_CAP_CURSOR |
- 0,
- },
-
- .lm = {
- .count = 2,
- .base = { 0x44000, 0x46000 },
- .instances = {
- { .id = 0, .pp = 0, .dspp = 0,
- .caps = MDP_LM_CAP_DISPLAY |
- MDP_LM_CAP_PAIR, },
- { .id = 1, .pp = 1, .dspp = -1,
- .caps = MDP_LM_CAP_WB, },
- },
- .nb_stages = 8,
- .max_width = 2048,
- .max_height = 0xFFFF,
- },
- .dspp = {
- .count = 1,
- .base = { 0x54000 },
- },
- .ad = {
- .count = 2,
- .base = { 0x78000, 0x78800 },
- },
- .pp = {
- .count = 3,
- .base = { 0x70000, 0x71000, 0x72000 },
- },
- .cdm = {
- .count = 1,
- .base = { 0x79200 },
- },
- .intf = {
- .base = { 0x6a000, 0x6a800 },
- .connect = {
- [0] = INTF_DISABLED,
- [1] = INTF_DSI,
- },
- },
- .max_clk = 412500000,
-};
-
-static const struct mdp5_cfg_hw sdm660_config = {
- .name = "sdm660",
- .mdp = {
- .count = 1,
- .caps = MDP_CAP_DSC |
- MDP_CAP_CDM |
- MDP_CAP_SRC_SPLIT |
- 0,
- },
- .ctl = {
- .count = 5,
- .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
- .flush_hw_mask = 0xf4ffffff,
- },
- .pipe_vig = {
- .count = 2,
- .base = { 0x04000, 0x6000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_CSC |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_rgb = {
- .count = 4,
- .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SCALE |
- MDP_PIPE_CAP_DECIMATION |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_dma = {
- .count = 2, /* driver supports max of 2 currently */
- .base = { 0x24000, 0x26000, 0x28000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- 0,
- },
- .pipe_cursor = {
- .count = 1,
- .base = { 0x34000 },
- .caps = MDP_PIPE_CAP_HFLIP |
- MDP_PIPE_CAP_VFLIP |
- MDP_PIPE_CAP_SW_PIX_EXT |
- MDP_PIPE_CAP_CURSOR |
- 0,
- },
-
- .lm = {
- .count = 4,
- .base = { 0x44000, 0x45000, 0x46000, 0x49000 },
- .instances = {
- { .id = 0, .pp = 0, .dspp = 0,
- .caps = MDP_LM_CAP_DISPLAY |
- MDP_LM_CAP_PAIR, },
- { .id = 1, .pp = 1, .dspp = 1,
- .caps = MDP_LM_CAP_DISPLAY, },
- { .id = 2, .pp = 2, .dspp = -1,
- .caps = MDP_LM_CAP_DISPLAY |
- MDP_LM_CAP_PAIR, },
- { .id = 3, .pp = 3, .dspp = -1,
- .caps = MDP_LM_CAP_WB, },
- },
- .nb_stages = 8,
- .max_width = 2560,
- .max_height = 0xFFFF,
- },
- .dspp = {
- .count = 2,
- .base = { 0x54000, 0x56000 },
- },
- .ad = {
- .count = 2,
- .base = { 0x78000, 0x78800 },
- },
- .pp = {
- .count = 5,
- .base = { 0x70000, 0x70800, 0x71000, 0x71800, 0x72000 },
- },
- .cdm = {
- .count = 1,
- .base = { 0x79200 },
- },
- .dsc = {
- .count = 2,
- .base = { 0x80000, 0x80400 },
- },
- .intf = {
- .base = { 0x6a000, 0x6a800, 0x6b000, 0x6b800 },
- .connect = {
- [0] = INTF_DISABLED,
- [1] = INTF_DSI,
- [2] = INTF_DSI,
- [3] = INTF_HDMI,
- },
- },
- .max_clk = 412500000,
-};
-
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = &msm8x74v1_config } },
{ .revision = 1, .config = { .hw = &msm8x26_config } },
@@ -1416,12 +1112,6 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 16, .config = { .hw = &msm8x53_config } },
};
-static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
- { .revision = 0, .config = { .hw = &msm8998_config } },
- { .revision = 2, .config = { .hw = &sdm660_config } },
- { .revision = 3, .config = { .hw = &sdm630_config } },
-};
-
const struct mdp5_cfg_hw *mdp5_cfg_get_hw_config(struct mdp5_cfg_handler *cfg_handler)
{
return cfg_handler->config.hw;
@@ -1455,10 +1145,6 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms *mdp5_kms,
cfg_handlers = cfg_handlers_v1;
num_handlers = ARRAY_SIZE(cfg_handlers_v1);
break;
- case 3:
- cfg_handlers = cfg_handlers_v3;
- num_handlers = ARRAY_SIZE(cfg_handlers_v3);
- break;
default:
DRM_DEV_ERROR(dev->dev, "unexpected MDP major version: v%d.%d\n",
major, minor);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7e977fec4100..abee7149a9e8 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -960,23 +960,33 @@ static bool prefer_mdp5 = true;
MODULE_PARM_DESC(prefer_mdp5, "Select whether MDP5 or DPU driver should be preferred");
module_param(prefer_mdp5, bool, 0444);
+/* list all platforms that have been migrated from mdp5 to dpu driver */
+static const char *const msm_mdp5_dpu_migrated[] = {
+ /* there never was qcom,msm8998-mdp5 */
+ "qcom,sdm630-mdp5",
+ "qcom,sdm660-mdp5",
+ NULL
+};
+
/* list all platforms supported by both mdp5 and dpu drivers */
static const char *const msm_mdp5_dpu_migration[] = {
"qcom,msm8917-mdp5",
"qcom,msm8937-mdp5",
"qcom,msm8953-mdp5",
"qcom,msm8996-mdp5",
- "qcom,sdm630-mdp5",
- "qcom,sdm660-mdp5",
NULL,
};
bool msm_disp_drv_should_bind(struct device *dev, bool dpu_driver)
{
- /* If it is not an MDP5 device, do not try MDP5 driver */
+ /* If it is not an MDP5 device, use DPU */
if (!of_device_is_compatible(dev->of_node, "qcom,mdp5"))
return dpu_driver;
+ /* If it is no longer supported by MDP5, use DPU */
+ if (of_device_compatible_match(dev->of_node, msm_mdp5_dpu_migrated))
+ return dpu_driver;
+
/* If it is not in the migration list, use MDP5 */
if (!of_device_compatible_match(dev->of_node, msm_mdp5_dpu_migration))
return !dpu_driver;
---
base-commit: f2d03d96ebe8f6948cea9a47d11728f42d62d0f9
change-id: 20250926-mdp5-drop-dpu3-38bc04d44103
Best regards,
--
With best wishes
DmitryOn 11.12.2025 04:25, Dmitry Baryshkov wrote: > Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support > by both DPU and MDP5 drivers. Support for them in the DPU driver is > mature enough, so it's no longer sensible to keep them enabled in the > MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible > string. Drop support for the MDP5 3.x genration inside the MDP5 > driver and migrate those to the DPU driver only. > > Note: this will break if one uses the DT generated before v6.3 as they > had only the generic, "qcom,mdp5" compatible string for SDM630 and > SDM660. However granted that we had two LTS releases inbetween I don't > think it is an issue. > I've retested DPU driver on our downstream release based on 6.18 (by using msm.prefer_mdp5=false kernel cmdline parameter) on all devices at my disposal, and I can confirm DPU driver working fine an all SDM660, SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer (Sony Xperia XA2): [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops dsi_ops [msm]) [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to opp-supp-hw 0x4 [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops a3xx_ops [msm]) [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller on minor 1 ... [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu error]enc33 intf1 ctl start interrupt wait failed [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for commit done returned -22 ... [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu error]enc33 intf1 ctl start interrupt wait failed [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for commit done returned -22 Which results in horrendous ~3-5 fps in shell. The block "enc33 intf1 ctl start interrupt wait failed" + "wait for commit done returned -22" is repeated few times per second whenever the display is turned on, and stops when it's turned off. Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). Well, as fine as possible considering [1], using several FD_MESA_DEBUG tricks to work around GPU issues. P.S. I have not yet tested MSM8998, but I can try if required [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/8442 -- Regards, Alexey Minnekhanov
On Wed, Dec 17, 2025 at 06:05:31PM +0300, Alexey Minnekhanov wrote: > On 11.12.2025 04:25, Dmitry Baryshkov wrote: > > Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support > > by both DPU and MDP5 drivers. Support for them in the DPU driver is > > mature enough, so it's no longer sensible to keep them enabled in the > > MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible > > string. Drop support for the MDP5 3.x genration inside the MDP5 > > driver and migrate those to the DPU driver only. > > > > Note: this will break if one uses the DT generated before v6.3 as they > > had only the generic, "qcom,mdp5" compatible string for SDM630 and > > SDM660. However granted that we had two LTS releases inbetween I don't > > think it is an issue. > > > > I've retested DPU driver on our downstream release based on 6.18 (by > using msm.prefer_mdp5=false kernel cmdline parameter) on all devices > at my disposal, and I can confirm DPU driver working fine an all SDM660, > SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer > (Sony Xperia XA2): Unfortunately I only have SDM660 and video DSI usecase here. BTW: is your SDM636 / SDM660 using CMD or video panel? > > [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops > dsi_ops [msm]) > [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to > opp-supp-hw 0x4 > [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops > a3xx_ops [msm]) > [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 > [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller > on minor 1 > ... > [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > error]enc33 intf1 ctl start interrupt wait failed > [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > commit done returned -22 > ... > [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > error]enc33 intf1 ctl start interrupt wait failed > [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > commit done returned -22 > > Which results in horrendous ~3-5 fps in shell. > > The block "enc33 intf1 ctl start interrupt wait failed" + "wait for > commit done returned -22" is repeated few times per second whenever > the display is turned on, and stops when it's turned off. > > Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). It's interesting. Would you please capture the devcoredump for the platform? There will be a lot of blocks, I'm interested in INTF_1, CTL and top_0. Also, as a debugging check, would you mind patching dpu_encoder_phys_cmd_wait_for_commit_done() so that it always calls dpu_encoder_phys_cmd_wait_for_tx_complete()? I will check if there are any differences for CTL_START and similar registers, but it will take some time. > Well, as fine as possible considering [1], using several FD_MESA_DEBUG > tricks to work around GPU issues. > > P.S. I have not yet tested MSM8998, but I can try if required As far as I remember, MDP5 on MSM8998 has never been wired (as in never committed to the DTSI). Angelo has enabled and Freebox people have tested DPU on MSM8998, but I think it was limited to video / HDMI usecases. > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/8442 > > -- > Regards, > Alexey Minnekhanov -- With best wishes Dmitry
On 12/17/25 5:34 PM, Dmitry Baryshkov wrote: > On Wed, Dec 17, 2025 at 06:05:31PM +0300, Alexey Minnekhanov wrote: >> On 11.12.2025 04:25, Dmitry Baryshkov wrote: >>> Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support >>> by both DPU and MDP5 drivers. Support for them in the DPU driver is >>> mature enough, so it's no longer sensible to keep them enabled in the >>> MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible >>> string. Drop support for the MDP5 3.x genration inside the MDP5 >>> driver and migrate those to the DPU driver only. >>> >>> Note: this will break if one uses the DT generated before v6.3 as they >>> had only the generic, "qcom,mdp5" compatible string for SDM630 and >>> SDM660. However granted that we had two LTS releases inbetween I don't >>> think it is an issue. >>> >> >> I've retested DPU driver on our downstream release based on 6.18 (by >> using msm.prefer_mdp5=false kernel cmdline parameter) on all devices >> at my disposal, and I can confirm DPU driver working fine an all SDM660, >> SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer >> (Sony Xperia XA2): > > Unfortunately I only have SDM660 and video DSI usecase here. BTW: is > your SDM636 / SDM660 using CMD or video panel? > >> >> [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops >> dsi_ops [msm]) >> [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to >> opp-supp-hw 0x4 >> [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops >> a3xx_ops [msm]) >> [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 >> [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller >> on minor 1 >> ... >> [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu >> error]enc33 intf1 ctl start interrupt wait failed >> [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for >> commit done returned -22 >> ... >> [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu >> error]enc33 intf1 ctl start interrupt wait failed >> [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for >> commit done returned -22 >> >> Which results in horrendous ~3-5 fps in shell. >> >> The block "enc33 intf1 ctl start interrupt wait failed" + "wait for >> commit done returned -22" is repeated few times per second whenever >> the display is turned on, and stops when it's turned off. >> >> Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). > > It's interesting. Would you please capture the devcoredump for the > platform? There will be a lot of blocks, I'm interested in INTF_1, CTL > and top_0. > > Also, as a debugging check, would you mind patching > dpu_encoder_phys_cmd_wait_for_commit_done() so that it always calls > dpu_encoder_phys_cmd_wait_for_tx_complete()? I will check if there are > any differences for CTL_START and similar registers, but it will take > some time. > >> Well, as fine as possible considering [1], using several FD_MESA_DEBUG >> tricks to work around GPU issues. >> >> P.S. I have not yet tested MSM8998, but I can try if required > > As far as I remember, MDP5 on MSM8998 has never been wired (as in never > committed to the DTSI). Angelo has enabled and Freebox people have > tested DPU on MSM8998, but I think it was limited to video / HDMI > usecases. I think we poked at both, back in the day (tm) and DPU worked on msm8998- sony-maple (sharp,ls055d1sx04 cmd mode panel) with the funny CMD mode hack (due to a register field not existing on <845?) https://github.com/SoMainline/linux/commit/14e0517e2fd5eee116a32db624b09856c60fa022 FYI panel wiring: https://github.com/SoMainline/linux/commit/88f276e81cea0f7496d3f92cd731f27615cfa703 +Marijn may know more Konrad
On Thu, Dec 18, 2025 at 12:23:49PM +0100, Konrad Dybcio wrote: > On 12/17/25 5:34 PM, Dmitry Baryshkov wrote: > > On Wed, Dec 17, 2025 at 06:05:31PM +0300, Alexey Minnekhanov wrote: > >> On 11.12.2025 04:25, Dmitry Baryshkov wrote: > >>> Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support > >>> by both DPU and MDP5 drivers. Support for them in the DPU driver is > >>> mature enough, so it's no longer sensible to keep them enabled in the > >>> MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible > >>> string. Drop support for the MDP5 3.x genration inside the MDP5 > >>> driver and migrate those to the DPU driver only. > >>> > >>> Note: this will break if one uses the DT generated before v6.3 as they > >>> had only the generic, "qcom,mdp5" compatible string for SDM630 and > >>> SDM660. However granted that we had two LTS releases inbetween I don't > >>> think it is an issue. > >>> > >> > >> I've retested DPU driver on our downstream release based on 6.18 (by > >> using msm.prefer_mdp5=false kernel cmdline parameter) on all devices > >> at my disposal, and I can confirm DPU driver working fine an all SDM660, > >> SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer > >> (Sony Xperia XA2): > > > > Unfortunately I only have SDM660 and video DSI usecase here. BTW: is > > your SDM636 / SDM660 using CMD or video panel? > > > >> > >> [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops > >> dsi_ops [msm]) > >> [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to > >> opp-supp-hw 0x4 > >> [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops > >> a3xx_ops [msm]) > >> [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 > >> [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller > >> on minor 1 > >> ... > >> [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > >> error]enc33 intf1 ctl start interrupt wait failed > >> [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > >> commit done returned -22 > >> ... > >> [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > >> error]enc33 intf1 ctl start interrupt wait failed > >> [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > >> commit done returned -22 > >> > >> Which results in horrendous ~3-5 fps in shell. > >> > >> The block "enc33 intf1 ctl start interrupt wait failed" + "wait for > >> commit done returned -22" is repeated few times per second whenever > >> the display is turned on, and stops when it's turned off. > >> > >> Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). > > > > It's interesting. Would you please capture the devcoredump for the > > platform? There will be a lot of blocks, I'm interested in INTF_1, CTL > > and top_0. > > > > Also, as a debugging check, would you mind patching > > dpu_encoder_phys_cmd_wait_for_commit_done() so that it always calls > > dpu_encoder_phys_cmd_wait_for_tx_complete()? I will check if there are > > any differences for CTL_START and similar registers, but it will take > > some time. > > > >> Well, as fine as possible considering [1], using several FD_MESA_DEBUG > >> tricks to work around GPU issues. > >> > >> P.S. I have not yet tested MSM8998, but I can try if required > > > > As far as I remember, MDP5 on MSM8998 has never been wired (as in never > > committed to the DTSI). Angelo has enabled and Freebox people have > > tested DPU on MSM8998, but I think it was limited to video / HDMI > > usecases. > > I think we poked at both, back in the day (tm) and DPU worked on msm8998- > sony-maple (sharp,ls055d1sx04 cmd mode panel) with the funny CMD mode hack > (due to a register field not existing on <845?) > > https://github.com/SoMainline/linux/commit/14e0517e2fd5eee116a32db624b09856c60fa022 Ok, so my guess was correct and CTL_START is not present there. Checking the regmaps, there is no intr_start too. Let me cook the patchset. > > FYI panel wiring: > > https://github.com/SoMainline/linux/commit/88f276e81cea0f7496d3f92cd731f27615cfa703 > > +Marijn may know more > > Konrad -- With best wishes Dmitry
On 12/18/25 2:49 PM, Dmitry Baryshkov wrote: > On Thu, Dec 18, 2025 at 12:23:49PM +0100, Konrad Dybcio wrote: >> On 12/17/25 5:34 PM, Dmitry Baryshkov wrote: >>> On Wed, Dec 17, 2025 at 06:05:31PM +0300, Alexey Minnekhanov wrote: >>>> On 11.12.2025 04:25, Dmitry Baryshkov wrote: >>>>> Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support >>>>> by both DPU and MDP5 drivers. Support for them in the DPU driver is >>>>> mature enough, so it's no longer sensible to keep them enabled in the >>>>> MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible >>>>> string. Drop support for the MDP5 3.x genration inside the MDP5 >>>>> driver and migrate those to the DPU driver only. >>>>> >>>>> Note: this will break if one uses the DT generated before v6.3 as they >>>>> had only the generic, "qcom,mdp5" compatible string for SDM630 and >>>>> SDM660. However granted that we had two LTS releases inbetween I don't >>>>> think it is an issue. >>>>> >>>> >>>> I've retested DPU driver on our downstream release based on 6.18 (by >>>> using msm.prefer_mdp5=false kernel cmdline parameter) on all devices >>>> at my disposal, and I can confirm DPU driver working fine an all SDM660, >>>> SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer >>>> (Sony Xperia XA2): >>> >>> Unfortunately I only have SDM660 and video DSI usecase here. BTW: is >>> your SDM636 / SDM660 using CMD or video panel? >>> >>>> >>>> [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops >>>> dsi_ops [msm]) >>>> [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to >>>> opp-supp-hw 0x4 >>>> [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops >>>> a3xx_ops [msm]) >>>> [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 >>>> [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller >>>> on minor 1 >>>> ... >>>> [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu >>>> error]enc33 intf1 ctl start interrupt wait failed >>>> [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for >>>> commit done returned -22 >>>> ... >>>> [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu >>>> error]enc33 intf1 ctl start interrupt wait failed >>>> [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for >>>> commit done returned -22 >>>> >>>> Which results in horrendous ~3-5 fps in shell. >>>> >>>> The block "enc33 intf1 ctl start interrupt wait failed" + "wait for >>>> commit done returned -22" is repeated few times per second whenever >>>> the display is turned on, and stops when it's turned off. >>>> >>>> Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). >>> >>> It's interesting. Would you please capture the devcoredump for the >>> platform? There will be a lot of blocks, I'm interested in INTF_1, CTL >>> and top_0. >>> >>> Also, as a debugging check, would you mind patching >>> dpu_encoder_phys_cmd_wait_for_commit_done() so that it always calls >>> dpu_encoder_phys_cmd_wait_for_tx_complete()? I will check if there are >>> any differences for CTL_START and similar registers, but it will take >>> some time. >>> >>>> Well, as fine as possible considering [1], using several FD_MESA_DEBUG >>>> tricks to work around GPU issues. >>>> >>>> P.S. I have not yet tested MSM8998, but I can try if required >>> >>> As far as I remember, MDP5 on MSM8998 has never been wired (as in never >>> committed to the DTSI). Angelo has enabled and Freebox people have >>> tested DPU on MSM8998, but I think it was limited to video / HDMI >>> usecases. >> >> I think we poked at both, back in the day (tm) and DPU worked on msm8998- >> sony-maple (sharp,ls055d1sx04 cmd mode panel) with the funny CMD mode hack >> (due to a register field not existing on <845?) >> >> https://github.com/SoMainline/linux/commit/14e0517e2fd5eee116a32db624b09856c60fa022 > > Ok, so my guess was correct and CTL_START is not present there. Checking > the regmaps, there is no intr_start too. Let me cook the patchset. FWIW it's not something I came up with.. But I can't fully recall the original finder. Maybe it was one of the MSM8996/MSM8998/SDM845-mainline contributors? It was difficult to find, so I'd like to credit the author but I'm afraid I can't find it.. Konrad
On Thu, Dec 18, 2025 at 02:54:15PM +0100, Konrad Dybcio wrote: > On 12/18/25 2:49 PM, Dmitry Baryshkov wrote: > > On Thu, Dec 18, 2025 at 12:23:49PM +0100, Konrad Dybcio wrote: > >> On 12/17/25 5:34 PM, Dmitry Baryshkov wrote: > >>> On Wed, Dec 17, 2025 at 06:05:31PM +0300, Alexey Minnekhanov wrote: > >>>> On 11.12.2025 04:25, Dmitry Baryshkov wrote: > >>>>> Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support > >>>>> by both DPU and MDP5 drivers. Support for them in the DPU driver is > >>>>> mature enough, so it's no longer sensible to keep them enabled in the > >>>>> MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible > >>>>> string. Drop support for the MDP5 3.x genration inside the MDP5 > >>>>> driver and migrate those to the DPU driver only. > >>>>> > >>>>> Note: this will break if one uses the DT generated before v6.3 as they > >>>>> had only the generic, "qcom,mdp5" compatible string for SDM630 and > >>>>> SDM660. However granted that we had two LTS releases inbetween I don't > >>>>> think it is an issue. > >>>>> > >>>> > >>>> I've retested DPU driver on our downstream release based on 6.18 (by > >>>> using msm.prefer_mdp5=false kernel cmdline parameter) on all devices > >>>> at my disposal, and I can confirm DPU driver working fine an all SDM660, > >>>> SDM636 ones, but not on SDM630. Some logs from sdm630-sony-nile-pioneer > >>>> (Sony Xperia XA2): > >>> > >>> Unfortunately I only have SDM660 and video DSI usecase here. BTW: is > >>> your SDM636 / SDM660 using CMD or video panel? > >>> > >>>> > >>>> [ 2.356546] msm_dpu c901000.display-controller: bound c994000.dsi (ops > >>>> dsi_ops [msm]) > >>>> [ 2.357328] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to > >>>> opp-supp-hw 0x4 > >>>> [ 2.364802] msm_dpu c901000.display-controller: bound 5000000.gpu (ops > >>>> a3xx_ops [msm]) > >>>> [ 2.444649] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000 > >>>> [ 2.449793] [drm] Initialized msm 1.13.0 for c901000.display-controller > >>>> on minor 1 > >>>> ... > >>>> [ 2.911900] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > >>>> error]enc33 intf1 ctl start interrupt wait failed > >>>> [ 2.911916] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > >>>> commit done returned -22 > >>>> ... > >>>> [ 3.176171] [drm:_dpu_encoder_phys_cmd_wait_for_ctl_start:654] [dpu > >>>> error]enc33 intf1 ctl start interrupt wait failed > >>>> [ 3.176367] [drm:dpu_kms_wait_for_commit_done:525] [dpu error]wait for > >>>> commit done returned -22 > >>>> > >>>> Which results in horrendous ~3-5 fps in shell. > >>>> > >>>> The block "enc33 intf1 ctl start interrupt wait failed" + "wait for > >>>> commit done returned -22" is repeated few times per second whenever > >>>> the display is turned on, and stops when it's turned off. > >>>> > >>>> Meanwhile it is working fine using MDP5 driver (msm.prefer_mdp5=true). > >>> > >>> It's interesting. Would you please capture the devcoredump for the > >>> platform? There will be a lot of blocks, I'm interested in INTF_1, CTL > >>> and top_0. > >>> > >>> Also, as a debugging check, would you mind patching > >>> dpu_encoder_phys_cmd_wait_for_commit_done() so that it always calls > >>> dpu_encoder_phys_cmd_wait_for_tx_complete()? I will check if there are > >>> any differences for CTL_START and similar registers, but it will take > >>> some time. > >>> > >>>> Well, as fine as possible considering [1], using several FD_MESA_DEBUG > >>>> tricks to work around GPU issues. > >>>> > >>>> P.S. I have not yet tested MSM8998, but I can try if required > >>> > >>> As far as I remember, MDP5 on MSM8998 has never been wired (as in never > >>> committed to the DTSI). Angelo has enabled and Freebox people have > >>> tested DPU on MSM8998, but I think it was limited to video / HDMI > >>> usecases. > >> > >> I think we poked at both, back in the day (tm) and DPU worked on msm8998- > >> sony-maple (sharp,ls055d1sx04 cmd mode panel) with the funny CMD mode hack > >> (due to a register field not existing on <845?) > >> > >> https://github.com/SoMainline/linux/commit/14e0517e2fd5eee116a32db624b09856c60fa022 > > > > Ok, so my guess was correct and CTL_START is not present there. Checking > > the regmaps, there is no intr_start too. Let me cook the patchset. > > FWIW it's not something I came up with.. But I can't fully recall the > original finder. Maybe it was one of the MSM8996/MSM8998/SDM845-mainline > contributors? It was difficult to find, so I'd like to credit the author > but I'm afraid I can't find it.. For now I credited Alexey for his email earlier in this thread. -- With best wishes Dmitry
On 12/11/25 2:25 AM, Dmitry Baryshkov wrote: > Currently MDP5 3.x (MSM8998, SDM630 and SDM660) platforms are support > by both DPU and MDP5 drivers. Support for them in the DPU driver is > mature enough, so it's no longer sensible to keep them enabled in the > MDP5 driver. Not to mention that MSM8998 never used an MDP5 compatible > string. Drop support for the MDP5 3.x genration inside the MDP5 > driver and migrate those to the DPU driver only. > > Note: this will break if one uses the DT generated before v6.3 as they > had only the generic, "qcom,mdp5" compatible string for SDM630 and > SDM660. However granted that we had two LTS releases inbetween I don't > think it is an issue. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- I wouldn't be surprised if the DPU description was "better" too, since they've gone through rounds of reviews FWIW Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
© 2016 - 2026 Red Hat, Inc.