linux-kernel - Re: [PATCH v2 2/3] drm/mediatek: Fix mode valid issue for dp

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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAOTY_9R89cgXiM_JhJS88hk0Mc-pXGG9dCGUAyTak98mNSocg@mail.gmail.com>
Date: Mon, 30 Dec 2024 22:33:50 +0800
From: Chun-Kuang Hu <chunkuang.hu@...nel.org>
To: Liankun Yang <liankun.yang@...iatek.com>
Cc: chunkuang.hu@...nel.org, p.zabel@...gutronix.de, airlied@...il.com, 
	simona@...ll.ch, matthias.bgg@...il.com, 
	angelogioacchino.delregno@...labora.com, ck.hu@...iatek.com, 
	dmitry.osipenko@...labora.com, msp@...libre.com, rex-bc.chen@...iatek.com, 
	granquet@...libre.com, peng.liu@...iatek.com, jitao.shi@...iatek.com, 
	mac.shen@...iatek.com, Project_Global_Chrome_Upstream_Group@...iatek.com, 
	dri-devel@...ts.freedesktop.org, linux-mediatek@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/3] drm/mediatek: Fix mode valid issue for dp

Hi, Liankun:

Liankun Yang <liankun.yang@...iatek.com> 於 2024年10月25日 週五 下午4:31寫道：
>
> Fix dp mode valid issue to avoid abnormal display of limit state.
>
> After DP passes link training, it can express the lane count of the
> current link status is good. Calculate the maximum bandwidth supported
> by DP using the current lane count.
>
> The color format will select the best one based on the bandwidth
> requirements of the current timing mode. If the current timing mode
> uses RGB and meets the DP link bandwidth requirements, RGB will be used.
>
> If the timing mode uses RGB but does not meet the DP link bandwidthi
> requirements, it will continue to check whether YUV422 meetsi
> the DP link bandwidth.
>
> FEC overhead is approximately 2.4% from DP 1.4a spec 2.2.1.4.2.
> The down-spread amplitude shall either be disabled (0.0%) or up
> to 0.5% from 1.4a 3.5.2.6. Add up to approximately 3% total overhead.
>
> Because rate is already divided by 10,
> mode->clock does not need to be multiplied by 10.

Applied to mediatek-drm-fixes [1], thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes

Regards,
Chun-Kuang.

>
> Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
> Signed-off-by: Liankun Yang <liankun.yang@...iatek.com>
> ---
> Change in V2:
> - Adjust the writing style.
> - Add instructions.
> ---
>  drivers/gpu/drm/mediatek/mtk_dp.c | 28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index 613e1c842478..ae4807823a5c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2328,12 +2328,19 @@ mtk_dp_bridge_mode_valid(struct drm_bridge *bridge,
>  {
>         struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
>         u32 bpp = info->color_formats & DRM_COLOR_FORMAT_YCBCR422 ? 16 : 24;
> -       u32 rate = min_t(u32, drm_dp_max_link_rate(mtk_dp->rx_cap) *
> -                             drm_dp_max_lane_count(mtk_dp->rx_cap),
> -                        drm_dp_bw_code_to_link_rate(mtk_dp->max_linkrate) *
> -                        mtk_dp->max_lanes);
> +       u32 lane_count_min = mtk_dp->train_info.lane_count;
> +       u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) *
> +                        lane_count_min;
>
> -       if (rate < mode->clock * bpp / 8)
> +       /*
> +        *FEC overhead is approximately 2.4% from DP 1.4a spec 2.2.1.4.2.
> +        *The down-spread amplitude shall either be disabled (0.0%) or up
> +        *to 0.5% from 1.4a 3.5.2.6. Add up to approximately 3% total overhead.
> +        *
> +        *Because rate is already divided by 10,
> +        *mode->clock does not need to be multiplied by 10
> +        */
> +       if ((rate * 97 / 100) < (mode->clock * bpp / 8))
>                 return MODE_CLOCK_HIGH;
>
>         return MODE_OK;
> @@ -2374,10 +2381,9 @@ static u32 *mtk_dp_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>         struct drm_display_mode *mode = &crtc_state->adjusted_mode;
>         struct drm_display_info *display_info =
>                 &conn_state->connector->display_info;
> -       u32 rate = min_t(u32, drm_dp_max_link_rate(mtk_dp->rx_cap) *
> -                             drm_dp_max_lane_count(mtk_dp->rx_cap),
> -                        drm_dp_bw_code_to_link_rate(mtk_dp->max_linkrate) *
> -                        mtk_dp->max_lanes);
> +       u32 lane_count_min = mtk_dp->train_info.lane_count;
> +       u32 rate = drm_dp_bw_code_to_link_rate(mtk_dp->train_info.link_rate) *
> +                        lane_count_min;
>
>         *num_input_fmts = 0;
>
> @@ -2386,8 +2392,8 @@ static u32 *mtk_dp_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>          * datarate of YUV422 and sink device supports YUV422, we output YUV422
>          * format. Use this condition, we can support more resolution.
>          */
> -       if ((rate < (mode->clock * 24 / 8)) &&
> -           (rate > (mode->clock * 16 / 8)) &&
> +       if (((rate * 97 / 100) < (mode->clock * 24 / 8)) &&
> +           ((rate * 97 / 100) > (mode->clock * 16 / 8)) &&
>             (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) {
>                 input_fmts = kcalloc(1, sizeof(*input_fmts), GFP_KERNEL);
>                 if (!input_fmts)
> --
> 2.45.2
>