Re: [PATCH v3] drm/panel: novatek-nt36672a: Inline panel init sequences
From: Alexey Minnekhanov
Date: Mon May 25 2026 - 11:11:25 EST
On 23.05.2026 06:57, Chintan Patel wrote:
Inline the panel initialization command sequences and remove the
table-based command abstraction used by the NT36672A panel driver.
Replace the nt36672a_panel_cmd tables and nt36672a_send_cmds()
helper with explicit initialization functions using
mipi_dsi_dcs_write_seq_multi() and
mipi_dsi_dcs_write_var_seq_multi() directly.
This improves readability by making the panel programming sequence
explicit in code and allows future sharing of common command
subsequences between panels. It also removes an unnecessary wrapper
around the MIPI DSI helpers.
Additionally, compress repeated register writes into small loops where
appropriate to reduce duplication in the initialization sequences.
Add:
tianma_fhd_video_send_init_cmds_1()
tianma_fhd_video_send_init_cmds_2()
tianma_fhd_video_send_deinit_cmds()
Update nt36672a_panel_desc to use function pointers for panel init
sequences and invoke them directly from prepare/unprepare paths.
Signed-off-by: Chintan Patel <chintanlike@xxxxxxxxx>
Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
---
Changes in v3:
- Rename on_init_1/on_init_2/off_init to send_init_cmds_1/send_init_cmds_2/send_deinit_cmds
- Convert all hex values to lowercase (0xFF → 0xff) per kernel coding standards
Changes in v2:
- Replace command tables with explicit init functions
- Remove nt36672a_send_cmds() helper entirely
- Use mipi_dsi_dcs_write_seq_multi() directly
- Use mipi_dsi_dcs_write_var_seq_multi() loops for repeated register writes
- Convert nt36672a_panel_desc command table fields to function pointers
---
.../gpu/drm/panel/panel-novatek-nt36672a.c | 522 +++++++-----------
1 file changed, 186 insertions(+), 336 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
index 7e8b5e059575..464d9ce47d87 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
...
@@ -162,8 +141,8 @@ static int nt36672a_panel_prepare(struct drm_panel *panel)
dsi_ctx.accum_err = nt36672a_panel_power_on(pinfo);
/* send first part of init cmds */
- nt36672a_send_cmds(&dsi_ctx, pinfo->desc->on_cmds_1,
- pinfo->desc->num_on_cmds_1);
+ if (pinfo->desc->send_init_cmds_1)
+ pinfo->desc->send_init_cmds_1(&dsi_ctx);
mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
@@ -173,8 +152,8 @@ static int nt36672a_panel_prepare(struct drm_panel *panel)
mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
/* Send rest of the init cmds */
- nt36672a_send_cmds(&dsi_ctx, pinfo->desc->on_cmds_2,
- pinfo->desc->num_on_cmds_2);
+ if (pinfo->desc->send_init_cmds_2)
+ pinfo->desc->send_init_cmds_2(&dsi_ctx);
mipi_dsi_msleep(&dsi_ctx, 120);
Hi!
Here, the split of panel init sequence into 2 separate functions _1 / _2
is completely artificial and completely unnecessary. For some unknown
reason the initial version of driver had initialization procedure cut in
2 parts on the boundary of exit_sleep_mode + set_display_on commands.
I think the whole init sequence should be glued together into one big
send_init_cmds() callback and have all these calls:
mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
/* 0x46 = 70 ms delay */
mipi_dsi_msleep(&dsi_ctx, 70);
mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
included in the middle. This opens up a possibility for other panels
based on nt36672a to be supported in this driver, which don't have the
init sequence split this way. The location of exit_sleep_mode and
set_display_on commands there is different. And, importantly, the delay
is different too.
I once did a very similar change to this driver [1] to add support for
more panels (ignore touchscreen changes there, look only at panel).
What is also important, that change was also tested on Xiaomi Poco F1
(xiaomi-beryllium) phone, which is the main user of this panel.
Unfortunately I never got to send it, even though I wanted to..
What do you think?
[1] https://gitlab.com/sdm845-mainline/linux/-/merge_requests/131
--
Regards,
Alexey Minnekhanov