[v2] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init

Message ID 1505502613-11801-1-git-send-email-nicoleotsuka@gmail.com
State New
Headers show
Series
  • [v2] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init
Related show

Commit Message

Nicolin Chen Sept. 15, 2017, 7:10 p.m.
Below is the call trace of tegra210_init_pllu() function:
  start_kernel()
  -> time_init()
  --> of_clk_init()
  ---> tegra210_clock_init()
  ----> tegra210_pll_init()
  -----> tegra210_init_pllu()

Because the preemption is disabled in the start_kernel before calling
time_init, tegra210_init_pllu is actually in an atomic context while
it includes a readl_relaxed_poll_timeout that might sleep.

So this patch just changes this readl_relaxed_poll_timeout() to its
atomic version.

Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
---
Changelog
v2:
 * Corrected a typo in the commit log
 * Added Peter's Acked-by.

 drivers/clk/tegra/clk-tegra210.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Nicolin Chen Oct. 19, 2017, 9:29 a.m. | #1
On Fri, Sep 15, 2017 at 12:10:13PM -0700, Nicolin Chen wrote:
> Below is the call trace of tegra210_init_pllu() function:
>   start_kernel()
>   -> time_init()
>   --> of_clk_init()
>   ---> tegra210_clock_init()
>   ----> tegra210_pll_init()
>   -----> tegra210_init_pllu()
> 
> Because the preemption is disabled in the start_kernel before calling
> time_init, tegra210_init_pllu is actually in an atomic context while
> it includes a readl_relaxed_poll_timeout that might sleep.
> 
> So this patch just changes this readl_relaxed_poll_timeout() to its
> atomic version.
> 
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>

Thierry, can you also take a look at this one? I sent a month ago. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding Oct. 19, 2017, 9:44 a.m. | #2
On Thu, Oct 19, 2017 at 02:29:20AM -0700, Nicolin Chen wrote:
> On Fri, Sep 15, 2017 at 12:10:13PM -0700, Nicolin Chen wrote:
> > Below is the call trace of tegra210_init_pllu() function:
> >   start_kernel()
> >   -> time_init()
> >   --> of_clk_init()
> >   ---> tegra210_clock_init()
> >   ----> tegra210_pll_init()
> >   -----> tegra210_init_pllu()
> > 
> > Because the preemption is disabled in the start_kernel before calling
> > time_init, tegra210_init_pllu is actually in an atomic context while
> > it includes a readl_relaxed_poll_timeout that might sleep.
> > 
> > So this patch just changes this readl_relaxed_poll_timeout() to its
> > atomic version.
> > 
> > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> > Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
> 
> Thierry, can you also take a look at this one? I sent a month ago. Thanks.

I'm wondering why we're not seeing a splat for this. Usually the kernel
will warn if you sleep during atomic context. Does this mean we're just
not hitting that case? readx_poll_timeout() has a might_sleep_if(), and
therefore it should always cause the splat.

Any ideas why this has gone unnoticed for all this time?

Thierry
Nicolin Chen Oct. 19, 2017, 6:42 p.m. | #3
On Thu, Oct 19, 2017 at 11:44:22AM +0200, Thierry Reding wrote:
> > > Below is the call trace of tegra210_init_pllu() function:
> > >   start_kernel()
> > >   -> time_init()
> > >   --> of_clk_init()
> > >   ---> tegra210_clock_init()
> > >   ----> tegra210_pll_init()
> > >   -----> tegra210_init_pllu()

> I'm wondering why we're not seeing a splat for this. Usually the kernel
> will warn if you sleep during atomic context. Does this mean we're just
> not hitting that case?

Yes.

> readx_poll_timeout() has a might_sleep_if(), and
> therefore it should always cause the splat.

That's true as long as CONFIG_DEBUG_ATOMIC_SLEEP is enabled locally.

> Any ideas why this has gone unnoticed for all this time?

We can see in the tegra210_init_pllu() function that it'll not call
tegra210_enable_pllu() if pllu is already enabled (by bootloader).

You can verify it by adding an irqs_disabled() in this routine. The
function is called during system-boot and suspend-n-resume. And both
cases should be irqs_disabled().

Thanks
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nicolin Chen Oct. 20, 2017, 12:19 a.m. | #4
On Thu, Oct 19, 2017 at 11:42:24AM -0700, Nicolin Chen wrote:
> On Thu, Oct 19, 2017 at 11:44:22AM +0200, Thierry Reding wrote:
> > > > Below is the call trace of tegra210_init_pllu() function:
> > > >   start_kernel()
> > > >   -> time_init()
> > > >   --> of_clk_init()
> > > >   ---> tegra210_clock_init()
> > > >   ----> tegra210_pll_init()
> > > >   -----> tegra210_init_pllu()
> 
> > I'm wondering why we're not seeing a splat for this. Usually the kernel
> > will warn if you sleep during atomic context. Does this mean we're just
> > not hitting that case?
> 
> Yes.
> 
> > readx_poll_timeout() has a might_sleep_if(), and
> > therefore it should always cause the splat.
> 
> That's true as long as CONFIG_DEBUG_ATOMIC_SLEEP is enabled locally.
> 
> > Any ideas why this has gone unnoticed for all this time?
> 
> We can see in the tegra210_init_pllu() function that it'll not call
> tegra210_enable_pllu() if pllu is already enabled (by bootloader).
> 
> You can verify it by adding an irqs_disabled() in this routine. The
> function is called during system-boot and suspend-n-resume. And both

A correction: using mainline kernel, only system-boot as the commit log
describes.

> cases should be irqs_disabled().
> 
> Thanks
> Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jon Hunter Oct. 20, 2017, 10:20 a.m. | #5
On 19/10/17 19:42, Nicolin Chen wrote:
> On Thu, Oct 19, 2017 at 11:44:22AM +0200, Thierry Reding wrote:
>>>> Below is the call trace of tegra210_init_pllu() function:
>>>>   start_kernel()
>>>>   -> time_init()
>>>>   --> of_clk_init()
>>>>   ---> tegra210_clock_init()
>>>>   ----> tegra210_pll_init()
>>>>   -----> tegra210_init_pllu()
> 
>> I'm wondering why we're not seeing a splat for this. Usually the kernel
>> will warn if you sleep during atomic context. Does this mean we're just
>> not hitting that case?
> 
> Yes.
> 
>> readx_poll_timeout() has a might_sleep_if(), and
>> therefore it should always cause the splat.
> 
> That's true as long as CONFIG_DEBUG_ATOMIC_SLEEP is enabled locally.
> 
>> Any ideas why this has gone unnoticed for all this time?
> 
> We can see in the tegra210_init_pllu() function that it'll not call
> tegra210_enable_pllu() if pllu is already enabled (by bootloader).

I was thinking that same and so I clobbered the PLLU enable bit with
u-boot, however, then the kernel appears to hang on boot when enabling
the PLL. So although this is probably a separate issue, I am curious if
you have booted the mainline with the PLLU disabled?

Cheers
Jon
Thierry Reding Oct. 20, 2017, 11:38 a.m. | #6
On Fri, Sep 15, 2017 at 12:10:13PM -0700, Nicolin Chen wrote:
> Below is the call trace of tegra210_init_pllu() function:
>   start_kernel()
>   -> time_init()
>   --> of_clk_init()
>   ---> tegra210_clock_init()
>   ----> tegra210_pll_init()
>   -----> tegra210_init_pllu()
> 
> Because the preemption is disabled in the start_kernel before calling
> time_init, tegra210_init_pllu is actually in an atomic context while
> it includes a readl_relaxed_poll_timeout that might sleep.
> 
> So this patch just changes this readl_relaxed_poll_timeout() to its
> atomic version.
> 
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
> ---
> Changelog
> v2:
>  * Corrected a typo in the commit log
>  * Added Peter's Acked-by.
> 
>  drivers/clk/tegra/clk-tegra210.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

Thierry
Nicolin Chen Oct. 20, 2017, 6:24 p.m. | #7
On Fri, Oct 20, 2017 at 11:20:24AM +0100, Jon Hunter wrote:
> 
> On 19/10/17 19:42, Nicolin Chen wrote:
> > On Thu, Oct 19, 2017 at 11:44:22AM +0200, Thierry Reding wrote:
> >>>> Below is the call trace of tegra210_init_pllu() function:
> >>>>   start_kernel()
> >>>>   -> time_init()
> >>>>   --> of_clk_init()
> >>>>   ---> tegra210_clock_init()
> >>>>   ----> tegra210_pll_init()
> >>>>   -----> tegra210_init_pllu()
> > 
> >> I'm wondering why we're not seeing a splat for this. Usually the kernel
> >> will warn if you sleep during atomic context. Does this mean we're just
> >> not hitting that case?
> > 
> > Yes.
> > 
> >> readx_poll_timeout() has a might_sleep_if(), and
> >> therefore it should always cause the splat.
> > 
> > That's true as long as CONFIG_DEBUG_ATOMIC_SLEEP is enabled locally.
> > 
> >> Any ideas why this has gone unnoticed for all this time?
> > 
> > We can see in the tegra210_init_pllu() function that it'll not call
> > tegra210_enable_pllu() if pllu is already enabled (by bootloader).
> 
> I was thinking that same and so I clobbered the PLLU enable bit with
> u-boot, however, then the kernel appears to hang on boot when enabling
> the PLL. So although this is probably a separate issue, I am curious if
> you have booted the mainline with the PLLU disabled?

I am not sure if clearing the enable bit only would work. But the test
below should be able to verify the situation -- setting the PLLU_BASE
register to its reset value.

diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index ea695c4..2279373 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2602,6 +2602,7 @@ static int tegra210_init_pllu(void)
 	u32 reg;
 	int err;
 
+	writel_relaxed(0x1011902, clk_base + PLLU_BASE);
	tegra210_pllu_set_defaults(&pll_u_vco_params);
	/* skip initialization when pllu is in hw controlled mode */
	reg = readl_relaxed(clk_base + PLLU_BASE);
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index 0b9789a..ea695c4 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2587,8 +2587,8 @@  static int tegra210_enable_pllu(void)
 	reg |= PLL_ENABLE;
 	writel(reg, clk_base + PLLU_BASE);
 
-	readl_relaxed_poll_timeout(clk_base + PLLU_BASE, reg,
-				   reg & PLL_BASE_LOCK, 2, 1000);
+	readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
+					  reg & PLL_BASE_LOCK, 2, 1000);
 	if (!(reg & PLL_BASE_LOCK)) {
 		pr_err("Timed out waiting for PLL_U to lock\n");
 		return -ETIMEDOUT;