mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frank Oltmanns <frank@oltmanns.dev>
To: Maxime Ripard <maxime@cerno.tech>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Andre Przywara <andre.przywara@arm.com>,
	Roman Beranek <me@crly.cz>
Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
	Frank Oltmanns <frank@oltmanns.dev>
Subject: [PATCH v3 0/8] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate
Date: Sun, 02 Jul 2023 19:55:19 +0200	[thread overview]
Message-ID: <20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev> (raw)

This patchset enables NKM clocks to consider alternative parent rates
and utilize this new feature to adjust the pll-video0 clock on Allwinner
A64 (PATCH 1 and 2).

Furthermore, with this patchset pll-video0 considers rates that are
higher than the requested rate when finding the closest rate. In
consequence, higher rates are also considered by pll-video0's
descandents (PATCH 3 et. seq.).

This allows us to achieve an optimal rate for driving the board's panel.

To provide some context, the clock structure involved in this process is
as follows:
    clock                       clock type
    --------------------------------------
    pll-video0                  ccu_nm
       pll-mipi                 ccu_nkm
          tcon0                 ccu_mux
             tcon-data-clock    sun4i_dclk

The divider between tcon0 and tcon-data-clock is fixed at 4. Therefore,
in order to achieve a rate that closely matches the desired rate of the
panel, pll-mipi needs to operate at a specific rate.

Tests
=====
So far, this has been successfully tested on the A64-based Pinephone
using three different panel rates:

 1. A panel rate that can be matched exactly by pll-video0.
 2. A panel rate that requires pll-video0 to undershoot to get the
    closest rate.
 3. A panel rate that requires pll-video0 to overshoot to get the
    closest rate.

Test records:

Re 1:
-----
Panel requests tcon-data-clock of 103500000 Hz, i.e., pll-mipi needs to
run at 414000000 Hz. This results in the following clock rates:
   clock                            rate
----------------------------------------
    pll-video0                 207000000
       hdmi-phy-clk             51750000
       hdmi                    207000000
       tcon1                   207000000
       pll-mipi                414000000
          tcon0                414000000
             tcon-data-clock   103500000

The results of the find_best calls:
[   12.345862] ccu_nkm_find_best_with_parent_adj: rate=414000000, best_rate=414000000, best_parent_rate=207000000, n=1, k=2, m=1
[   12.346111] ccu_nkm_find_best_with_parent_adj: rate=414000000, best_rate=414000000, best_parent_rate=207000000, n=1, k=2, m=1
[   12.346291] ccu_nkm_find_best_with_parent_adj: rate=414000000, best_rate=414000000, best_parent_rate=207000000, n=1, k=2, m=1
[   12.346471] ccu_nkm_find_best_with_parent_adj: rate=414000000, best_rate=414000000, best_parent_rate=207000000, n=1, k=2, m=1
[   12.346867] ccu_nkm_find_best: rate=414000000, best_rate=414000000, parent_rate=207000000, n=1, k=2, m=1

Re 2:
-----
Panel requests tcon-data-clock of 103650000 Hz, i.e., pll-mipi needs to
run at 414600000 Hz. This results in the following clock rates:
   clock                            rate
----------------------------------------
    pll-video0                 282666666
       hdmi-phy-clk             70666666
       hdmi                    282666666
       tcon1                   282666666
       pll-mipi                414577776
          tcon0                414577776
             tcon-data-clock   103644444

The results of the find_best calls:
[   13.638954] ccu_nkm_find_best_with_parent_adj: rate=414600000, best_rate=414577776, best_parent_rate=282666666, n=11, k=2, m=15
[   13.639212] ccu_nkm_find_best_with_parent_adj: rate=414600000, best_rate=414577776, best_parent_rate=282666666, n=11, k=2, m=15
[   13.639395] ccu_nkm_find_best_with_parent_adj: rate=414577776, best_rate=414577776, best_parent_rate=282666666, n=11, k=2, m=15
[   13.639577] ccu_nkm_find_best_with_parent_adj: rate=414577776, best_rate=414577776, best_parent_rate=282666666, n=11, k=2, m=15
[   13.639913] ccu_nkm_find_best: rate=414577776, best_rate=414577776, parent_rate=282666666, n=11, k=2, m=15

Here, we consistently ask the pll-video0 for a rate that it can't
provide exactly:
 - rate=414600000: We ask the parent for 282681818 (rate * m / (n * k)),
   it returns 282666666. Here the parent undershoots.
 - rate=414577776: We ask the parent for 282666665 (rate * m / (n * k)),
   it returns 282666666. Here the parent overshoots.

So, in both cases it rounds to the nearest rate (first down, then up),
which is the intended behaviour.

Re 3:
-----
Panel requests tcon-data-clock of 112266000 Hz, i.e., pll-mipi needs to
run at 449064000 Hz. This results in the following clock rates:
   clock                            rate
----------------------------------------
    pll-video0                 207272727
       hdmi-phy-clk             51818181
       hdmi                    207272727
       tcon1                   207272727
       pll-mipi                449090908
          tcon0                449090908
             tcon-data-clock   112272727

The results of the find_best calls:
[   13.871022] ccu_nkm_find_best_with_parent_adj: rate=449064000, best_rate=449090908, best_parent_rate=207272727, n=13, k=2, m=12
[   13.871277] ccu_nkm_find_best_with_parent_adj: rate=449064000, best_rate=449090908, best_parent_rate=207272727, n=13, k=2, m=12
[   13.871461] ccu_nkm_find_best_with_parent_adj: rate=449090908, best_rate=449090908, best_parent_rate=207272727, n=13, k=2, m=12
[   13.871646] ccu_nkm_find_best_with_parent_adj: rate=449090908, best_rate=449090908, best_parent_rate=207272727, n=13, k=2, m=12
[   13.872050] ccu_nkm_find_best: rate=449090908, best_rate=449090908, parent_rate=207272727, n=13, k=2, m=12

Here, we consistently ask the pll-video0 for a rate that it can't
provide exactly:
 - rate=449064000: We ask the parent for 207260307 (rate * m / (n * k)),
   it returns 207272727.
 - rate=449090908: We ask the parent for 207272726 (rate * m / (n * k)),
   it returns 207272727.

So, in both cases, it rounds up to the nearest rate, which is the
intended behavior.

Changes in v3:
 - Use dedicated function for finding the best rate in cases where an
   nkm clock supports setting its parent's rate, streamlining it with
   the structure that is used in other sunxi-ng ccus such as ccu_mp
   (PATCH 1).
 - Therefore, remove the now obsolete comments that were introduced in
   v2 (PATCH 1).
 - Remove the dedicated function for calculating the optimal parent rate
   for nkm clocks that was introduced in v2. Instead use a simple
   calculation and require the parent clock to select the closest rate to
   achieve optimal results (PATCH 1).
 - Therefore, add support to set the closest rate for nm clocks (because
   pll-mipi's parent pll-video0 is an nm clock) and all clock types that
   are descendants of a64's pll-video0, i.e., nkm, mux, and div (PATCH 3
   et. seq.).
 - Link to v2: https://lore.kernel.org/all/20230611090143.132257-1-frank@oltmanns.dev/

Changes in V2:
 - Move optimal parent rate calculation to dedicated function
 - Choose a parent rate that does not to overshoot requested rate
 - Add comments to ccu_nkm_find_best
 - Make sure that best_parent_rate stays at original parent rate in the unlikely
   case that all combinations overshoot.

Link to V1:
https://lore.kernel.org/lkml/20230605190745.366882-1-frank@oltmanns.dev/

---
Frank Oltmanns (8):
      clk: sunxi-ng: nkm: consider alternative parent rates when determining rate
      clk: sunxi-ng: a64: allow pll-mipi to set parent's rate
      clk: sunxi-ng: Add feature to find closest rate
      clk: sunxi-ng: nm: Support finding closest rate
      clk: sunxi-ng: nkm: Support finding closest rate
      clk: sunxi-ng: mux: Support finding closest rate
      clk: sunxi-ng: div: Support finding closest rate
      clk: sunxi-ng: a64: select closest rate for pll-video0

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 25 ++++++-----
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   |  3 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  |  6 ++-
 drivers/clk/sunxi-ng/ccu_common.h     |  1 +
 drivers/clk/sunxi-ng/ccu_div.h        | 30 +++++++++++++
 drivers/clk/sunxi-ng/ccu_mux.c        | 36 +++++++++++++---
 drivers/clk/sunxi-ng/ccu_mux.h        | 17 ++++++++
 drivers/clk/sunxi-ng/ccu_nkm.c        | 80 ++++++++++++++++++++++++++++++++---
 drivers/clk/sunxi-ng/ccu_nm.c         | 23 +++++++++-
 drivers/clk/sunxi-ng/ccu_nm.h         |  6 ++-
 10 files changed, 198 insertions(+), 29 deletions(-)
---
base-commit: 6995e2de6891c724bfeb2db33d7b87775f913ad1
change-id: 20230626-pll-mipi_set_rate_parent-3363fc0d6e6f

Best regards,
-- 
Frank Oltmanns <frank@oltmanns.dev>


             reply	other threads:[~2023-07-02 17:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-02 17:55 Frank Oltmanns [this message]
2023-07-02 17:55 ` [PATCH v3 1/8] clk: sunxi-ng: nkm: consider alternative parent rates when determining rate Frank Oltmanns
2023-07-03  6:47   ` Maxime Ripard
2023-07-03  8:02     ` Frank Oltmanns
2023-07-02 17:55 ` [PATCH v3 2/8] clk: sunxi-ng: a64: allow pll-mipi to set parent's rate Frank Oltmanns
2023-07-03  6:47   ` Maxime Ripard
2023-07-02 17:55 ` [PATCH v3 3/8] clk: sunxi-ng: Add feature to find closest rate Frank Oltmanns
2023-07-03  6:48   ` Maxime Ripard
2023-07-02 17:55 ` [PATCH v3 4/8] clk: sunxi-ng: nm: Support finding " Frank Oltmanns
2023-07-03  7:24   ` Maxime Ripard
2023-07-03  8:46     ` Frank Oltmanns
2023-07-02 17:55 ` [PATCH v3 5/8] clk: sunxi-ng: nkm: " Frank Oltmanns
2023-07-02 20:06   ` kernel test robot
2023-07-03  7:17   ` Frank Oltmanns
2023-07-03  7:25     ` Maxime Ripard
2023-07-03  8:59       ` Frank Oltmanns
2023-07-03 11:36         ` Maxime Ripard
2023-07-03  7:33   ` Maxime Ripard
2023-07-02 17:55 ` [PATCH v3 6/8] clk: sunxi-ng: mux: " Frank Oltmanns
2023-07-03  7:38   ` Maxime Ripard
2023-07-03  9:17     ` Frank Oltmanns
2023-07-03 11:37       ` Maxime Ripard
2023-07-02 17:55 ` [PATCH v3 7/8] clk: sunxi-ng: div: " Frank Oltmanns
2023-07-03  7:39   ` Maxime Ripard
2023-07-02 17:55 ` [PATCH v3 8/8] clk: sunxi-ng: a64: select closest rate for pll-video0 Frank Oltmanns
2023-07-03  7:50   ` Maxime Ripard
2023-07-03  9:28     ` Frank Oltmanns
2023-07-03  7:51 ` [PATCH v3 0/8] clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate Maxime Ripard
2023-07-03  9:36   ` Frank Oltmanns

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=20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev \
    --to=frank@oltmanns.dev \
    --cc=andre.przywara@arm.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maxime@cerno.tech \
    --cc=me@crly.cz \
    --cc=mturquette@baylibre.com \
    --cc=samuel@sholland.org \
    --cc=sboyd@kernel.org \
    --cc=wens@csie.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

all inboxes | Powered by JetHome®