Message-ID: <a5734572-c822-493a-a15a-63dcf37d60cc@quicinc.com>
Date: Tue, 25 Jun 2024 10:49:50 -0700
From: Jessica Zhang <quic_jesszhan@...cinc.com>
To: zhaoxiong lv <lvzhaoxiong@...qin.corp-partner.google.com>
CC: <dmitry.torokhov@...il.com>, <robh@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <jikos@...nel.org>, <benjamin.tissoires@...hat.co>,
        <dianders@...gle.com>, <hsinyi@...gle.com>, <jagan@...eble.ai>,
        <neil.armstrong@...aro.org>, <dmitry.baryshkov@...aro.org>,
        <dri-devel@...ts.freedesktop.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Shuijing Li
	<shuijing.li@...iatek.corp-partner.google.com>
Subject: Re: [PATCH v5 1/5] drm/panel: jd9365da: Modify the method of sending
 commands



On 6/25/2024 5:13 AM, zhaoxiong lv wrote:
> On Tue, Jun 25, 2024 at 7:41 AM Jessica Zhang <quic_jesszhan@...cinc.com> wrote:
>>
>>
>>
>> On 6/24/2024 7:19 AM, Zhaoxiong Lv wrote:
>>> Currently, the init_code of the jd9365da driver is placed
>>> in the enable() function and sent, but this seems to take
>>> a long time. It takes 17ms to send each instruction (an init
>>> code consists of about 200 instructions), so it takes
>>> about 3.5s to send the init_code. So we moved the sending
>>> of the inti_code to the prepare() function, and each
>>> instruction seemed to take only 25μs.
>>>
>>> We checked the DSI host and found that the difference in
>>> command sending time is caused by the different modes of
>>> the DSI host in prepare() and enable() functions.
>>> Our DSI Host only supports sending cmd in LP mode, The
>>> prepare() function can directly send init_code (LP->cmd)
>>> in LP mode, but the enable() function is in HS mode and
>>> needs to switch to LP mode before sending init code
>>> (HS->LP->cmd->HS). Therefore, it takes longer to send
>>> the command.
>>>
>>> Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@...qin.corp-partner.google.com>
>>
>> Hi Zhaoxiong,
>>
>> Just curious, if the host expects that commands are sent in LP mode, why
>> isn't the MIPI_DSI_MODE_LPM flag set before sending the DCS commands?
>>
>> Thanks,
>>
>> Jessica Zhang
> 
> hi jessica
> 
> We have tried to set dsi->mode_flags to MIPI_DSI_MODE_LPM in the
> probe() function,
> but this seems to still happen. MTK colleagues believe that the host
> dsi configuration is
> still in LP mode during the prepare() function, and when in the
> enable() function, the host
> dsi is already in HS mode. However, since the command must be sent in
> LP mode, it will
> switch back and forth between HS->LP->HS.
> 
> Add Mediatek colleagues（shuijing.li@...iatek.corp-partner.google.com）

Got it. Even drivers that call their init commands in prepare() set the 
LPM flag [1][2] when applicable so I was just wondering why this driver 
doesn't seem to set LPM at all even though it is going into LP mode.

[1] 
https://elixir.bootlin.com/linux/v6.10-rc5/source/drivers/gpu/drm/panel/panel-visionox-vtdr6130.c#L46

[2] 
https://elixir.bootlin.com/linux/v6.10-rc5/source/drivers/gpu/drm/panel/panel-visionox-r66451.c#L46

> 
> 
>>
>>> ---
>>> Changes between V5 and V4:
>>> - 1. No changes.
>>>
>>> V4:https://lore.kernel.org/all/20240620080509.18504-2-lvzhaoxiong@huaqin.corp-partner.google.com/
>>>
>>> Changes between V4 and V3:
>>> - 1. Only move mipi_dsi_dcs_write_buffer from enable() function to prepare() function,
>>> -    and no longer use mipi_dsi_dcs_write_seq_multi.
>>>
>>> V3:https://lore.kernel.org/all/20240614145510.22965-2-lvzhaoxiong@huaqin.corp-partner.google.com/
>>>
>>> ---
>>>    .../gpu/drm/panel/panel-jadard-jd9365da-h3.c  | 24 +++++++++----------
>>>    1 file changed, 11 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>>> index 4879835fe101..a9c483a7b3fa 100644
>>> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>>> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>>> @@ -52,21 +52,9 @@ static int jadard_enable(struct drm_panel *panel)
>>>    {
>>>        struct device *dev = panel->dev;
>>>        struct jadard *jadard = panel_to_jadard(panel);
>>> -     const struct jadard_panel_desc *desc = jadard->desc;
>>>        struct mipi_dsi_device *dsi = jadard->dsi;
>>> -     unsigned int i;
>>>        int err;
>>>
>>> -     msleep(10);
>>> -
>>> -     for (i = 0; i < desc->num_init_cmds; i++) {
>>> -             const struct jadard_init_cmd *cmd = &desc->init_cmds[i];
>>> -
>>> -             err = mipi_dsi_dcs_write_buffer(dsi, cmd->data, JD9365DA_INIT_CMD_LEN);
>>> -             if (err < 0)
>>> -                     return err;
>>> -     }
>>> -
>>>        msleep(120);
>>>
>>>        err = mipi_dsi_dcs_exit_sleep_mode(dsi);
>>> @@ -100,6 +88,8 @@ static int jadard_disable(struct drm_panel *panel)
>>>    static int jadard_prepare(struct drm_panel *panel)
>>>    {
>>>        struct jadard *jadard = panel_to_jadard(panel);
>>> +     const struct jadard_panel_desc *desc = jadard->desc;
>>> +     unsigned int i;
>>>        int ret;
>>>
>>>        ret = regulator_enable(jadard->vccio);
>>> @@ -117,7 +107,15 @@ static int jadard_prepare(struct drm_panel *panel)
>>>        msleep(10);
>>>
>>>        gpiod_set_value(jadard->reset, 1);
>>> -     msleep(120);
>>> +     msleep(130);
>>> +
>>> +     for (i = 0; i < desc->num_init_cmds; i++) {
>>> +             const struct jadard_init_cmd *cmd = &desc->init_cmds[i];
>>> +
>>> +             ret = mipi_dsi_dcs_write_buffer(dsi, cmd->data, JD9365DA_INIT_CMD_LEN);
>>> +             if (ret < 0)
>>> +                     return ret;
>>> +     }
>>>
>>>        return 0;
>>>    }
>>> --
>>> 2.17.1
>>>

Powered by blists - more mailing lists