From patchwork Wed Aug 10 21:09:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 9274139 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7738F600CB for ; Wed, 10 Aug 2016 21:11:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5FDC727FC0 for ; Wed, 10 Aug 2016 21:11:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4F8AE283E9; Wed, 10 Aug 2016 21:11:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D279C27FC0 for ; Wed, 10 Aug 2016 21:11:35 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bXal5-0003My-Ar; Wed, 10 Aug 2016 21:09:51 +0000 Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bXal0-0003KK-L2; Wed, 10 Aug 2016 21:09:47 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 87C64612F8; Wed, 10 Aug 2016 21:09:25 +0000 (UTC) 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 D294A61271; Wed, 10 Aug 2016 21:09:23 +0000 (UTC) Date: Wed, 10 Aug 2016 14:09:22 -0700 From: Stephen Boyd To: James Liao Subject: Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents Message-ID: <20160810210922.GD2996@codeaurora.org> References: <1466581229-2342-1-git-send-email-erin.lo@mediatek.com> <1466581229-2342-2-git-send-email-erin.lo@mediatek.com> <20160702012140.GB17071@codeaurora.org> <1467604308.26485.4.camel@mtksdaap41> <146802073038.73491.6675612765998057903@resonance> <1468225452.31247.7.camel@mtksdaap41> <1470203182.17063.3.camel@mtksdaap41> <1470721183.8551.6.camel@mtksdaap41> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1470721183.8551.6.camel@mtksdaap41> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160810_140946_869628_B40B9C77 X-CRM114-Status: GOOD ( 21.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sascha Hauer , srv_heupstream@mediatek.com, Arnd Bergmann , devicetree@vger.kernel.org, Michael Turquette , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-mediatek@lists.infradead.org, Philipp Zabel , Matthias Brugger , Erin Lo , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP (Including lists) On 08/09, James Liao wrote: > On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote: >> >> Hi Mike, >> >> Do you have new patches to fix new clock parents? If not, I think we can >> use my patch first. Is it okay? >> > > Hi Stephen, > > Do you have comments for the bug fixing? I prefer to use my patch (clk: > fix initial state of critical clock's parents). How do you think? > How about we recalc accuracies and rates in addition to the patch from Mike? That will fix everything? ---8<---- From: Michael Turquette Subject: [PATCH] clk: migrate ref counts when orphans are reunited It's always nice to see families reunited, and this is equally true when talking about parent clocks and their children. However, if the orphan clk had a positive prepare_count or enable_count, then we would not migrate those counts up the parent chain correctly. This has manifested with the recent critical clocks feature, which often enables clocks very early, before their parents have been registered. Fixed by replacing the call to clk_core_reparent with calls to __clk_set_parent_{before,after}. Cc: James Liao Cc: Erin Lo Signed-off-by: Michael Turquette [sboyd@codeaurora.org: Recalc accuracies and rates too] Signed-off-by: Stephen Boyd Tested-by: James Liao --- drivers/clk/clk.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 820a939fb6bb..dc3fff2bf839 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2449,8 +2449,16 @@ static int __clk_core_init(struct clk_core *core) hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) { struct clk_core *parent = __clk_init_parent(orphan); - if (parent) - clk_core_reparent(orphan, parent); + /* + * we could call __clk_set_parent, but that would result in a + * reducant call to the .set_rate op, if it exists + */ + if (parent) { + __clk_set_parent_before(orphan, parent); + __clk_set_parent_after(orphan, parent, NULL); + __clk_recalc_accuracies(orphan); + __clk_recalc_rates(orphan, 0); + } } /*