[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXv+5FPUchS36ObBZQ73zh7cR5wyfk6bpNO4u5h3AH1GzSP0Q@mail.gmail.com>
Date: Mon, 24 Oct 2022 14:58:29 -0700
From: Chen-Yu Tsai <wenst@...omium.org>
To: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
Cc: sboyd@...nel.org, mturquette@...libre.com, matthias.bgg@...il.com,
miles.chen@...iatek.com, nfraprado@...labora.com,
rex-bc.chen@...iatek.com, chun-jie.chen@...iatek.com,
jose.exposito89@...il.com, yangyingliang@...wei.com,
msp@...libre.com, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/10] clk: mediatek: mt8186-topckgen: Drop flags for
main/univpll fixed factors
On Mon, Oct 24, 2022 at 3:23 AM AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com> wrote:
>
> The mainpll and univpll clocks are used as clock sources for multiple
> peripherals of different kind, some of which are critical (like AXIs);
> a rate change on any of these two will produce a rate change on many
> devices and that's likely to produce system instability if not done
> correctly: this is the reason why we have "fixed factor" clocks, used
> by MUX clocks to provide different rates based on PLL output dividers.
>
> Though, there's one fundamental issue that must be resolved somehow:
>
> When performing GPU DVFS, we get a rate request that will try to change
> the frequency of MAINPLL due to the CLK_TOP_MFG mux having clk26m,
> mfgpll (the GPU dedicated PLL), mainpll_d3, mainpll_d5 (fixed factor
> dividers) as possible parents.
>
> In order to solve that, there are two ways:
> 1. Add new "fake" mainpll_d3_fixed, mainpll_d5_fixed clocks, clones
> of mainpll_d3, mainpll_d5 clocks, for the only purpose of not
> declaring CLK_SET_RATE_PARENT; or
> 2. Simply drop said flag from the original dividers.
>
> After some careful validation, I cannot see anything calling a rate
> change request during runtime for MAINPLL, nor for UNIVPLL (which would,
> again, mean that we're reclocking lots of peripherals at once!), so it
> is safe *and sane* to simply remove the CLK_SET_RATE_PARENT flag to all
> of the main/univpll fixed factor divider clocks.
>
> Besides, if for any (doubtful) reason main/univpll rate change will be
> required in the future, it's still possible to call that on the PLL main
> clocks, so we're still covered anyway.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
AFAIK this matches what we do for some other SoC families, so
Reviewed-by: Chen-Yu Tsai <wenst@...omium.org>
Powered by blists - more mailing lists