From patchwork Thu Nov 13 23:27:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 5301691 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 26844C11AC for ; Thu, 13 Nov 2014 23:27:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 38AAF20125 for ; Thu, 13 Nov 2014 23:27:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5C5A82011E for ; Thu, 13 Nov 2014 23:27:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Xp3nw-0002KI-3H; Thu, 13 Nov 2014 23:27:56 +0000 Received: from mail-vc0-x232.google.com ([2607:f8b0:400c:c03::232]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Xp3nu-0001zr-A4 for linux-rockchip@lists.infradead.org; Thu, 13 Nov 2014 23:27:54 +0000 Received: by mail-vc0-f178.google.com with SMTP id hq12so5032329vcb.9 for ; Thu, 13 Nov 2014 15:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=V5t2DZ7LkXcal2W3bUPXBC8A2o8sI48J4QM9pnWtJMo=; b=FHSxUQmkI4HgnxQR+hCBuAPwL3jdGwb5llunzwhrm/E0v6UaJ9AtQJVMVwhd6a2aBH IGwpY7YNUyX6OCrHGd+uooaNyOF3poY8rYl4rVLzneFp3ieP2KUaNn9I8e38PnxB5mw/ zm+9u+kFBHOPxdn5uWwPC82KZjKDYWAfYc3DXfi89Y3vA0PM9sCyogb1jeRtHNrxuozO L9zBCbI7Fv0qn/bWEdkASBarYPgjjCZpEPDm6RYZ/7xMhWmxkSSB4WGktkA4drDdnkwW hAXFm201JaVF5PRCoOSK8WR+IHCXg8TK9vq0/ehJmEH16Vjr8vXWEPLyKv71RKHjT0I/ Ft9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=V5t2DZ7LkXcal2W3bUPXBC8A2o8sI48J4QM9pnWtJMo=; b=LATAP/8axxpkjgmpI2PG3Jk3FWjyxkW5q2F14/eK5Tqo3TQ6+tV5y4Icm5DAma4RdT bQYDTpdbda6QKfaGsdX1693uhD8E8rlXHMpm31XbUQBGwlIBdtlaS1ZW9zoyBgG7H93F uEAOaLVimQ4fswlLlRSg+aWiuCdKgx6HEsf70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V5t2DZ7LkXcal2W3bUPXBC8A2o8sI48J4QM9pnWtJMo=; b=eLKSPecXT3UV2MyVvWLuNKooTRVo990Cb1b/MLJW7fSVe3RzGpCUmSNf5o602ZMfht yNrO7wSZnRhquIRv73MeLKwCc3k1GbD3RSwCAFWXUzOOOllZR88vmsUNOSowHPsbmPvW ith/wHb5napvIP8fVsqkt/1Ugt4Cdg572PcbSFpkHLnU+VLbk8GpKDZ8L4HY8Gycbh5w j1KzE1zZb04yt+DR57K9mSxvyzBpe0ojFVjUNdXtMSk3g87R6qZ7rhD+nbhVzXTi6NNI aWsNX1r3qgaPVl4RadVqvTcp2orY5ujV4y+jyqeBJkqSBrO0Nbf1dGw8qGtoTUqq5qmb JlmA== X-Gm-Message-State: ALoCoQkdXbqHXk5lBROSJr51iORVzKOL1IMwWKijjLo000xLzidnMz4F+zH583LLb7juGYmvfU1L MIME-Version: 1.0 X-Received: by 10.220.7.69 with SMTP id c5mr4165194vcc.11.1415921252877; Thu, 13 Nov 2014 15:27:32 -0800 (PST) Received: by 10.52.165.65 with HTTP; Thu, 13 Nov 2014 15:27:32 -0800 (PST) In-Reply-To: <1641362.yfrjtMOWge@diego> References: <1415884826-7877-1-git-send-email-kever.yang@rock-chips.com> <1415884826-7877-2-git-send-email-kever.yang@rock-chips.com> <1641362.yfrjtMOWge@diego> Date: Thu, 13 Nov 2014 15:27:32 -0800 X-Google-Sender-Auth: PBj42ycoay5OPodgFnNmVHK6gOc Message-ID: Subject: Re: [RFC PATCH 1/2] clk: add property for force to update clock setting From: Doug Anderson To: =?UTF-8?Q?Heiko_St=C3=BCbner?= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141113_152754_423296_25A9ED77 X-CRM114-Status: GOOD ( 20.01 ) X-Spam-Score: -1.8 (-) Cc: Tao Huang , =?UTF-8?B?5oi05YWL6ZyWIChKYWNrKQ==?= , Addy Ke , Mike Turquette , Kever Yang , "linux-kernel@vger.kernel.org" , "open list:ARM/Rockchip SoC..." , Eddie Cai , Sonny Rao X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On Thu, Nov 13, 2014 at 6:53 AM, Heiko Stübner wrote: > Am Donnerstag, 13. November 2014, 21:20:25 schrieb Kever Yang: >> Usually we assigned a clock to a default rate in dts, >> there is a situation that the clock already initialized to the rate >> we intend to set before kernel(hardware default or init in uboot etc). >> For the PLLs we can get a rate from different PLL parameter configure, >> we can't change the PLL parameter if the rate is not changed by now. >> >> This patch adds a option property 'assigned-clock-force-rates' >> to make sure we update all the setting even if we don't need to >> update the clock rate. >> >> Signed-off-by: Kever Yang >> --- >> >> drivers/clk/clk-conf.c | 33 ++++++++++++++++++++++++++++++++- >> 1 file changed, 32 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c >> index aad4796..0c9df48 100644 >> --- a/drivers/clk/clk-conf.c >> +++ b/drivers/clk/clk-conf.c >> @@ -84,7 +84,7 @@ static int __set_clk_rates(struct device_node *node, bool >> clk_supplier) struct clk *clk; >> u32 rate; >> >> - of_property_for_each_u32(node, "assigned-clock-rates", prop, cur, rate) { >> + of_property_for_each_u32(node, "assigned-force-rates", prop, cur, rate) { >> if (rate) { >> rc = of_parse_phandle_with_args(node, "assigned-clocks", >> "#clock-cells", index, &clkspec); >> @@ -104,7 +104,38 @@ static int __set_clk_rates(struct device_node *node, >> bool clk_supplier) index, node->full_name); >> return PTR_ERR(clk); >> } >> + /* change the old rate to 0 to make sure we can get into >> + * clk_change_rate */ >> + clk->rate = 0; >> + rc = clk_set_rate(clk, rate); >> + if (rc < 0) >> + pr_err("clk: couldn't set %s clock rate: %d\n", >> + __clk_get_name(clk), rc); >> + clk_put(clk); > > Forcing clocks to 0 at first will probably create issues on some platfoms. > I think what Doug meant was something like [0], which would then enable > the clk_conf part to force the rate change. I haven't tested this yet, but it > seems the check in clk_set_rate is the only one checking for identical new > and old rates. Hrm, I was actually not thinking of adding a new device tree property. I was thinking that we'd _always_ call "force" for "assigned-clock-rates". Really the check in clk_set_rate() is an optimization (right?), not for correctness. Thus it should be OK to bypass it at bootup. Actually, maybe even better: for all clocks you should always skip the "clk_get_rate()" check the first time through. Then you'd ensure that you aren't using some default or firmware-assigned clock settings. AKA, something like this untested patch: I'm ducking now in case Mike decides to throw a tomato at me. -Doug diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 59d853d..56db138 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1618,9 +1618,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate) /* prevent racing with updates to the clock topology */ clk_prepare_lock(); - /* bail early if nothing to do */ - if (rate == clk_get_rate(clk)) + /* bail early if nothing to do; linux should always set the rate once */ + if (rate == clk_get_rate(clk) && clk->did_set_rate) goto out; + clk->did_set_rate = true; if ((clk->flags & CLK_SET_RATE_GATE) && clk->prepare_count) { ret = -EBUSY;