| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Jun 2024 18:55:31 +0800
From: zhaoxiong lv <lvzhaoxiong@...qin.corp-partner.google.com>
To: Jessica Zhang <quic_jesszhan@...cinc.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 Wed, Jun 26, 2024 at 1:49 AM Jessica Zhang <quic_jesszhan@...cinc.com> wrote:
>
>
>
> 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
hi jessica
The initial default setting of our host DSI is the LP mode.
>
> >
> >
> >>
> >>> ---
> >>> 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