| Message ID | 1505502613-11801-1-git-send-email-nicoleotsuka@gmail.com |
|---|---|
| State | Deferred |
| Headers | show |
| Series | [v2] clk: tegra: Use readl_relaxed_poll_timeout_atomic in tegra210_clock_init | expand |
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
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
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
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
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
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
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
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;