public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tero Kristo <kristo@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Tony Lindgren <tony@atomide.com>
Cc: linux-clk <linux-clk@vger.kernel.org>,
	"open list:TI ETHERNET SWITCH DRIVER (CPSW)" 
	<linux-omap@vger.kernel.org>
Subject: Re: DRA7 clock question
Date: Fri, 29 Oct 2021 08:34:20 +0300	[thread overview]
Message-ID: <bb6a0a28-8419-f131-caf6-aed1b5261c6b@kernel.org> (raw)
In-Reply-To: <d0c128b2-8de1-85b6-52d0-21f7346a98bd@ti.com>

On 28/10/2021 19:13, Grygorii Strashko wrote:
> 
> 
> On 28/10/2021 18:16, Geert Uytterhoeven wrote:
>> Hi Tero, Tony,
>>
>> I accidentally stumbled across the following code in 
>> drivers/clk/ti/apll.c:
>>
>>      static int dra7_apll_enable(struct clk_hw *hw)
>>      {
>>              struct clk_hw_omap *clk = to_clk_hw_omap(hw);
>>              int r = 0, i = 0;
>>              struct dpll_data *ad;
>>              const char *clk_name;
>>              u8 state = 1;
>>              u32 v;
>>
>>              ad = clk->dpll_data;
>>              if (!ad)
>>                      return -EINVAL;
>>
>>              clk_name = clk_hw_get_name(&clk->hw);
>>
>>              state <<= __ffs(ad->idlest_mask);
>>
>> state is shifted to its bit position...
>>
>>              /* Check is already locked */
>>              v = ti_clk_ll_ops->clk_readl(&ad->idlest_reg);
>>
>>              if ((v & ad->idlest_mask) == state)
>>
>> ... and checked.
>>
>>                      return r;
>>
>>              v = ti_clk_ll_ops->clk_readl(&ad->control_reg);
>>              v &= ~ad->enable_mask;
>>              v |= APLL_FORCE_LOCK << __ffs(ad->enable_mask);
>>              ti_clk_ll_ops->clk_writel(v, &ad->control_reg);
>>
>>              state <<= __ffs(ad->idlest_mask);
>>
>> state is shifted again? ...
> 
> this is probably copy-paste err

Yeah, this looks like something for someone to fix. The bug has been 
masked by the fact that the autoidle_mask for dra7 is always 0x1, 
meaning the shift value becomes zero.

> 
>>
>>              while (1) {
>>                      v = ti_clk_ll_ops->clk_readl(&ad->idlest_reg);
>>                      if ((v & ad->idlest_mask) == state)
>>
>> ... and checked again?
> 
> this is correct wait for locking
> 
>>
>>                              break;
>>                      if (i > MAX_APLL_WAIT_TRIES)
>>                              break;
>>                      i++;
>>                      udelay(1);
>>              }
>>
>>              if (i == MAX_APLL_WAIT_TRIES) {
>>                      pr_warn("clock: %s failed transition to '%s'\n",
>>                              clk_name, (state) ? "locked" : "bypassed");
>>                      r = -EBUSY;
>>              } else
>>                      pr_debug("clock: %s transition to '%s' in %d 
>> loops\n",
>>                               clk_name, (state) ? "locked" : 
>> "bypassed", i);
>>
>>              return r;
>>      }
>>
>>      static void dra7_apll_disable(struct clk_hw *hw)
>>      {
>>              struct clk_hw_omap *clk = to_clk_hw_omap(hw);
>>              struct dpll_data *ad;
>>              u8 state = 1;
>>              u32 v;
>>
>>              ad = clk->dpll_data;
>>
>>              state <<= __ffs(ad->idlest_mask);
>>
>> state is shifted to its bit position, but it is never used below?
>> Perhaps one of the check blocks above should be moved here?
> 
> this is probably copy-paste issue also

Yes, this can be dropped. When a clock is going to autoidle, we don't 
really care when it does so and thus are not polling the status.

-Tero

> 
>>
>> I checked git history and the original patch submissions, and even
>> the oldest submission I could find had the same logic.
> 
> I think, old logic (basic) can be found at
> 
> arch/arm/mach-omap2/dpll3xxx.c
> 
>>
>>              v = ti_clk_ll_ops->clk_readl(&ad->control_reg);
>>              v &= ~ad->enable_mask;
>>              v |= APLL_AUTO_IDLE << __ffs(ad->enable_mask);
>>              ti_clk_ll_ops->clk_writel(v, &ad->control_reg);
>>      }
>>
>> Thanks!
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
> 
> 


  reply	other threads:[~2021-10-29  5:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 15:16 DRA7 clock question Geert Uytterhoeven
2021-10-28 16:13 ` Grygorii Strashko
2021-10-29  5:34   ` Tero Kristo [this message]
2021-10-29  6:45     ` Tony Lindgren

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=bb6a0a28-8419-f131-caf6-aed1b5261c6b@kernel.org \
    --to=kristo@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.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