From: Peng Fan <peng.fan@oss.nxp.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
Date: Wed, 22 Apr 2026 22:00:23 +0800 [thread overview]
Message-ID: <aejUd6L1AfbsflxR@shlinux89> (raw)
In-Reply-To: <20260422-huge-kiwi-of-tornado-4fce89@sudeepholla>
Hi Sudeep,
Thanks for giving a look.
On Wed, Apr 22, 2026 at 02:14:56PM +0100, Sudeep Holla wrote:
>On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
>> when setting a clock rate. The previously added dt-bindings header
>> defines three modes:
>>
>> ROUND_DOWN / ROUND_UP / ROUND_AUTO
>>
>> To enable device tree clients to select a rounding mode, extend the
>> SCMI clock provider to support "#clock-cells = <2>", where the second
>> cell encodes the desired rounding mode. The default remains
>> ROUND_DOWN for backwards compatibility with existing device trees.
>>
>
>Where is the binding update documented ? It's not in 1/2.
This was missed in this patchset, I will fix in new version, if this
patchset does not have big design flaw.
>
>Also if it can be static in the device tree, why can't it be
>autonomously handled in the platform firmware ? I think I know the
Linux passes ROUND_DOWN, SCMI firmware uses round down for clk calculation.
>answer for this but I want to make sure it is a valid use-case and
>gets documented here as part of binding updates.
Per info from our video software team.
We have some video modes where the best pixel clock rate is slightly above the
nominal rate, and the default round down rule (CLOCK_ROUND_RULE_CEILING in SM
firmware) can cause the resulting clock rate to be much lower than expected.
disp1pix = 96200000 Hz (desired pixel clock rate)
The MIPI DPHY cannot hit the exact frequency of 288600000 Hz needed for this
pixel clock rate, so the next best DPHY PLL frequency is 289000000 Hz. This
corresponds to a pixel clock frequency of 96333333 Hz, which is slightly higher
than the nominal rate of 96200000 Hz the video mode specifies.
Setting the VIDEOPLL (disp1pix parent) to 289000000 Hz should divide down to
the adjusted disp1pix frequency of 96333333 Hz, but here is what happens in the
SM firmware:
quotient = 289000000 / (96200000 + 1) = 3.004 => 3 (notice that the SM always
receives the nominal clock rate, not the adjusted rate)
If the rounding rule is round down (CLOCK_ROUND_RULE_CEILING),
quotient = quotient + 1. Therefore, quotient becomes 4.
disp1pix = 289000000 / 4 = 72250000, which is nowhere close to the target of
96333333.
However, if we can use ROUND_AUTO the SM firmware would select a quotient of 3
in this case, and disp1pix would match our target: 289000000 / 3 = 96333333.
Thanks,
Peng
>
>--
>Regards,
>Sudeep
next prev parent reply other threads:[~2026-04-22 13:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 6:20 [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy) Peng Fan (OSS)
2026-03-06 6:20 ` [PATCH RFC 1/2] dt-bindings: clock: Add SCMI clock rounding mode declarations Peng Fan (OSS)
2026-03-06 6:20 ` [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode Peng Fan (OSS)
2026-04-22 13:14 ` Sudeep Holla
2026-04-22 14:00 ` Peng Fan [this message]
2026-04-22 18:51 ` Sudeep Holla
2026-04-04 1:53 ` [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy) Peng Fan
2026-04-06 15:38 ` Brian Masney
2026-04-08 13:58 ` Peng Fan
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=aejUd6L1AfbsflxR@shlinux89 \
--to=peng.fan@oss.nxp.com \
--cc=arm-scmi@vger.kernel.org \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@kernel.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