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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jessica,

On Thu, Aug 8, 2024 at 3:56 PM Jessica Zhang <quic_jesszhan@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >
> > 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@xxxxxxxxxxxx>
> > Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Acked-by: Jessica Zhang <quic_jesszhan@xxxxxxxxxxx>

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@xxxxxxxxxxxxxx

Thanks!

-Doug




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux