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]

 



On 12/08/2024 17:45, Doug Anderson wrote:
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...

I don't have an advanced MIPI DSI knowledge, but they simple remove unneeded
sleeps between dcs commands, so if they are confident they can be removed I agree...

Neil


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

Thanks!

-Doug





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux