On Wed, Apr 24, 2024 at 2:05 PM Doug Anderson <dianders@xxxxxxxxxx> wrote: > > Hi, > > On Tue, Apr 23, 2024 at 2:20 PM Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > On Tue, Apr 23, 2024 at 01:41:59PM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Tue, Apr 23, 2024 at 11:10 AM Hsin-Yi Wang <hsinyi@xxxxxxxxxx> wrote: > > > > > > > > > > > > +#define _INIT_DCS_CMD(...) { \ > > > > > > > > + .type = INIT_DCS_CMD, \ > > > > > > > > + .len = sizeof((char[]){__VA_ARGS__}), \ > > > > > > > > + .data = (char[]){__VA_ARGS__} } > > > > > > > > + > > > > > > > > +#define _INIT_DELAY_CMD(...) { \ > > > > > > > > + .type = DELAY_CMD,\ > > > > > > > > + .len = sizeof((char[]){__VA_ARGS__}), \ > > > > > > > > + .data = (char[]){__VA_ARGS__} } > > > > > > > > > > > > > > This is the third panel driver using the same appoach. Can you use > > > > > > > mipi_dsi_generic_write_seq() instead of the huge table? Or if you prefer > > > > > > > the table, we should extract this framework to a common helper. > > > > > > > (my preference is shifted towards mipi_dsi_generic_write_seq()). > > > > > > > > > > > > > The drawback of mipi_dsi_generic_write_seq() is that it can cause the > > > > > > kernel size grows a lot since every sequence will be expanded. > > > > > > > > > > > > Similar discussion in here: > > > > > > https://lore.kernel.org/dri-devel/CAD=FV=Wju3WS45=EpXMUg7FjYDh3-=mvm_jS7TF1tsaAzbb4Uw@xxxxxxxxxxxxxx/ > > > > > > > > > > > > This patch would increase the module size from 157K to 572K. > > > > > > scripts/bloat-o-meter shows chg +235.95%. > > > > > > > > > > > > So maybe the common helper is better regarding the kernel module size? > > > > > > > > > > Yes, let's get a framework done in a useful way. > > > > > I'd say, drop the _INIT_DELAY_CMD. msleep() and usleep_range() should be > > > > > used instead (and it's up to the developer to select correct delay > > > > > function). > > > > > > > > > > > > > > > > > > > + > > > > > > > > +static const struct panel_init_cmd kingdisplay_kd101ne3_init_cmd[] = { > > > > > > > > + _INIT_DELAY_CMD(50), > > > > > > > > + _INIT_DCS_CMD(0xE0, 0x00), > > > > > > > > > > [skipped the body of the table] > > > > > > > > > > > > > + _INIT_DCS_CMD(0x0E, 0x48), > > > > > > > > + > > > > > > > > + _INIT_DCS_CMD(0xE0, 0x00), > > > > > > > > > > > > > + _INIT_DCS_CMD(0X11), > > > > > > > > > > Also, at least this is mipi_dsi_dcs_exit_sleep_mode(). > > > > > > > > > > > > > + /* T6: 120ms */ > > > > > > > > + _INIT_DELAY_CMD(120), > > > > > > > > + _INIT_DCS_CMD(0X29), > > > > > > > > > > And this is mipi_dsi_dcs_set_display_on(). > > > > > > > > > > Having a single table enourages people to put known commands into the > > > > > table, the practice that must be frowned upon and forbidden. > > > > > > > > > > We have functions for some of the standard DCS commands. So, maybe > > > > > instead of adding a single-table based approach we can improve > > > > > mipi_dsi_generic_write_seq() to reduce the bloat. E.g. by moving the > > > > > error handling to a common part of enable() / prepare() function. > > > > > > > > > > > > > For this panel, I think it can also refer to how > > > > panel-kingdisplay-kd097d04.c does. Create the table for init cmd data, > > > > not what operation to use, and use mipi_dsi_generic_write_seq() when > > > > looping through the table. > > > > > > Even more similar discussion: > > > > > > https://lore.kernel.org/r/CAD=FV=UGDbNvAMjzWSOvxybGikQcvW9JsRtbxHVg8_97YPEQCA@xxxxxxxxxxxxxx > > > > It seems I skipped that thread. > > > > I'd still suggest a code-based solution compared to table-based one, for > > the reasons I've outlined before. Having a tables puts a pressure on the > > developer to put commands there for which we already have a > > command-specific function. > > The problem is that with these panels that need big init sequences the > code based solution is _a lot_ bigger. If it were a few bytes or a > 1-2KB then fine, but when Hsin-Yi measured Linus W's attempt to move > from a table to code it was 100K difference in code [1]. I would also > say that having these long init sequences done as separate commands > encourages people to skip checking the return values of each of the > transfer functions and I don't love that idea. > > It would be ideal if these panels didn't need these long init > sequences, but I don't have any inside knowledge here saying that they > could be removed. So assume we can't get rid of the init sequences it > feels like we have to find some way to make the tables work for at > least the large chunks of init code and encourage people to make the > tables readable... > For the init sequence of the panel from this patch, using the table approach, we can still use mipi_dsi_generic_write_seq() and not invent new macro or make the code complicated. > > [1] https://lore.kernel.org/r/CAD=FV=UFa_AoJQvUT3BTiRs19WCA2xLVeQOU=+nYu_HaE0_c6Q@xxxxxxxxxxxxxx