[PATCH v2 1/3] drm/panel: jdi-lpm102a188a: Update deprecated MIPI function calls
Doug Anderson
dianders at chromium.org
Wed Jul 16 15:44:33 UTC 2025
Hi,
On Tue, Jul 15, 2025 at 10:32 PM Brigham Campbell
<me at brighamcampbell.com> wrote:
>
> On Mon Jul 14, 2025 at 3:46 PM MDT, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Jul 8, 2025 at 12:39 AM Brigham Campbell <me at brighamcampbell.com> wrote:
> >>
> >> Update jdi-lpm102a188a panel driver to use the "multi" variant of MIPI
> >> functions in order to facilitate improved error handling and remove the
> >> panel's dependency on deprecated MIPI functions.
> >>
> >> This patch's usage of the mipi_dsi_multi_context struct is not
> >> idiomatic. Rightfully, the struct wasn't designed to cater to the needs
> >> of panels with multiple MIPI DSI interfaces. This panel is an oddity
> >> which requires swapping the dsi pointer between MIPI function calls in
> >> order to preserve the exact behavior implemented using the non-multi
> >> variant of the macro.
> >
> > Right. We dealt with this before with "novatek-nt36523"...
> >
> >
> >> Signed-off-by: Brigham Campbell <me at brighamcampbell.com>
> >> ---
> >> drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c | 160 +++++++-----------
> >> 1 file changed, 59 insertions(+), 101 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
> >> index 5b5082efb282..5001bea1798f 100644
> >> --- a/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
> >> +++ b/drivers/gpu/drm/panel/panel-jdi-lpm102a188a.c
> >> @@ -81,25 +81,20 @@ static int jdi_panel_disable(struct drm_panel *panel)
> >> static int jdi_panel_unprepare(struct drm_panel *panel)
> >> {
> >> struct jdi_panel *jdi = to_panel_jdi(panel);
> >> - int ret;
> >> + struct mipi_dsi_multi_context dsi_ctx;
> >>
> >> - ret = mipi_dsi_dcs_set_display_off(jdi->link1);
> >> - if (ret < 0)
> >> - dev_err(panel->dev, "failed to set display off: %d\n", ret);
> >> -
> >> - ret = mipi_dsi_dcs_set_display_off(jdi->link2);
> >> - if (ret < 0)
> >> - dev_err(panel->dev, "failed to set display off: %d\n", ret);
> >> + dsi_ctx.dsi = jdi->link1;
> >> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> >> + dsi_ctx.dsi = jdi->link2;
> >> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> >>
> >> /* Specified by JDI @ 50ms, subject to change */
> >> msleep(50);
> >
> > Needs to be mipi_dsi_msleep() to avoid the sleep in case the above
> > commands caused an error.
> >
> >
> >> - ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link1);
> >> - if (ret < 0)
> >> - dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
> >> - ret = mipi_dsi_dcs_enter_sleep_mode(jdi->link2);
> >> - if (ret < 0)
> >> - dev_err(panel->dev, "failed to enter sleep mode: %d\n", ret);
> >> + dsi_ctx.dsi = jdi->link1;
> >> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> >> + dsi_ctx.dsi = jdi->link2;
> >> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> >
> > I think you need this here:
> >
> > if (dsi_ctx.accum_err)
> > return dsi_ctx.accum_err;
> >
> > ...otherwise the code will do the sleeps, GPIO calls, and regulator
> > calls even in the case of an error. You don't want that. Then at the
> > end of the function you'd just have "return 0;"
> >
> >
>
> Regarding these two suggestions, I prepared this patch with the intent
> to change the drivers actual behavior as little as possible. It looks
> like the original driver will happily msleep and try to continue
> initialization even after an error has occurred. Of course, using the
> _multi variants of mipi dbi functions kind of implies that we want to
> stop communicating with a display after an error has occurred. And
> because all _multi functions are effectively no-ops after an error has
> occurred, it doesn't make sense to perform the other half of the
> initialization sequence while anything involving mipi is dutifully
> skipped.
>
> I'll make these changes in the next patch revision.
Hmmmm. You're right that the old driver was indeed plowing forward
when it got errors. It checks them and does a printout, but then it
throws away the error code and continues executing the rest of the
functions.
Oh! ...but looking at this with fresh eyes, perhaps what the old code
was doing was more correct specifically because this is _unprepare_
and we want to power off even if there were errors. To be explicit:
1. Just because MIPI commands are failing on one link doesn't mean
that they are failing on both links.
2. Even though trying to send "enter sleep mode" after a failed
"display off" will probably fail, it doesn't seem like it would hurt
to try it.
3. You definitely still want all the GPIO / regulator calls even if
the MIP commands failed.
4. Given all the above, I guess one could argue that the sleeps should
all be executed in this case even if the MIPI commands fail.
Maybe something like this would make sense?
/*
* One context per panel since we'll continue trying to shut down
* the other panel even if one isn't responding.
*/
struct mipi_dsi_multi_context dsi_ctx1 = { .dsi = jdi->link1 };
struct mipi_dsi_multi_context dsi_ctx2 = { .dsi = jdi->link2 };
mipi_dsi_dcs_set_display_off_multi(&dsi_ctx1);
mipi_dsi_dcs_set_display_off_multi(&dsi_ctx2);
msleep(50);
/* Doesn't hurt to try sleep mode even if display off fails */
dsi_ctx1.accum_err = dsi_ctx2.accum_err = 0;
mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx1);
mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx2);
msleep(150);
...
...
/* We powered off; return no error even if MIPI cmds failed */
return 0;
What do you think? This is still a small functionality change since
the old code would have returned an error if the second
mipi_dsi_dcs_enter_sleep_mode() returned an error code, but that feels
like it was a bug. That should probably be mentioned in the commit
message.
> >> static int jdi_setup_symmetrical_split(struct mipi_dsi_device *left,
> >> struct mipi_dsi_device *right,
> >> const struct drm_display_mode *mode)
> >> {
> >> - int err;
> >> + struct mipi_dsi_multi_context dsi_ctx;
> >
> > I think you should actually pass in the "dsi_ctx" to this function
> > since the caller already has one. Then you can change it to a "void"
> > function...
> >
> >
> >> static int jdi_write_dcdc_registers(struct jdi_panel *jdi)
> >> {
> >
> > I think you want to pass the context into this function too and make
> > it "void". Then the caller doesn't need to check for the error before
> > calling it...
> >
> > Then the "msleep(150)" after calling this function can change to a
> > `mipi_dsi_msleep()` and you don't need to check the error until right
> > before the LPM flag is cleared...
> >
> >
>
> About the suggestion, "you don't need to check the error until right
> before the LPM flag is cleared...", if I change
> jdi_setup_symmetrical_split to accept a mipi_dsi_multi_context pointer,
> the driver will output "failed to set up symmetrical split" even if the
> error was encountered well before setting up the symmetrical split
> (meaning the driver doesn't even try to set up symmetrical split at all).
>
> The appropriate solution will be to either maintain the error checks in
> the driver, or remove the print statements. For the next revision, I'll
> simply go ahead and remove the error print statements because:
> - the mipi _multi functions should handle error printing well enough
> to facilitate tracking down the particular mipi sequence which
> caused an error during probe/unprepare.
> - less logic in this driver makes it easier to maintain
Right. You'd remove the "failed to set up symmetrical split" error
since all sources of the error would already be reported.
> >> + struct mipi_dsi_multi_context dsi_ctx;
> >> +
> >> /* Clear the manufacturer command access protection */
> >> - mipi_dsi_generic_write_seq(jdi->link1, MCS_CMD_ACS_PROT,
> >> + dsi_ctx.dsi = jdi->link1;
> >> + mipi_dsi_generic_write_seq_multi(&dsi_ctx, MCS_CMD_ACS_PROT,
> >> MCS_CMD_ACS_PROT_OFF);
> >> - mipi_dsi_generic_write_seq(jdi->link2, MCS_CMD_ACS_PROT,
> >> + dsi_ctx.dsi = jdi->link2;
> >> + mipi_dsi_generic_write_seq_multi(&dsi_ctx, MCS_CMD_ACS_PROT,
> >> MCS_CMD_ACS_PROT_OFF);
> >
> > All the duplication is annoying. In "novatek-nt36523" I guess we only
> > needed to send _some_ of the commands to both panels and so we ended
> > up with a macro in just that C file just for
> > mipi_dsi_dual_dcs_write_seq_multi(). ...but here you seem to be
> > needing it for lots of functions.
> >
> > Maybe the solution is to add something like this to "drm_mipi_dsi.h":
> >
> > #define mipi_dsi_dual(_func, _dsi1, _dsi2, _ctx, _args...) \
> > do { \
> > (_ctx)->dsi = (_dsi1); \
> > (_func)((_ctx), _args); \
> > (_ctx)->dsi = (_dsi2); \
> > (_func)((_ctx), _args); \
> > } while (0)
> >
> > Then you could have statements like:
> >
> > mipi_dsi_dual(mipi_dsi_generic_write_seq_multi, jdi->link1,
> > jdi->link2, &dsi_ctx, ...);
> >
> > I _think_ that will work? I at least prototyped it up with some simple
> > test code and it seemed to work... What do others think of that?
>
> In my opinion, this change is absolutely worth making, but the creation
> of a new macro like mipi_dsi_dual in drm_mipi_dsi.h is beyond the scope
> of this patch series because it has implications for panels like
> novatek-nt36523 and others. It looks like you've already effectively
> completed the work of implementing the macro, but I'm happy to address
> the adoption of the macro in lpm102a188a and other drivers as a part of
> a later patch series. Besides, there is no more duplication in this
> driver after applying my patch than there was before.
>
> Of course, maybe that's just me being pedantic. I'm happy to include
> mipi_dsi_dual in this series if you insist.
I would prefer if you had a patch #1 introducing mipi_dsi_dual() and
then used it in patch #2. IMO there's no need for you to go back and
re-cleanup "novatek-nt36523". I think the panel you're dealing with is
the second one to have run into this issue during the "multi"
conversion and it's better to get the cleaner solution landed before
others copy.
That being said, I won't insist. You're right that the duplication
isn't any worse with your patch.
-Doug
More information about the dri-devel
mailing list