Linux clock framework development
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Quentin Schulz <quentin.schulz@cherry.de>,
	Alexey Charkov <alchark@flipper.net>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Brian Masney <bmasney@redhat.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	Wyon Bi <bivvy.bi@rock-chips.com>,
	Finley Xiao <finley.xiao@rock-chips.com>,
	Elaine Zhang <zhangqing@rock-chips.com>,
	Detlev Casanova <detlev.casanova@collabora.com>,
	Sugar Zhang <sugar.zhang@rock-chips.com>,
	YouMin Chen <cym@rock-chips.com>,
	Dragan Simic <dsimic@manjaro.org>, Liang Chen <cl@rock-chips.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement
Date: Wed, 22 Jul 2026 18:23:10 +0200	[thread overview]
Message-ID: <3482742.0oRPG1VZx4@diego> (raw)
In-Reply-To: <CAKTNdwE=s6XG==4HvbaEV86DATWO6egVxLgNE4LpjFaXNQP7_g@mail.gmail.com>

Am Mittwoch, 22. Juli 2026, 13:00:47 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> Hi Quentin,
> 
> On Wed, Jul 22, 2026 at 2:35 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >
> > Hi Alexey,
> >
> > On 7/21/26 9:17 PM, Alexey Charkov wrote:
> > > When the PLL rates table was first committed for RK3588 (and later reused
> > > for RK3576), the fractional PLL coefficient was defined as an unsigned
> > > value, while the TRM clearly states that it is a two's complement 16-bit
> > > value.
> > >
> > > Rockchip's downstream kernel later revised the fractional PLL code [1] to
> > > account for the two's complement nature of the coefficient, but that
> > > change wasn't upstreamed.
> > >
> > > Change the PLL table definition to use two's complement for the
> > > fractional coefficient and update its users accordingly.
> > >
> > > Note that a negative fractional coefficient is meant to be subtracted from
> > > the next larger integer multiplier, so the _m values in the table are
> > > also adjusted accordingly for the two negative-k entries.
> > >
> > > While at it, fix the denominator of the fractional PLL calculation to use
> > > 65536 instead of 65535, as per the TRM (RK3576 TRM Part 1 V1.2, Section
> > > 2.13.1.4 Setting Guide on P, M, S, and K):
> > >
> > > Fout = ((m + k/65536) * Fin) / (p * 2^s)
> > >
> > > Link: https://github.com/flipperdevices/rockchip-linux/commit/7a72bc05dcc3a51e85ae531749e6270bf9b9212d [1]
> > > Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588")
> > > Fixes: cc40f5baa91b ("clk: rockchip: Add clock controller for the RK3576")
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > > ---
> > > Not adding Cc stable, because while this fixes a real bug it's not a
> > > regression, as the issue was introduced in the same commit that added the
> > > RK3576/RK3588 support.
> > >
> >
> > I don't think this is a valid reason :)
> 
> I believe Linus frowns upon changes like "it never worked, but we've
> fixed it now" being submitted as fixes. It's been broken for years,
> and since nobody complained yet, going via the normal development path
> (i.e. -next) seems perfectly fine to me.

Personally, I also don't think this _needs_ a stable tag.
The whole if it ain't broke thing ....

If stable-maintainers do think it valuable on their own (without stable tag)
then by all means, but changing how the PLL rate stuff works has the
_ability_ to introduce other behaviour _somewhere_.


> > In any case, this patch is doing too many things at once. I see the
> > following things that would warrant individual patches:
> >
> > 1) fix the wrong denominator, stable candidate IMO,
> 
> I could split this one out, but since it's a trivial one-liner, I'd
> like to hear what Heiko prefers.

yes please.
- Subject: Foo and Bar
- Commit message with "while at it"
are clear indicators that the change wants to get split ;-)

So please split out that "while at it" part. The rest can stay
together though.


Thanks
Heiko



      parent reply	other threads:[~2026-07-22 16:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 19:17 [PATCH] clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement Alexey Charkov
2026-07-22 10:35 ` Quentin Schulz
2026-07-22 11:00   ` Alexey Charkov
2026-07-22 12:59     ` Quentin Schulz
2026-07-22 13:42       ` Alexey Charkov
2026-07-22 13:43       ` Sebastian Reichel
2026-07-22 13:54         ` Alexey Charkov
2026-07-22 16:15           ` Sebastian Reichel
2026-07-22 16:23     ` Heiko Stübner [this message]

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=3482742.0oRPG1VZx4@diego \
    --to=heiko@sntech.de \
    --cc=alchark@flipper.net \
    --cc=bivvy.bi@rock-chips.com \
    --cc=bmasney@redhat.com \
    --cc=cl@rock-chips.com \
    --cc=cym@rock-chips.com \
    --cc=detlev.casanova@collabora.com \
    --cc=dsimic@manjaro.org \
    --cc=finley.xiao@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=quentin.schulz@cherry.de \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=sugar.zhang@rock-chips.com \
    --cc=zhangqing@rock-chips.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