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