From: Philippe CORNU <philippe.cornu@st.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Archit Taneja <architt@codeaurora.org>,
Andrzej Hajda <a.hajda@samsung.com>,
David Airlie <airlied@linux.ie>,
Brian Norris <briannorris@chromium.org>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Bhumika Goyal <bhumirks@gmail.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Sandy Huang <hjc@rock-chips.com>,
"Heiko Stubner" <heiko@sntech.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
Yannick FERTRE <yannick.fertre@st.com>,
Vincent ABRIOU <vincent.abriou@st.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Ludovic BARRE <ludovic.barre@st.com>,
Mickael REULIER <mickael.reulier@st.com>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set
Date: Mon, 29 Jan 2018 10:17:37 +0000 [thread overview]
Message-ID: <114a9fc1-3f31-decd-6bdc-803dc88b3b3c@st.com> (raw)
In-Reply-To: <2782155.lsFkNecG25@avalon>
Hi Laurent,
And many thanks for your comments :)
On 01/29/2018 10:46 AM, Laurent Pinchart wrote:
> 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@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.
* 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"...
Many thanks,
Philippe :-)
[1] https://patchwork.freedesktop.org/patch/200240/
[2] https://patchwork.freedesktop.org/patch/200720/
>
> 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);
>
next prev parent reply other threads:[~2018-01-29 10:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180125155556epcas2p107973eb77ab08c436dbddcb66fcb7c89@epcas2p1.samsung.com>
2018-01-25 15:55 ` Philippe Cornu
2018-01-25 22:47 ` Brian Norris
2018-01-26 9:54 ` Philippe CORNU
2018-01-29 4:14 ` Archit Taneja
2018-01-29 9:46 ` Laurent Pinchart
2018-01-29 10:17 ` Philippe CORNU [this message]
2018-01-29 10:40 ` Laurent Pinchart
2018-02-02 22:41 ` Philippe CORNU
2018-02-08 13:15 ` Laurent Pinchart
2018-04-23 10:10 ` Laurent Pinchart
2018-04-23 12:29 ` Yannick FERTRE
2018-04-26 6:33 ` Andrzej Hajda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=114a9fc1-3f31-decd-6bdc-803dc88b3b3c@st.com \
--to=philippe.cornu@st.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=alexandre.torgue@st.com \
--cc=architt@codeaurora.org \
--cc=benjamin.gaignard@linaro.org \
--cc=bhumirks@gmail.com \
--cc=briannorris@chromium.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=ludovic.barre@st.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mickael.reulier@st.com \
--cc=vincent.abriou@st.com \
--cc=yannick.fertre@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®