Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966266AbeAORMG (ORCPT + 1 other); Mon, 15 Jan 2018 12:12:06 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:56752 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965179AbeAORME (ORCPT ); Mon, 15 Jan 2018 12:12:04 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20180115171202euoutp024f5c1a651f0cf42b39164778835e5c90~KCwC_CDNp2777927779euoutp02a X-AuditID: cbfec7f2-f793b6d000003243-03-5a5ce0e1174e MIME-version: 1.0 Content-type: text/plain; charset="utf-8" Subject: Re: [PATCH v2] drm/bridge/synopsys: dsi: add optional pixel clock To: Philippe CORNU , Archit Taneja , Laurent Pinchart , David Airlie , Philipp Zabel , Benjamin Gaignard , Bhumika Goyal , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Cc: Yannick FERTRE , Vincent ABRIOU , Alexandre TORGUE , Maxime Coquelin , Gabriel FERNANDEZ , Ludovic BARRE , Fabien DESSENNE , Mickael REULIER , Brian Norris From: Andrzej Hajda Message-id: <87a1d69d-c7a0-de01-8c95-15711d59a4cf@samsung.com> Date: Mon, 15 Jan 2018 18:11:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 In-reply-to: Content-transfer-encoding: 8bit Content-language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOd9tn8PZ5zQ9aGQtjIzyQlIHNako+Kp/jCBsiDbyQyVvbGoq Bd6bWtllpc7SSLOLpGSlJVlz2rZUJNMib3OamkSl08wLajm/Ff73e8/7POe878OhcfF30oWO ik3g5LGyaAklJOp08x07h0whUm+V0hFd6niHoScjbQBlKH+QKEPbSqEpYwGFas0TJOqemaCQ rroeoKzBdgzlXq0QoK6GWxRq0exHpUuPSdTapMXQgNFAIFPWOInaP2oIdCE3m9onZkvSOgm2 6/IljH2pHhCwJcpiku3/9Ipi63+bSHYwX4+xBUve7OhcI85O124MEkqFAeFcdFQSJ/cKPCWM zLqRj8cXeSSPqMrxNNC8OQ/QNGR84ZAhIA/YrKATfG+sofKAkBYz9wAsrRzG+GIawMK+SYxX +cLLs3rKwmKmEsCmflcLixh7OHfdSFgYZzzg+K9rBG8eA/D2wwnS0nBgjsAKzVXcwo5MPQ7v qzDekIPDMmOohakV89LTHoq/NBC2FX1Z9RKMO7xpHlnl9UwwzBtrWGUbxg+2jBlw/h432NT9 1TqEM8zM7lkdAjI6ASweqrZucBBmmjMFPDvAb/pnVt4Au67nWw35AE4VGAR8oQJwebII51X+ sFnfSfJP2MFrdYU4H6QIKnPEvISFb+9WW+X7YV/7LPE/xweNJuIKcFOviUy9JjL1mi3Ua7a4 A4hHwJFLVMREcIpdngpZjCIxNsLzdFxMLVj5g23L+qkXYMbgpwUMDSS2IlQXIhWTsiRFSowW QBqXOIrSj68cicJlKamcPC5MnhjNKbTAlSYkzqK90pyTYiZClsCd4bh4Tv6vi9E2LmngrM7G fOjw6J5gp61bFkLWuczPahaHL1bfau4ZFZmO3bxi161zvu3hvpCjZPwlxf4pN+aoyIkFf5Vt u2tN6Ejv59igNz6jm+xPBH3Ybi4ve559Pkz3M66SkSwF+Wp95kOXvV78qdJ4H11MNp3bFpje MJ26bgfnNjjweqFXursq8sC8hFBEyny243KF7C+gDhWrfwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsVy+t/xy7oPHsREGVz/q2vRe+4kk8XGJ6cZ LZo63rJaNB06xWbx6V4/m8Wmj+9ZLa58fc9mcWzddkaLlvtnmCw6Jy5ht7i8aw6bxZEDjhbz /q5ltTh18BCTxd17J1gsHrS8YLU4c/UAi0V7Zyubg5DH7IaLLB6X+3qZPHbOusvuMbtjJqvH nWt72Dy2f3vA6nG/+ziTR/9fA4+nP/Yye3zeJBfAFcVlk5Kak1mWWqRvl8CV0TK1m7lghmbF kymLmRsYDyt2MXJySAiYSPR9P84GYYtJXLi3Hsjm4hASWMIosXzbUiaQBK+AoMSPyfdYuhg5 OJgF1CWmTMmFqHnGKHF3QgcLSI2wgJfEkgMTmUFsEYGdzBKL9oSCFDEL9DBLTGl+zw7R8ZVR onPpNrCpbAKaEn8332SD2GAncXrGY1YQm0VAVWLaxydgtqhAhETTzLlgNqeAlcSRZyfANjAL yEscvPKcBcIWl2huvckygVFwFpJjZyEcOwtJxywkHQsYWVYxiqSWFuem5xYb6RUn5haX5qXr JefnbmIERuy2Yz+37GDsehd8iFGAg1GJh9diW0yUEGtiWXFl7iFGCQ5mJRHexmCgEG9KYmVV alF+fFFpTmrxIUZpDhYlcd7ePasjhQTSE0tSs1NTC1KLYLJMHJxSDYxRW8+3dAYK2nUJVKf7 ND3w1J6vnh9b7V3B3mfcf3NXYVq18oaz7/P2fd3Qo6Ohw2F6pU71vhv38xOmmfop06K8uYWl 39t/iWhlTtD5GnDxZG1j1jE2Nb+X1fNC/pTXJi584FB3jvv4obv1BrJsTizW6mekH20yNJh+ fPKF+KnXp0vpX1bsU2Ipzkg01GIuKk4EAIWvw9HUAgAA X-CMS-MailID: 20180115171200eucas1p128f916dc7d763e3fe9eb1232ee2f26de X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180112162603epcas5p31b20a27fc66410b136b47f7278d04c87 X-RootMTR: 20180112162603epcas5p31b20a27fc66410b136b47f7278d04c87 References: <20180112162530.31432-1-philippe.cornu@st.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 15.01.2018 15:40, Philippe CORNU wrote: > Hi Andrzej, > > On 01/15/2018 02:52 PM, Andrzej Hajda wrote: >> On 12.01.2018 17:25, Philippe Cornu wrote: >>> The pixel clock is optional. When available, 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 dependent). >>> >>> Signed-off-by: Philippe Cornu >>> --- >>> Changes in v2: Improve px_clk probing in case of ENOENT dt returned value >>> (thanks to Philipp Zabel & Andrzej Hajda comments) >>> >>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 26 ++++++++++++++++++++------ >>> 1 file changed, 20 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 c39c7dce20ed..62fcff881b98 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >>> @@ -225,6 +225,7 @@ struct dw_mipi_dsi { >>> void __iomem *base; >>> >>> struct clk *pclk; >>> + struct clk *px_clk; >>> >>> unsigned int lane_mbps; /* per lane */ >>> u32 channel; >>> @@ -753,24 +754,28 @@ void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge, >>> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge); >>> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops; >>> void *priv_data = dsi->plat_data->priv_data; >>> + struct drm_display_mode px_clk_mode = *mode; >>> int ret; >>> >>> clk_prepare_enable(dsi->pclk); >>> >>> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags, >>> + if (dsi->px_clk) >>> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000; >>> + >>> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_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, &px_clk_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, &px_clk_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, &px_clk_mode); >>> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode); >>> >>> dw_mipi_dsi_dphy_init(dsi); >>> dw_mipi_dsi_dphy_timing_config(dsi); >>> @@ -784,7 +789,7 @@ 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(&px_clk_mode); >>> >>> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */ >>> dw_mipi_dsi_set_mode(dsi, 0); >>> @@ -878,6 +883,15 @@ __dw_mipi_dsi_probe(struct platform_device *pdev, >>> return ERR_PTR(ret); >>> } >>> >>> + dsi->px_clk = devm_clk_get(dev, "px_clk"); >>> + if (PTR_ERR(dsi->px_clk) == -ENOENT) { >>> + dsi->px_clk = NULL; >>> + } else if (IS_ERR(dsi->px_clk)) { >>> + ret = PTR_ERR(dsi->px_clk); >>> + dev_err(dev, "Unable to get optional px_clk: %d\n", ret); >>> + dsi->px_clk = NULL; >>> + } >>> + >> As I understand on fail you just log an error and continue? >> The code could be slightly simplified, for example: >> dsi->px_clk = devm_clk_get(dev, "px_clk"); >> if (IS_ERR(dsi->px_clk)) { >>         ret = PTR_ERR(dsi->px_clk); >>         if (ret != ENOENT) >>                 dev_err(dev, "Unable to get optional px_clk: %d\n", ret); >>         dsi->px_clk = NULL; >> } >> >> With or without this change: >> >> Reviewed-by: Andrzej Hajda >> > Thanks for your review. > > Yes in this version, on fail, I just log an error and continue, > especially because this px_clk is "optional" in the documentation. Then > your proposal is much better than mine : ) > > Nevertheless, I wonder now if it could be better to "return" in case of > error as we do for others mandatory clocks... > So then, the code could be: > > dsi->px_clk = devm_clk_get(dev, "px_clk"); > if (IS_ERR(dsi->px_clk)) { > dsi->px_clk = NULL; > ret = PTR_ERR(dsi->px_clk); > if (ret != ENOENT) { > dev_err(dev, "Unable to get optional px_clk: %d\n", ret); > return ERR_PTR(ret); > } > } > > > Do you (or someone else) have a preferred choice? No strong feelings, but I would slightly prefer current version: error is reported but the driver tries to do the best to continue work. On the other side it increases risk that the error will be ignored and potential bug not fixed. Choice between robustness and strictness. Regards Andrzej > > > Many thanks, > Philippe :-) > >>  -- >> Regards >> Andrzej >> >> >>> /* >>> * Note that the reset was not defined in the initial device tree, so >>> * we have to be prepared for it not being found.