[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <hrykjklurrj3gqsauwtdiptyqf7uuiu5zuk6dtevchukrsrmty@tqgwqhtgqkbe>
Date: Tue, 7 Jan 2025 16:59:34 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>, linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] clk: qcom: clk-alpha-pll: Add Pongo PLL
On Tue, Jan 07, 2025 at 02:36:52PM +0100, Krzysztof Kozlowski wrote:
> On 07/01/2025 13:36, Dmitry Baryshkov wrote:
> > On Mon, Jan 06, 2025 at 02:44:30PM +0100, Krzysztof Kozlowski wrote:
> >> Add support for Pongo type of PLL clocks, used in Qualcomm SM8750 SoC.
> >> Notable difference comparing to other PLLs is the need for calibration
> >> for internally generated clock followed by wait_for_pll(). This is done
> >> in configure call and at this time clocks are not yet registered, thus
> >> wait_for_pll() cannot use clk_hw_get_name.
> >
> > Is this still correct?
>
> No, it is not, I forgot to drop it after reworking code.
>
> Patches were merged, though.
>
>
> >
> >> Locking during this
> >> calibration requires much more time, thus increase the timeout in
> >> wait_for_pll().
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> >>
> >> ---
> >>
> >> v2:
> >> - EXPORT_SYMBOL_GPL
> >> - Move the PLL calibration and wait_for_pll_enable_lock() call to
> >> prepare callback.
> >> ---
> >> drivers/clk/qcom/clk-alpha-pll.c | 165 ++++++++++++++++++++++++++++++++++++++-
> >> drivers/clk/qcom/clk-alpha-pll.h | 6 ++
> >> 2 files changed, 170 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> >> index 00d3659ea2124e26dd50c1b4e88ba71c1411442e..df609f7e394de2dc73e60df01b1ad71714c0719d 100644
> >> --- a/drivers/clk/qcom/clk-alpha-pll.c
> >> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> >> @@ -58,6 +58,7 @@
> >> #define PLL_TEST_CTL_U(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U])
> >> #define PLL_TEST_CTL_U1(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U1])
> >> #define PLL_TEST_CTL_U2(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U2])
> >> +#define PLL_TEST_CTL_U3(p) ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U3])
> >> #define PLL_STATUS(p) ((p)->offset + (p)->regs[PLL_OFF_STATUS])
> >> #define PLL_OPMODE(p) ((p)->offset + (p)->regs[PLL_OFF_OPMODE])
> >> #define PLL_FRAC(p) ((p)->offset + (p)->regs[PLL_OFF_FRAC])
> >> @@ -197,6 +198,23 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> >> [PLL_OFF_TEST_CTL_U1] = 0x34,
> >> [PLL_OFF_TEST_CTL_U2] = 0x38,
> >> },
> >> + [CLK_ALPHA_PLL_TYPE_PONGO_ELU] = {
> >> + [PLL_OFF_OPMODE] = 0x04,
> >> + [PLL_OFF_STATE] = 0x08,
> >> + [PLL_OFF_STATUS] = 0x0c,
> >> + [PLL_OFF_L_VAL] = 0x10,
> >> + [PLL_OFF_USER_CTL] = 0x14,
> >> + [PLL_OFF_USER_CTL_U] = 0x18,
> >> + [PLL_OFF_CONFIG_CTL] = 0x1c,
> >> + [PLL_OFF_CONFIG_CTL_U] = 0x20,
> >> + [PLL_OFF_CONFIG_CTL_U1] = 0x24,
> >> + [PLL_OFF_CONFIG_CTL_U2] = 0x28,
> >> + [PLL_OFF_TEST_CTL] = 0x2c,
> >> + [PLL_OFF_TEST_CTL_U] = 0x30,
> >> + [PLL_OFF_TEST_CTL_U1] = 0x34,
> >> + [PLL_OFF_TEST_CTL_U2] = 0x38,
> >> + [PLL_OFF_TEST_CTL_U3] = 0x3c,
> >> + },
> >> [CLK_ALPHA_PLL_TYPE_TAYCAN_ELU] = {
> >> [PLL_OFF_OPMODE] = 0x04,
> >> [PLL_OFF_STATE] = 0x08,
> >> @@ -337,6 +355,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> >> #define LUCID_EVO_PLL_CAL_L_VAL_SHIFT 16
> >> #define LUCID_OLE_PLL_RINGOSC_CAL_L_VAL_SHIFT 24
> >>
> >> +/* PONGO ELU PLL specific setting and offsets */
> >> +#define PONGO_PLL_OUT_MASK GENMASK(1, 0)
> >> +#define PONGO_PLL_L_VAL_MASK GENMASK(11, 0)
> >
> > Does it really support such a high L value, or are there any additional
> > flags / data entries? PLL2 uses 0x493, which should end up with 22 GHz
> > clock, if my calculations are correct.
>
> That's the bitfield also in datasheet (except downstream driver). Not
> exactly answer to "does it really support", but not sure what else we
> can do here.
What is the PLL2 frequency if you program config->l as it is now
(0x493)?
--
With best wishes
Dmitry
Powered by blists - more mailing lists