On Mon, 19 Feb 2024 at 17:01, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote:
>
> On 19.02.2024 15:54, Andrew Halaney wrote:
> > On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
> >> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> >> introduced an entry to the alpha offsets array, but diving into QCM2290
> >> downstream and some documentation, it turned out that the name Huayra
> >> apparently has been used quite liberally across many chips, even with
> >> noticeably different hardware.
> >>
> >> Introduce another set of offsets and a new configure function for the
> >> Huayra PLL found on QCM2290. This is required e.g. for the consumers
> >> of GPUCC_PLL0 to properly start.
> >>
> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
> >> ---
> >> drivers/clk/qcom/clk-alpha-pll.c | 45 ++++++++++++++++++++++++++++++++++++++++
> >> drivers/clk/qcom/clk-alpha-pll.h | 3 +++
> >> 2 files changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
> >> index 8a412ef47e16..61b5abd13782 100644
> >> --- a/drivers/clk/qcom/clk-alpha-pll.c
> >> +++ b/drivers/clk/qcom/clk-alpha-pll.c
> >> @@ -244,6 +244,19 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
> >> [PLL_OFF_OPMODE] = 0x30,
> >> [PLL_OFF_STATUS] = 0x3c,
> >> },
> >> + [CLK_ALPHA_PLL_TYPE_HUAYRA_2290] = {
> >> + [PLL_OFF_L_VAL] = 0x04,
> >> + [PLL_OFF_ALPHA_VAL] = 0x08,
> >> + [PLL_OFF_USER_CTL] = 0x0c,
> >> + [PLL_OFF_CONFIG_CTL] = 0x10,
> >> + [PLL_OFF_CONFIG_CTL_U] = 0x14,
> >> + [PLL_OFF_CONFIG_CTL_U1] = 0x18,
> >> + [PLL_OFF_TEST_CTL] = 0x1c,
> >> + [PLL_OFF_TEST_CTL_U] = 0x20,
> >> + [PLL_OFF_TEST_CTL_U1] = 0x24,
> >> + [PLL_OFF_OPMODE] = 0x28,
> >> + [PLL_OFF_STATUS] = 0x38,
> >> + },
> >> };
> >> EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> >>
> >> @@ -779,6 +792,38 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> >> return clamp(rate, min_freq, max_freq);
> >> }
> >>
> >> +void clk_huayra_2290_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
> >> + const struct alpha_pll_config *config)
> >> +{
> >> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL(pll), config->config_ctl_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U(pll), config->config_ctl_hi_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_CONFIG_CTL_U1(pll), config->config_ctl_hi1_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL(pll), config->test_ctl_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U(pll), config->test_ctl_hi_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_TEST_CTL_U1(pll), config->test_ctl_hi1_val);
> >> + clk_alpha_pll_write_config(regmap, PLL_L_VAL(pll), config->l);
> >> + clk_alpha_pll_write_config(regmap, PLL_ALPHA_VAL(pll), config->alpha);
> >> + clk_alpha_pll_write_config(regmap, PLL_USER_CTL(pll), config->user_ctl_val);
> >> +
> >> + /* Set PLL_BYPASSNL */
> >> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_BYPASSNL, PLL_BYPASSNL);
> >> +
> >> + /* Wait 5 us between setting BYPASS and deasserting reset */
> >> + mb();
> >> + udelay(5);
> >> +
> >> + /* Take PLL out from reset state */
> >> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_RESET_N, PLL_RESET_N);
> >> +
> >> + /* Wait 50us for PLL_LOCK_DET bit to go high */
> >> + mb();
> >> + usleep_range(50, 55);
> >
> > I *think* you'd want to use a read to ensure your write goes through
> > prior to your sleep... from memory-barriers.txt:
> >
> > 5. A readX() by a CPU thread from the peripheral will complete before
> > any subsequent delay() loop can begin execution on the same thread.
> > This ensures that two MMIO register writes by the CPU to a peripheral
> > will arrive at least 1us apart if the first write is immediately read
> > back with readX() and udelay(1) is called prior to the second
> > writeX():
> >
> > writel(42, DEVICE_REGISTER_0); // Arrives at the device...
> > readl(DEVICE_REGISTER_0);
> > udelay(1);
> > writel(42, DEVICE_REGISTER_1); // ...at least 1us before this.
> >
> > also https://youtu.be/i6DayghhA8Q?si=7lp0be35q1HRmlnV&t=1677
> > for more references on this topic.
>
> I mentioned this feels very iffy in the cover letter, but it's a combination
> of two things:
>
> 1. i followed what qualcomm downstream code did
>
> 2. qualcomm downstream code is not known for being always correct
>
>
>
> I suppose a readback would be the correct solution, but then it should be
> done for all similar calls in this driver.
>
> Although this code has shipped in literally hundreds of millions of devices
> and it didn't explode badly :P (i'm not defending it, though)
I think the idea behind the code looks pretty close to
clk_alpha_pll_stromer_plus_set_rate(), which uses neither wmb() nor
read-back.
--
With best wishes
Dmitry
