Hi Philippe, I've tried your patch on both 4.17-rc1 & drm-misc-next and it works fine. So, Reviewed-by: Yannick Fertré <yannick.fertre@xxxxxx> Tested-by: Yannick Fertré <yannick.fertre@xxxxxx> BR Yannick Fertré On 04/23/2018 12:10 PM, Laurent Pinchart wrote: > 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.cornu@xxxxxx> >>>>>> >>>>>> 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); > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
