[PATCH v3 1/2] drm/panel: jd9365da: Move "exit sleep mode" and "set display on" cmds

[Doug Anderson]

Jessica,

On Thu, Aug 8, 2024 at 3:56 PM Jessica Zhang <quic_jesszhan at quicinc.com> wrote:
>
>
>
> On 8/7/2024 3:04 AM, Zhaoxiong Lv wrote:
> > Move the "exit sleep mode" and "set display on" command from
> > enable() to init() function.
> >
> > As mentioned in the patch:
> > https://lore.kernel.org/all/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com/
> >
> > The Mediatek Soc DSI host has different modes in prepare() and
> > enable() functions, prepare() is in LP mode and enable() is in
> > HS mode. Since the "exit sleep mode" and "set display on"
> > command must also be sent in LP mode, so we also move "exit
> > sleep mode" and "set display on" command to the init() function.
> >
> > We have no other actions in the enable() function after moves
> > "exit sleep mode" and "set display on", and we checked the call
> > of the enable() function during the "startup" process. It seems
> > that only one judgment was made in drm_panel_enabel(). If the
> > panel does not define enable(), the judgment will skip the
> > enable() and continue execution. This does not seem to have
> > any other effect, and we found that some drivers also seem
> > to have no enable() function added, for example:
> > panel-asus-z00t-tm5p5-n35596 / panel-boe-himax8279d...
> > In addition, we briefly tested the kingdisplay_kd101ne3 panel and
> > melfas_lmfbx101117480 panel, and it seems that there is no garbage
> > on the panel, so we delete enable() function.
> >
> > After moving the "exit sleep mode" and "set display on" command
> > to the init() function, we no longer need additional delay
> > judgment, so we delete variables "exit_sleep_to_display_on_delay_ms"
> > and "display_on_delay_ms".
> >
> > Reviewed-by: Douglas Anderson <dianders at chromium.org>
> > Signed-off-by: Zhaoxiong Lv <lvzhaoxiong at huaqin.corp-partner.google.com>
>
> Acked-by: Jessica Zhang <quic_jesszhan at quicinc.com>

Does this Ack mean you're confident enough about this patch that we
should go ahead and merge it, or do you think we should wait on
anything else (like Neil getting a chance to look at it)? As I
mentioned in my reply to the cover letter [1] the patches look OK to
me but I still don't consider myself to have a wonderful understanding
of the intricacies of MIPI DSI. If you think this is OK from a MIPI
DSI point of view then we can land it...

[1] https://lore.kernel.org/r/CAD=FV=WCw6pAump-PUFCW0cgbRY+5_2tPNLe=hN3-dnXD=B6MA@mail.gmail.com

Thanks!

-Doug