From patchwork Thu Nov 9 09:15:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tero Kristo X-Patchwork-Id: 118412 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp6344823qgn; Thu, 9 Nov 2017 01:15:48 -0800 (PST) X-Google-Smtp-Source: ABhQp+R9p9YZMbPr6btoT5zYt6wIpU0oAERtgxkGgW/jtcaPO4huaV7OgkUQSll49aPTj3SpalXG X-Received: by 10.84.246.195 with SMTP id j3mr515476plt.7.1510218948575; Thu, 09 Nov 2017 01:15:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510218948; cv=none; d=google.com; s=arc-20160816; b=oNSqkdbVADiMxrF/ho+xTrbA9014EKBJEWBnuegaoI2D80Kajjw4lYR6sNfkCP86gI IH4WWOSpHggFhettmC86IXsdIJ8sw59KWuL7eLxh/3J3JcEt4G5h0r3n9r0uRqMd52gc lEgQyvmY6Uv+o8Qb+Yur1R4CiaJsA7dHDALGYiMPrfxzzDTp+ZRz5/pyVQWDI4w4QbYE X2h6KJIpiAW+oyeRdVRUuUTfel0oVSioHqv3ZAiPuF60kNeTCfmgPtGhDxYSAq1kifJB bU0Aa18YkBHSvdAW6VprXbwFZRDgh3ctV0cTe5bpn0S1p4+2CjROVMLPfOLZbOoV6HZg /+ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=1GAF3EjZVaTbvb7Kq/cpcuutf22ZSQjWmruRu82QxAA=; b=cqLQo5iCjAMAeEYJdkpaJVwT2bSSGSlnN5cgdDJhqMws2etOQk6AutdCrrImWfBJez 1R5QxWZwft2ekq1dE5a/L6jRpsUSN34MPwM+q33/oQap7ai27DfuqjhpUJhLfmiYJRKs 9kObzUDmUiSrHAEHLYFIoJSvuDsirNe3yzzzv3KsBGlIIx1/p2qnsuCtryiXldOpTEtS GFyUXjmKhmkFMV3jxojhTWip0bZQqKiVGX60vSI9Sip0zF+oVQfLTJrr9mx16T4FH+bx X2c9VgqWqhvGariE/MQiSsmUcn1Tvb+Ea6hvqanWk2zlPfJkLJmtQUXQUd2TdVp8gPjo B7oQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@ti.com header.s=ti-com-17Q1 header.b=Ub1VkSwp; spf=pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-omap-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r4si5770893pgt.604.2017.11.09.01.15.48; Thu, 09 Nov 2017 01:15:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@ti.com header.s=ti-com-17Q1 header.b=Ub1VkSwp; spf=pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-omap-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753931AbdKIJPp (ORCPT + 4 others); Thu, 9 Nov 2017 04:15:45 -0500 Received: from lelnx194.ext.ti.com ([198.47.27.80]:43740 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753797AbdKIJPl (ORCPT ); Thu, 9 Nov 2017 04:15:41 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id vA99Fbc2030339; Thu, 9 Nov 2017 03:15:37 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1510218937; bh=S/kUkvO7LzAQ/dcKVPg+L20jZpC/xeAYAIYPz53MiZo=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=Ub1VkSwpJP9IF3ccFf5x2uqkY6Ac2pkg+zAmAWjgSM9/WpbTl7xyy34BQz0xk03Vp kMmrgxK7VHk1sTWmKjt2n4FX99GI4Lif1Wdg3YQhuIfJmlVc8zIOB2QNhT/SWH0+FG E1ItGKuGsbqi6dqx95L221F6iD61qX2gzvBNmz1c= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id vA99Fbsm024518; Thu, 9 Nov 2017 03:15:37 -0600 Received: from DFLE113.ent.ti.com (10.64.6.34) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Thu, 9 Nov 2017 03:15:36 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.845.34 via Frontend Transport; Thu, 9 Nov 2017 03:15:36 -0600 Received: from gomoku.home (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id vA99FWbq012718; Thu, 9 Nov 2017 03:15:35 -0600 From: Tero Kristo To: , CC: , , Subject: [PATCHv2 04/28] clk: ti: clkctrl: use fallback udelay approach if timekeeping is suspended Date: Thu, 9 Nov 2017 11:15:14 +0200 Message-ID: <1510218917-1725-2-git-send-email-t-kristo@ti.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1510218917-1725-1-git-send-email-t-kristo@ti.com> References: <1510218917-1725-1-git-send-email-t-kristo@ti.com> MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org In certain cases it is possible that the timekeeping has been suspended already when attempting to disable/enable a clkctrl clock. This will happen at least on am43xx platform when attempting to enable / disable the clockevent source itself, burping out a warning from timekeeping core. The sequence of events leading to this: -> timekeeping_suspend() -> clockevents_suspend() -> omap_clkevt_idle() -> omap_hwmod_idle() -> _omap4_clkctrl_clk_disable() -> _omap4_is_timeout() Avoid the issue by checking if the timekeeping is suspended and using the fallback udelay approach for checking timeouts. Signed-off-by: Tero Kristo --- drivers/clk/ti/clkctrl.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) -- 1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Acked-by: Stephen Boyd diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c index 284ba449..38dbcc1 100644 --- a/drivers/clk/ti/clkctrl.c +++ b/drivers/clk/ti/clkctrl.c @@ -21,6 +21,7 @@ #include #include #include +#include #include "clock.h" #define NO_IDLEST 0x1 @@ -90,7 +91,18 @@ static bool _omap4_is_ready(u32 val) static bool _omap4_is_timeout(union omap4_timeout *time, u32 timeout) { - if (unlikely(_early_timeout)) { + /* + * There are two special cases where ktime_to_ns() can't be + * used to track the timeouts. First one is during early boot + * when the timers haven't been initialized yet. The second + * one is during suspend-resume cycle while timekeeping is + * being suspended / resumed. Clocksource for the system + * can be from a timer that requires pm_runtime access, which + * will eventually bring us here with timekeeping_suspended, + * during both suspend entry and resume paths. This happens + * at least on am43xx platform. + */ + if (unlikely(_early_timeout || timekeeping_suspended)) { if (time->cycles++ < timeout) { udelay(1); return false;