From patchwork Fri Mar 9 00:56:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shawn Lin X-Patchwork-Id: 10269485 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 E970D6037E for ; Fri, 9 Mar 2018 01:02:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 35B6729A95 for ; Fri, 9 Mar 2018 01:02:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2A73E29AAB; Fri, 9 Mar 2018 01:02:54 +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=-5.4 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4305A29A95 for ; Fri, 9 Mar 2018 01:02:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751231AbeCIBCw (ORCPT ); Thu, 8 Mar 2018 20:02:52 -0500 Received: from lucky1.263xmail.com ([211.157.147.135]:60177 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbeCIBCv (ORCPT ); Thu, 8 Mar 2018 20:02:51 -0500 Received: from shawn.lin?rock-chips.com (unknown [192.168.167.8]) by lucky1.263xmail.com (Postfix) with ESMTP id 965EF6A55; Fri, 9 Mar 2018 09:02:46 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id 5D2FB380; Fri, 9 Mar 2018 09:02:44 +0800 (CST) X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: mturquette@baylibre.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-SENDER: lintao@rock-chips.com X-DNS-TYPE: 0 Received: from localhost.localdomain (unknown [58.22.7.114]) by smtp.263.net (Postfix) whith ESMTP id 12716Y6A7LL; Fri, 09 Mar 2018 09:02:45 +0800 (CST) From: Shawn Lin To: Michael Turquette , Stephen Boyd Cc: Heiko Stuebner , linux-clk@vger.kernel.org, Jerome Brunet , Geert Uytterhoeven , Shawn Lin Subject: [PATCH v2] clk: Don't show the incorrect clock phase Date: Fri, 9 Mar 2018 08:56:39 +0800 Message-Id: <1520556999-74737-1-git-send-email-shawn.lin@rock-chips.com> X-Mailer: git-send-email 1.9.1 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 It's found that the clock phase output from clk_summary is wrong compared to the actual phase reading from the register. cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample sdio_sample 0 1 0 50000000 0 -22 It exposes an issue that clk core, clk_core_get_phase, always returns the cached core->phase which should be either updated by calling clk_set_phase or directly from the first place the clk was registered. When registering the clk, the core->phase geting from ->get_phase() may return negative value indicating error. This is quite common since the clk's phase may be highly related to its parent chain, but it was temporarily orphan when registered, since its parent chains hadn't be ready at that time, so the clk drivers decide to return error in this case. However, if no clk_set_phase is called or maybe the ->set_phase() isn't even implemented, the core->phase would never be updated. This is wrong, and we should try to update it when all its parent chains are settled down, like the way of updating clock rate for that. But it's not deserved to complicate the code now and just update it anyway when calling clk_core_get_phase, which would be much simple and enough. Signed-off-by: Shawn Lin Acked-by: Jerome Brunet --- Changes in v2: - fix the typos suggested by Geert - update cached phase anyway suggested by Jerome drivers/clk/clk.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 0f686a9..4070664 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2370,6 +2370,17 @@ static int clk_core_get_phase(struct clk_core *core) int ret; clk_prepare_lock(); + /* + * Always try to update cached phase if possible since + * (1) It may be invalid at the first place when registering + * the hw clock but never got updated if no ->set_phase() be + * implemented or called. + * (2) It may be stale along with the other factors, for instance, + * the hw clock's rate is changed but current framework doesn't + * notify the change of phase concurrent with that of rate. + */ + if (core->ops->get_phase) + core->phase = core->ops->get_phase(core->hw); ret = core->phase; clk_prepare_unlock();