dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Guido Günther" <agx@sigxcpu.org>
To: "Robert Chiras (OSS)" <robert.chiras@oss.nxp.com>
Cc: Ondrej Jirman <megous@megous.com>,
	devicetree@vger.kernel.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>,
	Neil Armstrong <narmstrong@baylibre.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Rob Herring <robh+dt@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-imx@nxp.com
Subject: Re: [PATCH 3/5] drm/bridge: nwl-dsi: Add support for clock-drop-level
Date: Sun, 6 Sep 2020 12:28:20 +0200	[thread overview]
Message-ID: <20200906102820.GA3472@bogon.m.sigxcpu.org> (raw)
In-Reply-To: <1598613212-1113-4-git-send-email-robert.chiras@oss.nxp.com>

Hi Robert,
On Fri, Aug 28, 2020 at 02:13:30PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras <robert.chiras@nxp.com>
> 
> The clock-drop-level is needed in order to add more blanking space needed
> by DSI panels when sending DSI commands. One level is the equivalent of
> phy_ref rate from the PLL rate. Since the PLL rate is targeted as highest
> possible, each level should not get the crtc_clock too low, compared to
> the actual clock.

Did you check whether this is only needed during panel prepare (when the
image sequence is being sent)? I wonder if this is an artifact of the
driver sending pixel data too early - and if it's not whether we have
something else wrong so that we need to have a longer blanking period
with some panels?

Cheers,
 -- Guido

> 
> Example for a clock of 132M, with "clock-drop-level = <1>" in dts file
> will result in a crtc_clock of 129M, using the following logic:
> - video_pll rate to provide both phy_ref rate of 24M and pixel-clock
>   of 132M is 1056M (divisor /43 for phy_ref and /8 for pixel-clock)
> - from this rate, we subtract the equivalent of phy_ref (24M) but
>   keep the same divisor. This way, the video_pll rate will be 1056 - 24
> = 1032M.
> - new pixel-clock will be: 1032 / 8 = 129M
> 
> For a "clock-drop-level = <2>", new pixel-clock will be:
> (1056 - (24 * 2)) / 8 = 1008 / 8 = 126M
> 
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> ---
>  drivers/gpu/drm/bridge/nwl-dsi.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 1228466..ac4aa0a 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -142,6 +142,7 @@ struct nwl_dsi {
>  
>  	struct nwl_dsi_transfer *xfer;
>  	struct list_head valid_modes;
> +	u32 clk_drop_lvl;
>  };
>  
>  static const struct regmap_config nwl_dsi_regmap_config = {
> @@ -842,13 +843,14 @@ static unsigned long nwl_dsi_get_lcm(unsigned long a, unsigned long b)
>  
>  	return ((unsigned long long)a * b) / gcf;
>  }
> -
>  /*
>   * This function tries to adjust the crtc_clock for a DSI device in such a way
>   * that the video pll will be able to satisfy both Display Controller pixel
>   * clock (feeding out DPI interface) and our input phy_ref clock.
> + * Also, the DC pixel clock must be lower than the actual clock in order to
> + * have enough blanking space to send DSI commands, if the device is a panel.
>   */
> -static void nwl_dsi_setup_pll_config(struct mode_config *config)
> +static void nwl_dsi_setup_pll_config(struct mode_config *config, u32 lvl)
>  {
>  	unsigned long pll_rate;
>  	int div;
> @@ -908,7 +910,6 @@ static void nwl_dsi_setup_pll_config(struct mode_config *config)
>  	}
>  }
>  
> -
>  /*
>   * This function will try the required phy speed for current mode
>   * If the phy speed can be achieved, the phy will save the speed
> @@ -1103,7 +1104,7 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
>  
>  	pll_rate = config->pll_rates[config->phy_rate_idx];
>  	if (dsi->pll_clk && !pll_rate)
> -		nwl_dsi_setup_pll_config(config);
> +		nwl_dsi_setup_pll_config(config, dsi->clk_drop_lvl);
>  
>  	return MODE_OK;
>  }
> @@ -1248,6 +1249,7 @@ static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
>  static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
>  {
>  	struct platform_device *pdev = to_platform_device(dsi->dev);
> +	struct device_node *np = dsi->dev->of_node;
>  	struct clk *clk;
>  	void __iomem *base;
>  	int ret;
> @@ -1364,6 +1366,8 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
>  		return PTR_ERR(dsi->rst_dpi);
>  	}
>  
> +	of_property_read_u32(np, "fsl,clock-drop-level", &dsi->clk_drop_lvl);
> +
>  	INIT_LIST_HEAD(&dsi->valid_modes);
>  
>  	return 0;
> -- 
> 2.7.4
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-09-06 10:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28 11:13 [PATCH 0/5] Add new features to nwl-dsi driver Robert Chiras (OSS)
2020-08-28 11:13 ` [PATCH 1/5] drm/bridge: nwl-dsi: Add support for video_pll Robert Chiras (OSS)
2020-09-04 17:04   ` Guido Günther
2020-08-28 11:13 ` [PATCH 2/5] dt-bindings: display/bridge: nwl-dsi: Document video_pll clock Robert Chiras (OSS)
2020-08-28 21:40   ` Rob Herring
2020-08-28 11:13 ` [PATCH 3/5] drm/bridge: nwl-dsi: Add support for clock-drop-level Robert Chiras (OSS)
2020-09-06 10:28   ` Guido Günther [this message]
2020-08-28 11:13 ` [PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl, clock-drop-level property Robert Chiras (OSS)
2020-09-04 17:05   ` [PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level property Guido Günther
2020-09-05 16:07   ` Laurent Pinchart
2020-09-09 20:43   ` Rob Herring
2020-08-28 11:13 ` [PATCH 5/5] drm/bridge: nwl-dsi: add support for DCSS Robert Chiras (OSS)
2020-09-04 17:05   ` Guido Günther
2020-09-04 17:08 ` [PATCH 0/5] Add new features to nwl-dsi driver Guido Günther

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=20200906102820.GA3472@bogon.m.sigxcpu.org \
    --to=agx@sigxcpu.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=megous@megous.com \
    --cc=narmstrong@baylibre.com \
    --cc=robert.chiras@oss.nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    /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