Messages in this thread | | | Date | Tue, 30 May 2023 01:39:10 +0300 | Subject | Re: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3 | From | Dmitry Baryshkov <> |
| |
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
| |