Message-ID: <CAAOTY_8=HvU8p=6xG5_bNHtjXOsQwNAn1zqHF6AmwtOReZ_Xzw@mail.gmail.com>
Date:   Thu, 28 May 2020 07:27:51 +0800
From:   Chun-Kuang Hu <chunkuang.hu@...nel.org>
To:     Jitao Shi <jitao.shi@...iatek.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        srv_heupstream <srv_heupstream@...iatek.com>,
        huijuan.xie@...iatek.com, stonea168@....com,
        cawa.cheng@...iatek.com,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        Bibby Hsieh <bibby.hsieh@...iatek.com>,
        CK Hu <ck.hu@...iatek.com>, yingjoe.chen@...iatek.com,
        eddie.huang@...iatek.com,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] drm/mediatek: dsi: fix scrolling of panel with small hfp
 or hbp

Hi, Jitao:

Jitao Shi <jitao.shi@...iatek.com> 於 2020年5月22日 週五 下午6:12寫道：
>
> If panel has too small hfp or hbp, horizontal_frontporch_byte or
> horizontal_backporch_byte may become very small value or negative
> value. This patch adjusts their values so that they are greater
> than minimum value and keep total of them unchanged.
>
> Signed-off-by: Jitao Shi <jitao.shi@...iatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0ede69830a9d..aebaafd90ceb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -148,6 +148,9 @@
>         (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
>         (type == MIPI_DSI_DCS_READ))
>
> +#define MIN_HFP_BYTE           0x02
> +#define MIN_HBP_BYTE           0x02
> +
>  struct mtk_phy_timing {
>         u32 lpx;
>         u32 da_hs_prepare;
> @@ -450,6 +453,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>         u32 horizontal_sync_active_byte;
>         u32 horizontal_backporch_byte;
>         u32 horizontal_frontporch_byte;
> +       s32 signed_hfp_byte, signed_hbp_byte;
>         u32 dsi_tmp_buf_bpp, data_phy_cycles;
>         struct mtk_phy_timing *timing = &dsi->phy_timing;
>
> @@ -519,6 +523,20 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>                 }
>         }
>
> +       signed_hfp_byte = (s32)horizontal_frontporch_byte;
> +       signed_hbp_byte = (s32)horizontal_backporch_byte;
> +
> +       if (signed_hfp_byte + signed_hbp_byte < MIN_HFP_BYTE + MIN_HBP_BYTE) {
> +               DRM_WARN("Calculated hfp_byte and hbp_byte are too small, "
> +                        "panel may not work properly.\n");
> +       } else if (signed_hfp_byte < MIN_HFP_BYTE) {
> +               horizontal_frontporch_byte = MIN_HFP_BYTE;
> +               horizontal_backporch_byte -= MIN_HFP_BYTE - signed_hfp_byte;
> +       } else if (signed_hbp_byte < MIN_HBP_BYTE) {
> +               horizontal_frontporch_byte -= MIN_HBP_BYTE - signed_hbp_byte;
> +               horizontal_backporch_byte = MIN_HBP_BYTE;
> +       }
> +

I think horizontal_frontporch_byte would never be negtive, and
horizontal_backporch_byte would be negtive when

 if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
horizontal_backporch_byte =
(vm->hback_porch * dsi_tmp_buf_bpp - 10);
else
horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
dsi_tmp_buf_bpp - 10);

If this time it's negtive, the calculation of
horizontal_frontporch_byte is so strange.
I think processing negtive value should before here.

Regards,
Chun-Kuang.

>         writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
>         writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
>         writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> --
> 2.25.1
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Powered by blists - more mailing lists