Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754597AbdGCPYT (ORCPT ); Mon, 3 Jul 2017 11:24:19 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33438 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbdGCPYR (ORCPT ); Mon, 3 Jul 2017 11:24:17 -0400 Subject: Re: [PATCH 2/3] clk: WARN_ON about to disable a critical clock To: Lee Jones , Dirk Behme Cc: kernel@stlinux.com, Michael Turquette , sboyd@codeaurora.org, linux-kernel@vger.kernel.org, geert@linux-m68k.org, maxime.ripard@free-electrons.com, s.hauer@pengutronix.de, linux-arm-kernel@lists.infradead.org, maxime.coquelin@st.com References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org> <1453127331-20616-3-git-send-email-lee.jones@linaro.org> <20160211004327.26445.27416@quark.deferred.io> <20170703115324.5re2d32bd3slutcb@dell> <20170703142517.tyojzmzofvyiicsn@dell> From: Dirk Behme Message-ID: <3544e773-7006-81a8-aaf7-638c987ed3fa@gmail.com> Date: Mon, 3 Jul 2017 17:24:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170703142517.tyojzmzofvyiicsn@dell> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3534 Lines: 109 On 03.07.2017 16:25, Lee Jones wrote: > On Mon, 03 Jul 2017, Dirk Behme wrote: > >> On 03.07.2017 13:53, Lee Jones wrote: >>> On Tue, 27 Jun 2017, Dirk Behme wrote: >>> >>>> On 11.02.2016 01:43, Michael Turquette wrote: >>>>> Quoting Lee Jones (2016-01-18 06:28:50) >>>>>> Signed-off-by: Lee Jones >>>>> >>>>> Looks good to me. >>>>> >>>>> Regards, >>>>> Mike >>>>> >>>>>> --- >>>>>> drivers/clk/clk.c | 6 ++++++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c >>>>>> index 835cb85..178b364 100644 >>>>>> --- a/drivers/clk/clk.c >>>>>> +++ b/drivers/clk/clk.c >>>>>> @@ -575,6 +575,9 @@ static void clk_core_unprepare(struct clk_core *core) >>>>>> if (WARN_ON(core->prepare_count == 0)) >>>>>> return; >>>>>> + if (WARN_ON(core->prepare_count == 1 && core->flags & CLK_IS_CRITICAL)) >>>>>> + return; >>>>>> + >>>>>> if (--core->prepare_count > 0) >>>>>> return; >>>>>> @@ -680,6 +683,9 @@ static void clk_core_disable(struct clk_core *core) >>>>>> if (WARN_ON(core->enable_count == 0)) >>>>>> return; >>>>>> + if (WARN_ON(core->enable_count == 1 && core->flags & CLK_IS_CRITICAL)) >>>>>> + return; >>>>>> + >>>>>> if (--core->enable_count > 0) >>>>>> return; >>>> >>>> >>>> I have a question regarding this patch, which is mainline meanwhile [1]: >>>> >>>> Having the following clock configuration: >>>> >>>> |--> child clk '1' (crit) >>>> clk source --> parent clk 'A' (crit) -->| >>>> |--> child clk '2' >>>> >>>> >>>> Clock '2' might be used, or not. It might be disabled or not. It doesn't >>>> matter. Clock '1' is not allowed to be disabled. Therefore its marked as >>>> critical. >>>> >>>> Parent clock 'A' is marked as critical because its not allowed to be >>>> disabled, even if the enable_count of all child clocks is 0. To avoid that >>>> by disabling parent clock 'A' the child clock '1' is disabled, too, whats >>>> not allowed as its marked as critical. >>>> >>>> >>>> Now, child clock '2' is used and enabled & disabled continuously by a (SPI) >>>> driver. What is ok. But: >>>> >>>> Disabling child clock '2' results in the attempt to disable parent clock >>>> 'A', too, which has correct enable_count 1 (from enabling the child '2'). >>>> What results >>>> >>>> a) in the WARN_ON output >>>> >>>> and >>>> >>>> b) enable_count of 'A' never decreases to 0. Being off by one after the >>>> WARN_ON >>>> >>>> >>>> It sounds like both is wrong for a configuration like above. >>> >>> Clock A still has one user, Clock 1. >>> >>> Why is that wrong? >> >> >> Because clock 1 is not a (Linux kernel clock framework) used clock. Its >> enable count is 0. So from Linux kernel (clock framework) point of view >> clock 1 is unused. > > All critical clocks are 'used'. That's the point of critical clocks. Could you translate 'used' to enable_count? Whats valid enable_count numbers for critical clocks? Best regards Dirk >> The increase/decrease of enable count of parent clock A is only driven by >> the Linux kernel usage of clock 2. >> >>>> Opinions or proposal how to fix/change this? >>>> >>>> >>>> Best regards >>>> >>>> Dirk >>>> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/clk/clk.c?id=2e20fbf592621b2c2aeddd82e0fa3dad053cce03 >