Hi, On Wed, Jun 19, 2024 at 12:23 AM Tejas Vipin <tejasvipin76@xxxxxxxxx> wrote: > > > > On 6/19/24 12:06 PM, Dmitry Baryshkov wrote: > > On Wed, Jun 19, 2024 at 09:03:49AM GMT, Tejas Vipin wrote: > >> Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce > >> mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe > >> ("drm/mipi-dsi: wrap more functions for streamline handling") for the > >> raydium rm692e5 panel. > >> > >> Signed-off-by: Tejas Vipin <tejasvipin76@xxxxxxxxx> > >> --- > >> Changes in v2: > >> - Change rm692e5_on to return void and take mipi_dsi_multi_context > >> as an argument. > >> - Remove unnecessary warnings. > >> - More efficient error handling in rm692e5_prepare > >> > >> v1: https://lore.kernel.org/all/20240615093758.65431-1-tejasvipin76@xxxxxxxxx/ > >> --- > >> drivers/gpu/drm/panel/panel-raydium-rm692e5.c | 237 ++++++++---------- > >> 1 file changed, 99 insertions(+), 138 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c > >> index 21d97f6b8a2f..9936bda61af2 100644 > >> --- a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c > >> +++ b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c > > > >> static int rm692e5_prepare(struct drm_panel *panel) > >> { > >> struct rm692e5_panel *ctx = to_rm692e5_panel(panel); > >> struct drm_dsc_picture_parameter_set pps; > >> - struct device *dev = &ctx->dsi->dev; > >> - int ret; > >> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi }; > >> > >> - ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies); > >> - if (ret < 0) { > >> - dev_err(dev, "Failed to enable regulators: %d\n", ret); > >> - return ret; > >> - } > >> + dsi_ctx.accum_err = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies); > >> + if (dsi_ctx.accum_err) > >> + return dsi_ctx.accum_err; > > > > int ret, please. Let's leave dsi_ctx.accum_err for DSI errors only. > > LGTM otherwise. > > Is this really necessary seeing how regulator_bulk_enable returns > 0 on success anyways? It saves creating a new variable for a single > check. In case you do think its necessary, should it be changed in > himax_hx83102 too? Right. I made the same choice as Tejas did when I wrote commit a2ab7cb169da ("drm/panel: himax-hx83102: use wrapped MIPI DCS functions"). In that commit message, I wrote: It can also be noted that hx83102_prepare() has a mix of things that can take advantage of _multi calls and things that can't. The cleanest seemed to be to use the multi_ctx still but consistently use the "accum_err" variable for error returns, though that's definitely a style decision with pros and cons. In my mind trying to juggle half the cases having the error in "ret" and half in the DSI context was a recipe for getting mixed up and returning the wrong error. On the other hand, it felt awkward using the "dsi_ctx.accum_err". In the end I felt that the extra awkwardness was worth it if it meant that I was less likely to "return ret" when the error code was actually in "dsi_ctx.accum_err"... -Doug