linux-kernel - Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2782155.lsFkNecG25@avalon>
Date:   Mon, 29 Jan 2018 11:46:35 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Philippe Cornu <philippe.cornu@...com>
Cc:     Archit Taneja <architt@...eaurora.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        David Airlie <airlied@...ux.ie>,
        Brian Norris <briannorris@...omium.org>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Bhumika Goyal <bhumirks@...il.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Sandy Huang <hjc@...k-chips.com>,
        Heiko Stubner <heiko@...ech.de>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org,
        Yannick Fertre <yannick.fertre@...com>,
        Vincent Abriou <vincent.abriou@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Ludovic Barre <ludovic.barre@...com>,
        Mickael Reulier <mickael.reulier@...com>,
        daniel.vetter@...ll.ch
Subject: Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

Hi Philippe,

(CC'ing Daniel Vetter)

Thank you for the patch.

On Thursday, 25 January 2018 17:55:04 EET Philippe Cornu wrote:
> The "adjusted_mode" clock value (ie the real pixel clock) is more
> accurate than "mode" clock value (ie the panel/bridge requested
> clock value). It offers a better preciseness for timing
> computations and allows to reduce the extra dsi bandwidth in
> burst mode (from ~20% to ~10-12%, hw platform dependant).
> 
> Signed-off-by: Philippe Cornu <philippe.cornu@...com>

The adjusted mode is documented as

    /**
     * @adjusted_mode:
     *
     * Internal display timings which can be used by the driver to handle
     * differences between the mode requested by userspace in @mode and what
     * is actually programmed into the hardware. It is purely driver
     * implementation defined what exactly this adjusted mode means. Usually
     * it is used to store the hardware display timings used between the
     * CRTC and encoder blocks.
     */

This is easy to handle when the CRTC and encoder are controlled by the same 
driver, as the field is "implementation defined" by a single driver . However, 
when using bridges, there are two drivers involved, and they must both agree 
to meaningfully use the adjusted mode. I can't see how to do so without 
standardizing the meaning of the adjusted mode field.

Daniel, what's your opinion on this ?

> ---
> Note: This patch replaces "drm/bridge/synopsys: dsi: add optional pixel
> clock"
> 
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
> ed8af32f8e52..b926b62e9e33 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -707,20 +707,20 @@ static void dw_mipi_dsi_bridge_mode_set(struct
> drm_bridge *bridge,
> 
>  	clk_prepare_enable(dsi->pclk);
> 
> -	ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
> +	ret = phy_ops->get_lane_mbps(priv_data, adjusted_mode, dsi->mode_flags,
>  				     dsi->lanes, dsi->format, &dsi->lane_mbps);
>  	if (ret)
>  		DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
> 
>  	pm_runtime_get_sync(dsi->dev);
>  	dw_mipi_dsi_init(dsi);
> -	dw_mipi_dsi_dpi_config(dsi, mode);
> +	dw_mipi_dsi_dpi_config(dsi, adjusted_mode);
>  	dw_mipi_dsi_packet_handler_config(dsi);
>  	dw_mipi_dsi_video_mode_config(dsi);
> -	dw_mipi_dsi_video_packet_config(dsi, mode);
> +	dw_mipi_dsi_video_packet_config(dsi, adjusted_mode);
>  	dw_mipi_dsi_command_mode_config(dsi);
> -	dw_mipi_dsi_line_timer_config(dsi, mode);
> -	dw_mipi_dsi_vertical_timing_config(dsi, mode);
> +	dw_mipi_dsi_line_timer_config(dsi, adjusted_mode);
> +	dw_mipi_dsi_vertical_timing_config(dsi, adjusted_mode);
> 
>  	dw_mipi_dsi_dphy_init(dsi);
>  	dw_mipi_dsi_dphy_timing_config(dsi);
> @@ -734,7 +734,7 @@ static void dw_mipi_dsi_bridge_mode_set(struct
> drm_bridge *bridge,
> 
>  	dw_mipi_dsi_dphy_enable(dsi);
> 
> -	dw_mipi_dsi_wait_for_two_frames(mode);
> +	dw_mipi_dsi_wait_for_two_frames(adjusted_mode);
> 
>  	/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
>  	dw_mipi_dsi_set_mode(dsi, 0);

-- 
Regards,

Laurent Pinchart