Hi Philippe, On Thursday, 8 February 2018 15:15:40 EEST Laurent Pinchart wrote: > On Saturday, 3 February 2018 00:41:26 EET Philippe CORNU wrote: > > On 01/29/2018 11:40 AM, Laurent Pinchart wrote: > > > On Monday, 29 January 2018 12:17:37 EET Philippe CORNU wrote: > > >> On 01/29/2018 10:46 AM, Laurent Pinchart wrote: > > >>> 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.co...@st.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. > > >> > > >> This is exactly the reason why my first implementation used the dsi > > >> bridge "optional pixel clock" instead of the adjusted_mode (see [1]) > > >> > > >> But after digging more into the drm source code, I think using > > >> adjusted_mode instead of the pixel clock here brings more advantages > > >> because: > > >> * adjusted_mode is an argument of bridge mode_set() probably for being > > >> used in any manner, maybe like this :) > > >> * if the bridge "user" (crtc or a master bridge drivers) does not need > > >> to modify its adjusted_mode then mode & adjusted_mode mode_set() > > >> arguments will have the same values so "no consequence" for the bridge. > > >> * if the bridge "user" (crtc or master bridge drivers) needs to adjust > > >> any value of the mode then this adjustment is available for the bridge. > > > > > > Remember that there can be multiple chained bridges, and a single > > > adjusted mode field. > > > > > >> * rockchip crtc updates a part of the mode (the clock), stm is doing > > >> the > > >> same (see [2]) but any future "user" of the dw_mipi_dsi bridge can > > >> adjust something else (blankings...) and the dw_mipi_dsi bridge will be > > >> then aware of... > > >> > > >> But maybe it is a wrong usage of the "adjusted_mode offer"... > > > > > > I don't disagree that there's a need for using adjusted values, but I > > > believe we need to create a clear API to do so. Using the adjust_mode > > > field as-is when it's clearly documented as being implementation-defined > > > is asking for trouble. > > > > Laurent, do you think we can use "adjusted mode" here in this small > > patch as the actual 2 "users" of this bridge (rockchip & stm) use both > > "adjusted mode" in their crtc? > > The Synopsys DSI driver might only be used by two display controller drivers > today, it is nonetheless a standard bridge driver that should not make any > assumption of a particular use of the adjusted_mode in particular display > controller drivers. To use the adjusted_mode value in bridge drivers we > need to standardize its usage, otherwise we'll end up with > incompatibilities between bridge drivers and display controller drivers.
Now that the documentation has been clarified I have no objection against this patch anymore. > > >> [1] https://patchwork.freedesktop.org/patch/200240/ > > >> [2] https://patchwork.freedesktop.org/patch/200720/ > > >> > > >>> Daniel, what's your opinion on this ? > > > > Daniel, any opinion on the adjusted_mode usage? > > > > >>>> --- > > >>>> 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
