On 2023-05-30 01:18:40, Dmitry Baryshkov wrote: <snip> > >>>>> + ret = mipi_dsi_dcs_set_display_on(dsi); > >>>>> + if (ret < 0) { > >>>>> + dev_err(dev, "Failed to turn display on: %d\n", ret); > >>>>> + return ret; > >>>>> + } > >>>> > >>>> My usual question: should the mipi_dsi_dcs_exit_sleep_mode() / mipi_dsi_dcs_set_display_on() be moved from prepare() to enable() part? > >>> > >>> > >>> No, prepare is called before the video stream is started and when display is still in LPM mode and the mode hasn't been set. > >>> > >> > >> Yes, that's my point. Shouldn't we enable the panel _after_ starting the stream? > > > > I have never investigated what it takes to split these functions, but > > some of these panels do show some corruption at startup which may be > > circumvented by powering the panel on after starting the video stream? > > > > I'm just not sure where to make the split: downstream does describe a > > qcom,mdss-dsi-on-command and qcom,mdss-dsi-post-panel-on-command, where > > the latter only contains set_display_on() (not exit_sleep_mode()). > > It is documented like: > > > > same as "qcom,mdss-dsi-on-command" except commands are sent after > > displaying an image." > > > > So this seems like the right way to split them up, I'll test this out on > > all submitted panel drivers. > > Interesting enough, Neil suggested that sending all the commands during > pre_enable() is the correct sequence (especially for VIDEO mode panels), > since not all DSI hosts can send commands after switching to the VIDEO mode. Note that all these panels and Driver-ICs are command-mode, and/or programmed to run in command-mode, so there shouldn't be any notion of a VIDEO stream (any command-mode frame is just an "arbitrary command" as far as I understood). - Marijn