From patchwork Fri May 6 17:17:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 9034811 X-Patchwork-Delegate: sboyd@codeaurora.org Return-Path: X-Original-To: patchwork-linux-clk@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id F41D19F1D3 for ; Fri, 6 May 2016 17:18:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 078F72038A for ; Fri, 6 May 2016 17:18:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F29F820382 for ; Fri, 6 May 2016 17:18:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758161AbcEFRRw (ORCPT ); Fri, 6 May 2016 13:17:52 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:40156 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757219AbcEFRRv (ORCPT ); Fri, 6 May 2016 13:17:51 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 456A461315; Fri, 6 May 2016 17:17:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id B048660222; Fri, 6 May 2016 17:17:49 +0000 (UTC) Date: Fri, 6 May 2016 10:17:48 -0700 From: Stephen Boyd To: Joachim Eastwood Cc: Mike Turquette , linux-clk , Vladimir Zapolskiy Subject: Re: clk-lpc18xx-creg - scheduling while atomic Message-ID: <20160506171748.GS3492@codeaurora.org> References: <572B62AC.1020205@mleia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 05/05, Joachim Eastwood wrote: > Hi Stephen, > > On 5 May 2016 at 17:11, Vladimir Zapolskiy wrote: > > Hi Joachim, > > > > On 05.05.2016 14:53, Joachim Eastwood wrote: > >> Hi, > >> > >> I just tried next/master on my lpc18xx platform and got a 'scheduling > >> while atomic' on the msleep in clk_creg_32k_prepare. This does not > >> occur on 4.6-rc1. See below for backtrace. > >> > >> According to Documentation/clk.txt, Part 6 - Locking, sleeping is > >> allowed in prepare functions. Changing the msleep to an mdelay makes > >> the problem go away. > >> > >> So any ideas to what is going on? > >> > > > > the bug description resembles a recent problem on iMX7, you may find > > details from "clk: imx: do not sleep if IRQ's are still disabled" > > thread, the same sleeping clk_core_prepare() from time_init(), while > > sleeping is not allowed until the timer is ready. > > Thanks alot, Vladimir! > That sheed more light on the problem. > > Doing a partial revert of 32b9b10961860 ("clk: Allow clocks to be > marked as CRITICAL") also fixes the problem. 32b9b10961860 makes it > possible to call clk prepare, which is allowed to sleep, when clocks > are first created from of_clk_init(). of_clk_init() is called very > early where it's not allow to sleep at all[1]. > > What do you suggest, Stephen? > Calling prepare() from __clk_core_init() doesn't seem like a good idea > to me. I think the core clk handing of critical clocks needs to change > here. Yeah we need to figure out something for people who are using critical clks in of_clk_init() path because that's just not going to work if they sleep in their prepare callbacks. Regardless, is your driver using critical clks? It seems more like we need to apply this patch so that the flags member of clk_init_data isn't full of junk that might match against the critical flag? ---8<---- Acked-by: Joachim Eastwood diff --git a/drivers/clk/nxp/clk-lpc18xx-creg.c b/drivers/clk/nxp/clk-lpc18xx-creg.c index d44b61afa2dc..9e35749dafdf 100644 --- a/drivers/clk/nxp/clk-lpc18xx-creg.c +++ b/drivers/clk/nxp/clk-lpc18xx-creg.c @@ -147,6 +147,7 @@ static struct clk *clk_register_creg_clk(struct device *dev, init.name = creg_clk->name; init.parent_names = parent_name; init.num_parents = 1; + init.flags = 0; creg_clk->reg = syscon; creg_clk->hw.init = &init;