Message-ID: <CA+V-a8vghwkHKWoqU8NQ3O9ZdHxB+cEvMv7Z9LQOMsZcx9vjPA@mail.gmail.com>
Date: Thu, 11 Sep 2025 09:14:56 +0100
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	linux-clk@...r.kernel.org, Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Tommaso Merciai <tommaso.merciai.xr@...renesas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Michael Turquette <mturquette@...libre.com>, 
	Stephen Boyd <sboyd@...nel.org>, Biju Das <biju.das.jz@...renesas.com>, 
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH v8 2/6] clk: renesas: rzv2h-cpg: Add support for DSI clocks

Hi Tomi,

On Wed, Sep 10, 2025 at 1:30 PM Tomi Valkeinen
<tomi.valkeinen+renesas@...asonboard.com> wrote:
>
> Hi,
>
> On 03/09/2025 19:17, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Add support for PLLDSI and PLLDSI divider clocks.
> >
> > Introduce the `renesas-rzv2h-cpg-pll.h` header to centralize and share
> > PLLDSI related data structures, limits, and algorithms between the
> > RZ/V2H(P) CPG and DSI drivers.
> >
> > The DSI PLL is functionally similar to the CPG's PLLDSI, but has slightly
> > different parameter limits and omits the programmable divider present in
> > CPG. To ensure precise frequency calculations, especially for milliHz-level
> > accuracy needed by the DSI driver, the shared algorithm allows both drivers
> > to compute PLL parameters consistently using the same logic and input
> > clock.
>
> Can you elaborate a bit more why a new clock APIs are needed for the DSI
> PLL? This is the first time I have heard a DSI TX (well, any IP) require
> more precision than Hz. Is that really the case? Are there other reasons?
>
Im pasting the same reply from Fab
(https://lore.kernel.org/all/TYCPR01MB12093A7D99392BC3D6B5E5864C2BC2@TYCPR01MB12093.jpnprd01.prod.outlook.com/#t)
for the similar concern.

The PLL found inside the DSI IP is very similar to the PLLDSI found in
the CPG IP block, although the limits for some of the parameters are
different. Also, the PLLDSI is followed by a programmable divider,
whereas there is no such thing in the DSI PLL IP.

The limits for the PLL found within the DSI IP are:
1 <= PLL_P <= 4
64 <= PLL_M <= 1023
0 <= PLL_S <= 5
−32768 <= PLL_K <= 32767

The limits for PLLDSI (found in CPG) are:
1 <= PLL_P <= 4
64 <= PLL_M <= 533
0 <= PLL_S <= 6
−32768 <= PLL_K <= 32767
The limits for the PLLDSI related divider are:
CSDIV = 1/(2 + 2 * n), with n=0,...,15

Header file `renesas-rzv2h-cpg-pll.h` is added so that both the CPG
and DSI drivers can reuse exactly the same data structures and
algorithm, although they'll drive  rzv2h_get_pll*pars() with different
limits.

While the CPG driver only needs visibility of the limits for the
PLLDSI, the DSI driver is going to need visibility of the limits for
both PLLDSI and for the PLL inside the DSI IP.

The DSI driver requires a resolution higher than Hz (which is what the
clock subsystem currently does not support), namely: mHz. This is
vital to allow the DSI driver to keep the error between the calculated
value of HSFREQ and the generated value of HSFREQ below a certain
threshold. The difficulty in achieving a small error is down to the
accuracy of the VCLK representation.
Since the clock subsystem only allows for Hz, a 1/2 Hz error on the
representation of VCLK (down to the selection of frequencies that
cannot be precisely achieved and related rounding errors) may lead to
a very big error in the calculation of HSFREQ, which uses the below
formula:
HSFREQ = (VCLK * bpp) / num_lanes
In the worst case scenario (1 lane and 24 bpp), a 1/2 Hz error on the
representation of VCLK will lead to an error of 12Hz(!) on the
calculation of HSFREQ, leading to a non working video output.

By granting the DSI driver access to the PLL calculations and PLLDSI
(CPG) limits, the DSI driver can work out the best solution for VCLK
independently from the CPG driver, and it can set VCLK accordingly
(knowing that the CPG driver will use exactly the same parameters
determined by the DSI driver, as it will be using the same input
frequency and the same algorithm for the calculations).

For convenience, macro RZV2H_CPG_PLL_DSI_LIMITS() is added to avoid
replicating the declaration of the PLLDSI limits and therefore it can
be used in both the CPG driver and in the DSI driver.

Make use of the data structures and algorithm defined in header file
`renesas-rzv2h-cpg-pll.h` to add PLLDSI support, including its
divider.

Since we need to make sure that the DSI driver knows exactly which
frequency the PLLDSI + divider combo is going to generate, the CPG
driver is instructed to calculate the parameters for the PLLDSI +
divider combo (by calling into rzv2h_get_pll_dtable_pars()) only from
rzv2h_cpg_plldsi_div_determine_rate(). rzv2h_cpg_plldsi_div_set_rate()
will simply reuse the pre-calculated parameter values."


> If such precision is really needed, does it then indicate that it could
> be needed on other IPs too? Thus, we need improvements to the common clk
> API.
>
As of now, this requirement is specific to the DSI IP on the RZ/V2H(P)
SoC. For other IPs we haven’t seen a need yet. Once similar cases
arise in the future, we can certainly revisit the clock subsystem and
look into extending the common clk API to support this more generally.

Cheers,
Prabhakar

Powered by blists - more mailing lists