Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3781imm; Fri, 19 Oct 2018 16:08:40 -0700 (PDT) X-Google-Smtp-Source: ACcGV61Vs0QBlfifa6mVrS8n3OVsYs++rQU+pDC+AkMGwshhWHouK3eQADe/Jz0xf+17bqX7I9Md X-Received: by 2002:a63:7f0e:: with SMTP id a14-v6mr34358086pgd.296.1539990520745; Fri, 19 Oct 2018 16:08:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539990520; cv=none; d=google.com; s=arc-20160816; b=CmNXe5jRQFewxdM7/ALNTTG5yV9ZODvpQk0hx/BoDQk6hRKmdbKCSdPkZ3mkz0esKH b6uQ7DzJBl5mJSn90WviSsGOgh7ozSbyuIktpo/TOpRVCI+JzJma1b0TzZPmaBeA3zVu sIEZayM+0ynSlumVaXRp3U21K1irgfMmRSJ/EzoiK2hFKKjnCDDJjOuFGvh0T0kuyz2T rYVxokKLSZBauE1LCkzIDHBGvnpIpvNYD5l3JW17rVJId3rFf/zRJ6azjgC//qJVIASS Laearh8KznOoNCqQslWHOR7LoEL8FVhJeZmI3ktrRH7zqv/UIjEQOiVkcIEFJLfRLnZd 9Eaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=V6NTIQparOMPx9sx9IqYeTGacmCxgEWqBM1eJiLj60c=; b=WdbMBoZoTOIn/Zr4FQyR95wn7y6cSBgXmh1sFO9PCqqDIUbAAa0l+UGSf7Xd05ifdz 4h6PJQk44/5wjuQBOeJfQ7GJCw05mJXuLH3/sFy/p6cICGTZnhpGqOUb2Wf0Ex0DQ3jl /zFm/uQZ6CRArvTdNu1FFd1TqTj01WWsgbY592CSrc0jvAk9BUlhWe0RbWFqCyxcFB8G AAlBSNDY6kJlhm5Z6cpukHPR0a8CDg8m+jWuKq/BxFAwMKTHjJVUo9gnlSTju/nr01oh qoWw1uQaMF29jeW+cLlohyCiy8C7RJ0zy3HHyx4MPMJq5xyTAfTf3Jpm/3Ws6HtL2XoB av5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="i/PliEip"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r134-v6si27932909pfc.202.2018.10.19.16.08.24; Fri, 19 Oct 2018 16:08:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="i/PliEip"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726604AbeJTHPj (ORCPT + 99 others); Sat, 20 Oct 2018 03:15:39 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:42479 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbeJTHPj (ORCPT ); Sat, 20 Oct 2018 03:15:39 -0400 Received: by mail-io1-f67.google.com with SMTP id n18-v6so23940767ioa.9 for ; Fri, 19 Oct 2018 16:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V6NTIQparOMPx9sx9IqYeTGacmCxgEWqBM1eJiLj60c=; b=i/PliEip8BaRyJonZCHOuZ8EGqoXw7PP8wmv4tcNnOyQvMJF+xtW9y7QdvT/KSDN08 kpvW6Vqu84oroqSQzdMdDGBaW3I98WOBLaiB4LeR8YzPf26jUpkG8T5oatnsf5o8c4zV j0tpujAkgnI2fpx1LFEDhpQczzYeP3wfC4tPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V6NTIQparOMPx9sx9IqYeTGacmCxgEWqBM1eJiLj60c=; b=ISEsxUnoB+zjBIxajKRnPClmBG3HBvHcOXwMg61weEtTA8S421Y5XHz3dWDSnXPyUy EBvRBqrSuQ0TH/6vyMWlU2LzgMEFk8OI/oOGcNUbJnTZS0URPW/QNWkidljtaMLmtnxe VuPi7fcPIIGgsieLeJe3O0WsxjyKi7ae92c/A0ckDU2dfGjVjJXHigh6VG7Q53R0KSWl a/2qkmt7ladJ1fa3PkYgBUjFjr63CgnNR5YZT/BoMrdxdfInTHzM5xQIi4f5oEosij5b OEUOGIhieOcGeDyTj1ckGrjOhhnPi0q3m9g8uOUeDkaQsFrTuiihp0phAzS71iwqhauK L9iA== X-Gm-Message-State: AGRZ1gLQxm346BLRdIkgzJzM6OTDBTLOBKtRvdkp2dmEmJH95RGw9Kvo UIp89Qz0V0ImYSIjYWZfE3Ed6cPcQHszHxQGdrj1hw== X-Received: by 2002:a6b:ac45:: with SMTP id v66-v6mr4530142ioe.66.1539990453084; Fri, 19 Oct 2018 16:07:33 -0700 (PDT) MIME-Version: 1.0 References: <20180831212007.247186-1-dbasehore@chromium.org> In-Reply-To: <20180831212007.247186-1-dbasehore@chromium.org> From: "dbasehore ." Date: Fri, 19 Oct 2018 16:07:21 -0700 Message-ID: Subject: Re: [PATCH] clk: fix clk_calc_subtree compute duplications To: sboyd@kernel.org Cc: Michael Turquette , linux-clk@vger.kernel.org, linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 31, 2018 at 2:20 PM Derek Basehore wrote: > > clk_calc_subtree was called at every step up the clk tree in > clk_calc_new_rates. Since it recursively calls itself for its > children, this means it would be called once on each clk for each > step above the top clk is. > > This is fixed by adding a non-recursive function called at every > step in clk_calc_new_rates that fills in new_rate, new_parent, etc. > Since the clks not called directly for clk_calc_new_rates can only > change their rate, we only set new_rate in clk_calc_subtree. > clk_calc_subtree is also only called on the top clk after it's found > via clk_calc_new_rates to remove the duplicate recursive calls. > > Signed-off-by: Derek Basehore > --- > drivers/clk/clk.c | 20 ++++++++++++-------- > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index d31055ae6ec6..52032fb1a8a2 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -1609,11 +1609,18 @@ static int __clk_speculate_rates(struct clk_core *core, > return ret; > } > > -static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate, > - struct clk_core *new_parent, u8 p_index) > +static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate) > { > struct clk_core *child; > > + core->new_rate = new_rate; > + hlist_for_each_entry(child, &core->children, child_node) > + clk_calc_subtree(child, clk_recalc(child, new_rate)); > +} > + > +static void clk_set_change(struct clk_core *core, unsigned long new_rate, > + struct clk_core *new_parent, u8 p_index) > +{ > core->new_rate = new_rate; > core->new_parent = new_parent; > core->new_parent_index = p_index; > @@ -1621,11 +1628,6 @@ static void clk_calc_subtree(struct clk_core *core, unsigned long new_rate, > core->new_child = NULL; > if (new_parent && new_parent != core->parent) > new_parent->new_child = core; > - > - hlist_for_each_entry(child, &core->children, child_node) { > - child->new_rate = clk_recalc(child, new_rate); > - clk_calc_subtree(child, child->new_rate, NULL, 0); > - } > } > > /* > @@ -1709,7 +1711,7 @@ static struct clk_core *clk_calc_new_rates(struct clk_core *core, > top = clk_calc_new_rates(parent, best_parent_rate); > > out: > - clk_calc_subtree(core, new_rate, parent, p_index); > + clk_set_change(core, new_rate, parent, p_index); > > return top; > } > @@ -1910,6 +1912,8 @@ static int clk_core_set_rate_nolock(struct clk_core *core, > if (ret) > return ret; > > + clk_calc_subtree(top, top->new_rate); > + Oops. This is wrong. Calling here will overwrite new rate settings such as when determine_rate/round_rate return something different than clk_recalc(core, parent_rate). I'm working on a larger patch series where this will be fixed. > /* notify that we are about to change rates */ > fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE); > if (fail_clk) { > -- > 2.19.0.rc1.350.ge57e33dbd1-goog >