On 30/05/2023 01:37, Marijn Suijten wrote:
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).
Yes, from the data stream point of view. I was talking about the DSI
host being able to send arbitrary commands or not after enabling the
video/cmd stream.
- Marijn
--
With best wishes
Dmitry
