From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754952AbcEENR1 (ORCPT ); Thu, 5 May 2016 09:17:27 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:11187 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbcEENR0 (ORCPT ); Thu, 5 May 2016 09:17:26 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Thu, 05 May 2016 06:16:15 -0700 Subject: Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic" To: Dmitry Osipenko , Stephen Warren , Thierry Reding , "Alexandre Courbot" , Peter De Schrijver , Prashant Gaikwad References: <1460900051-3065-1-git-send-email-digetx@gmail.com> CC: , , From: Jon Hunter X-Nvconfidentiality: public Message-ID: <572B47DE.1090804@nvidia.com> Date: Thu, 5 May 2016 14:17:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1460900051-3065-1-git-send-email-digetx@gmail.com> X-Originating-IP: [10.21.132.133] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/04/16 14:34, Dmitry Osipenko wrote: > clk_get_rate() takes a mutex, hence cannot be used while IRQ's been > disabled. Replace it with a locked version. > > [ 3.430853] [] (dump_stack) from [] (__schedule_bug+0x50/0x64) > [ 3.431079] [] (__schedule_bug) from [] (__schedule+0x5c8/0x688) > [ 3.431453] [] (__schedule) from [] (schedule_preempt_disabled+0x24/0x34) > [ 3.431835] [] (schedule_preempt_disabled) from [] (__mutex_lock_slowpath+0xbc/0x170) > [ 3.432204] [] (__mutex_lock_slowpath) from [] (mutex_lock+0x4c/0x50) > [ 3.432427] [] (mutex_lock) from [] (clk_prepare_lock+0x88/0xfc) > [ 3.432800] [] (clk_prepare_lock) from [] (clk_get_rate+0xc/0x60) > [ 3.433177] [] (clk_get_rate) from [] (tegra_pmc_enter_suspend_mode+0x188/0x20c) > [ 3.433580] [] (tegra_pmc_enter_suspend_mode) from [] (tegra_idle_lp2_last+0xc/0x40) > [ 3.433795] [] (tegra_idle_lp2_last) from [] (tegra20_idle_lp2_coupled+0x118/0x1fc) > [ 3.434171] [] (tegra20_idle_lp2_coupled) from [] (cpuidle_enter_state+0x3c/0x160) > [ 3.434551] [] (cpuidle_enter_state) from [] (cpuidle_enter_state_coupled+0x3dc/0x3f4) > [ 3.434959] [] (cpuidle_enter_state_coupled) from [] (cpu_startup_entry+0x240/0x288) > [ 3.435340] [] (cpu_startup_entry) from [] (start_kernel+0x3b4/0x3c0) > [ 3.435557] [] (start_kernel) from [<00008074>] (0x8074) > > Signed-off-by: Dmitry Osipenko Thanks for the report. I have been unable to reproduce this, but then I don't see my tegra20 entering LP2 during cpuidle. I did force my tegra20 into LP2 during suspend which will exercise the same code but I did not trigger this either. However, from looking at the code it does appear that we could hit this. > --- > drivers/clk/tegra/clk-tegra-pmc.c | 9 +++++++++ > drivers/soc/tegra/pmc.c | 2 +- > include/linux/clk/tegra.h | 2 ++ > 3 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/tegra/clk-tegra-pmc.c b/drivers/clk/tegra/clk-tegra-pmc.c > index 91377ab..1ccf414 100644 > --- a/drivers/clk/tegra/clk-tegra-pmc.c > +++ b/drivers/clk/tegra/clk-tegra-pmc.c > @@ -78,6 +78,8 @@ static struct pmc_clk_init_data pmc_clks[] = { > PMC_CLK(3, 22, 18), > }; > > +static struct clk_hw *pclk_hw; > + > void __init tegra_pmc_clk_init(void __iomem *pmc_base, > struct tegra_clk *tegra_clks) > { > @@ -112,6 +114,9 @@ void __init tegra_pmc_clk_init(void __iomem *pmc_base, > clk_register_clkdev(clk, data->dev_name, data->gate_name); > } > > + dt_clk = tegra_lookup_dt_id(tegra_clk_pclk, tegra_clks); > + pclk_hw = __clk_get_hw(*dt_clk); > + > /* blink */ > writel_relaxed(0, pmc_base + PMC_BLINK_TIMER); > clk = clk_register_gate(NULL, "blink_override", "clk_32k", 0, > @@ -129,3 +134,7 @@ void __init tegra_pmc_clk_init(void __iomem *pmc_base, > *dt_clk = clk; > } > > +unsigned long tegra_pmc_get_pclk_rate(void) > +{ > + return clk_hw_get_rate(pclk_hw); > +} Ideally, it would be great if we did not need to add another custom API for this, but I did not find anything in the CCF that would allow us to avoid but that was only a quick look. However, we could ask the CCF folks. What I plan to do next is to understand if the pclk is likely to change. I know that it comes from one of the plls but I am not sure if we ever change the rate. If not we may be able to move this to probe time and avoid this. Cheers Jon