From: David Heidelberg <david@ixit.cz>
Introduce enable(), disable() and reset() functions.
The enable() and disable() callbacks keep the symmetry in the commands
sent to the panel and also make a clearer distinction between panel
initialization and configuration.
Splitting reset() from prepare() follows clean coding practices and lets
us potentially make reset optional in the future for flicker-less
takeover from a bootloader or framebuffer driver where the panel is
already configured.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 47 ++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index dcca7873acf8e..dad6b967b92c2 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -38,11 +38,10 @@ static inline struct sw43408_panel *to_panel_info(struct drm_panel *panel)
return container_of(panel, struct sw43408_panel, base);
}
-static int sw43408_unprepare(struct drm_panel *panel)
+static int sw43408_disable(struct drm_panel *panel)
{
struct sw43408_panel *sw43408 = to_panel_info(panel);
struct mipi_dsi_multi_context ctx = { .dsi = sw43408->link };
- int ret;
mipi_dsi_dcs_set_display_off_multi(&ctx);
@@ -50,18 +49,25 @@ static int sw43408_unprepare(struct drm_panel *panel)
mipi_dsi_msleep(&ctx, 100);
+ return ctx.accum_err;
+}
+
+static int sw43408_unprepare(struct drm_panel *panel)
+{
+ struct sw43408_panel *sw43408 = to_panel_info(panel);
+ int ret;
+
gpiod_set_value(sw43408->reset_gpio, 1);
ret = regulator_bulk_disable(ARRAY_SIZE(sw43408->supplies), sw43408->supplies);
- return ret ? : ctx.accum_err;
+ return ret;
}
static int sw43408_program(struct drm_panel *panel)
{
struct sw43408_panel *sw43408 = to_panel_info(panel);
struct mipi_dsi_multi_context ctx = { .dsi = sw43408->link };
- struct drm_dsc_picture_parameter_set pps;
mipi_dsi_dcs_write_seq_multi(&ctx, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
@@ -97,6 +103,15 @@ static int sw43408_program(struct drm_panel *panel)
mipi_dsi_dcs_write_seq_multi(&ctx, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70, 0xdb);
mipi_dsi_dcs_write_seq_multi(&ctx, 0xb0, 0xca);
+ return ctx.accum_err;
+}
+
+static int sw43408_enable(struct drm_panel *panel)
+{
+ struct sw43408_panel *sw43408 = to_panel_info(panel);
+ struct mipi_dsi_multi_context ctx = { .dsi = sw43408->link };
+ struct drm_dsc_picture_parameter_set pps;
+
mipi_dsi_dcs_set_display_on_multi(&ctx);
mipi_dsi_msleep(&ctx, 50);
@@ -116,18 +131,12 @@ static int sw43408_program(struct drm_panel *panel)
*/
mipi_dsi_compression_mode_ext_multi(&ctx, true,
MIPI_DSI_COMPRESSION_DSC, 1);
+
return ctx.accum_err;
}
-static int sw43408_prepare(struct drm_panel *panel)
+static void sw43408_reset(struct sw43408_panel *ctx)
{
- struct sw43408_panel *ctx = to_panel_info(panel);
- int ret;
-
- ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
- if (ret < 0)
- return ret;
-
usleep_range(5000, 6000);
gpiod_set_value(ctx->reset_gpio, 0);
@@ -136,6 +145,18 @@ static int sw43408_prepare(struct drm_panel *panel)
usleep_range(1000, 2000);
gpiod_set_value(ctx->reset_gpio, 0);
usleep_range(9000, 10000);
+}
+
+static int sw43408_prepare(struct drm_panel *panel)
+{
+ struct sw43408_panel *ctx = to_panel_info(panel);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ sw43408_reset(ctx);
ret = sw43408_program(panel);
if (ret)
@@ -208,6 +229,8 @@ static int sw43408_backlight_init(struct sw43408_panel *ctx)
}
static const struct drm_panel_funcs sw43408_funcs = {
+ .disable = sw43408_disable,
+ .enable = sw43408_enable,
.unprepare = sw43408_unprepare,
.prepare = sw43408_prepare,
.get_modes = sw43408_get_modes,
--
2.51.0On Mon, Dec 08, 2025 at 10:41:57AM +0100, David Heidelberg via B4 Relay wrote: > From: David Heidelberg <david@ixit.cz> > > Introduce enable(), disable() and reset() functions. > > The enable() and disable() callbacks keep the symmetry in the commands > sent to the panel and also make a clearer distinction between panel > initialization and configuration. It's not just it. There is a difference between commands being sent in en/disable and prepare/unprepare. > > Splitting reset() from prepare() follows clean coding practices and lets > us potentially make reset optional in the future for flicker-less > takeover from a bootloader or framebuffer driver where the panel is > already configured. > > Signed-off-by: David Heidelberg <david@ixit.cz> > --- > drivers/gpu/drm/panel/panel-lg-sw43408.c | 47 ++++++++++++++++++++++++-------- > 1 file changed, 35 insertions(+), 12 deletions(-) > -- With best wishes Dmitry
On 09/12/2025 23:37, Dmitry Baryshkov wrote: > On Mon, Dec 08, 2025 at 10:41:57AM +0100, David Heidelberg via B4 Relay wrote: >> From: David Heidelberg <david@ixit.cz> >> >> Introduce enable(), disable() and reset() functions. >> >> The enable() and disable() callbacks keep the symmetry in the commands >> sent to the panel and also make a clearer distinction between panel >> initialization and configuration. > > It's not just it. There is a difference between commands being sent in > en/disable and prepare/unprepare. Thanks, I didn't know. Is there good rule how to distinguish, which command should go where? > >> >> Splitting reset() from prepare() follows clean coding practices and lets >> us potentially make reset optional in the future for flicker-less >> takeover from a bootloader or framebuffer driver where the panel is >> already configured. >> >> Signed-off-by: David Heidelberg <david@ixit.cz> >> --- >> drivers/gpu/drm/panel/panel-lg-sw43408.c | 47 ++++++++++++++++++++++++-------- >> 1 file changed, 35 insertions(+), 12 deletions(-) >> > -- David Heidelberg
On 09/12/2025 23:51, David Heidelberg wrote: > On 09/12/2025 23:37, Dmitry Baryshkov wrote: >> On Mon, Dec 08, 2025 at 10:41:57AM +0100, David Heidelberg via B4 >> Relay wrote: >>> From: David Heidelberg <david@ixit.cz> >>> >>> Introduce enable(), disable() and reset() functions. >>> >>> The enable() and disable() callbacks keep the symmetry in the commands >>> sent to the panel and also make a clearer distinction between panel >>> initialization and configuration. >> >> It's not just it. There is a difference between commands being sent in >> en/disable and prepare/unprepare. > > Thanks, I didn't know. Is there good rule how to distinguish, which > command should go where? How about I would "reduce" this patch to putting reset sequence into own function, so Pixel 3 support could get merged? The display will need more work anyway, would you be fine with this approach? David
On 12/12/2025 16:39, David Heidelberg wrote: > On 09/12/2025 23:51, David Heidelberg wrote: >> On 09/12/2025 23:37, Dmitry Baryshkov wrote: >>> On Mon, Dec 08, 2025 at 10:41:57AM +0100, David Heidelberg via B4 >>> Relay wrote: >>>> From: David Heidelberg <david@ixit.cz> >>>> >>>> Introduce enable(), disable() and reset() functions. >>>> >>>> The enable() and disable() callbacks keep the symmetry in the commands >>>> sent to the panel and also make a clearer distinction between panel >>>> initialization and configuration. >>> >>> It's not just it. There is a difference between commands being sent in >>> en/disable and prepare/unprepare. >> >> Thanks, I didn't know. Is there good rule how to distinguish, which >> command should go where? > > How about I would "reduce" this patch to putting reset sequence into own > function, so Pixel 3 support could get merged? > > The display will need more work anyway, would you be fine with this > approach? As I did additional few changes, I'll sent v7 now, where I'll just abstract _reset() into own function. I would address any other (non reviewed) changes when we manage to get panel with the driver behave stable on mainline/-next. If you decide this change is worthy of inclusion in this series, I'm open to bring this commit back in future revisions. Thank you David
© 2016 - 2025 Red Hat, Inc.