Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp5632426pxb; Sun, 7 Nov 2021 16:50:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQqewyp4o6BDO8PpgfFbgw5dD1dFJg3UmhwQIdt0NS0F1U0XJPajHz+CErtRtDJC5+NIpI X-Received: by 2002:a50:cbc2:: with SMTP id l2mr74767861edi.89.1636332612696; Sun, 07 Nov 2021 16:50:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636332612; cv=none; d=google.com; s=arc-20160816; b=Atm+Fz9WstiVN+jK+cSxY2S56laVvpziu2KyyfwEpaKSr64Ti2Br9q0jXOpExqeiOS YmG3e2t/hhcM+yqF4/Fj5SsJKIMci6XLDvzJGVTplVvOCGBoQHj4u31GGXRKOoqYGti8 5FqxsMJwwDzZTmH/3PpY83X9su/Fzcr29vkxlpdHu+fQJ/W7yqeJqN2gJ+3JQONo+Wsr oT0D76HecQS4q4kH9zVNjTcVhvMLNObCfOCQ/aIdK+bIp7hiETqlvpFDYpwlqmIuz1xw 2OWZ1l2T29+NGvcpjAGUVb7iaOhSIu2bi2dSM/2UyQPtqLAYAVtFzrOqHnzZdiFDDY8r idwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=unKo15JzTOTFaWesFvijrWxvCyjo4F82rqmN0Z0VB08=; b=tUymtxQMwIJZU5jq3nuuDtQuwxnX/hxLQOoPbcABEO2ClJ8VNh0K2tRcvfMu0jpWKh skxdiXaISPjzJl6aBkIs50CfkSb4ios14wQeC77LyzsRVOmMz39RCGwy0sKooJyE+LRi dHOdYgNLQjW9TSWeUIFWFe8Kb4ia0t+r3ViWF6hxwovYAJJe8efb9TDxrN52Rtfs7FWJ MiI0yKw1k6Il6rewjPD0emgchPSg9Gqa/zhBOgo0hP/wfApvPNmencYIH0c2R1WXWEdX uf7ty/UP9A4TsLhwRrBcFTtlpBEZaGvLt/RWoOJxy1Q/uQE8t+Hc5Oph8GgLgwqSpmOT wskQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EGPJwh6J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p5si20734796edi.454.2021.11.07.16.49.49; Sun, 07 Nov 2021 16:50:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EGPJwh6J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236153AbhKGSyg (ORCPT + 99 others); Sun, 7 Nov 2021 13:54:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234643AbhKGSyf (ORCPT ); Sun, 7 Nov 2021 13:54:35 -0500 Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D644CC061764 for ; Sun, 7 Nov 2021 10:51:52 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id az37so27422109uab.13 for ; Sun, 07 Nov 2021 10:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=unKo15JzTOTFaWesFvijrWxvCyjo4F82rqmN0Z0VB08=; b=EGPJwh6J+kr9X4pqliRLLDnvsjAufLqMhCfMsL1tt0vh0JjP0U6LeXXGxXUR1nT+Lr UdKRhGMej2TR+7cOfQZOO1tqUltNVYuvxhmNuCdy2dn5t3+oP7bdKWjdYKBoqukscVSq 1SRH8c8WthZYefrriBk4pEvVpWyEYZLhRCtvDqpakfsaRPlUrAUaNIFozbGbg5rFFDqO GJ2Z2XlUm6ar+AfzRnPLLriNS++hfmnFYE+ckuuUFyXx7pt/Xzn5Kv8Gg4wrQdFelLTV 3UthEI6FLjqhudMLMzF9rH48gUycDFY7zTw8ZCPcyS/ghwnoabTeAQ+/zdHhTWh9KVLW vTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=unKo15JzTOTFaWesFvijrWxvCyjo4F82rqmN0Z0VB08=; b=w4Cd/sYgOzr7b4h35pXP8TD4PBVVINCbmfidDy385TZwJmxLvu5/Owk3BSqwOR1UsF MTkdVb+MJuyxgZ9oRy6FMQsMKaX7ip15gE8Je6YN/gPPf3/1bIvHuMf/4pOHpgwePoKl z8fB/PkRQxuRg9KzMpbCioY9VQvTO99ej3x5wOScDGwJxWcz8jFHdmJbcyY2AzFGUu8B mdHTN8JbLA4Ms6gpziQgoWTePi3DSHLxZgwJEGHwh1eDjpsau3TrlNJUEADvzYwjkR7d KX9wtS0B/jNDlZcqCnxPDbG76vsUWGpx3dm9NPotKl0tjBFDhbIwHMyEGoLrNqLNg7Yh TnjA== X-Gm-Message-State: AOAM532F6hWOhb9lhHOH1St6dbOCP1Av66c4PAhbT8UrK5EgVh58ecwv uaH/bzmSaB35hr9NVlFPgbl82+7JchpnseBHDdVukQ== X-Received: by 2002:ab0:6002:: with SMTP id j2mr69495801ual.9.1636311111532; Sun, 07 Nov 2021 10:51:51 -0800 (PST) MIME-Version: 1.0 References: <20211031122216.30212-1-semen.protsenko@linaro.org> <20211031122216.30212-11-semen.protsenko@linaro.org> In-Reply-To: From: Sam Protsenko Date: Sun, 7 Nov 2021 20:51:39 +0200 Message-ID: Subject: Re: [PATCH v2 10/12] watchdog: s3c2410: Support separate source clock To: Guenter Roeck Cc: Krzysztof Kozlowski , Wim Van Sebroeck , Rob Herring , linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 7 Nov 2021 at 18:09, Guenter Roeck wrote: > > On 11/7/21 7:55 AM, Sam Protsenko wrote: > > On Tue, 2 Nov 2021 at 12:15, Krzysztof Kozlowski > > wrote: > >> > >> On 31/10/2021 13:22, Sam Protsenko wrote: > >>> Right now all devices supported in the driver have the single clock: it > >>> acts simultaneously as a bus clock (providing register interface > >>> clocking) and source clock (driving watchdog counter). Some newer Exynos > >>> chips, like Exynos850, have two separate clocks for that. In that case > >>> two clocks will be passed to the driver from the resource provider, e.g. > >>> Device Tree. Provide necessary infrastructure to support that case: > >>> - use source clock's rate for all timer related calculations > >>> - use bus clock to gate/ungate the register interface > >>> > >>> All devices that use the single clock are kept intact: if only one clock > >>> is passed from Device Tree, it will be used for both purposes as before. > >>> > >>> Signed-off-by: Sam Protsenko > >>> --- > >>> Changes in v2: > >>> - Reworded commit message to be more formal > >>> - Used separate "has_src_clk" trait to tell if source clock is present > >>> - Renamed clock variables to match their purpose > >>> - Removed caching source clock rate, obtaining it in place each time instead > >>> - Renamed err labels for more consistency > >>> > >>> drivers/watchdog/s3c2410_wdt.c | 52 +++++++++++++++++++++++++--------- > >>> 1 file changed, 39 insertions(+), 13 deletions(-) > >>> > >>> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c > >>> index fdb1a1e9bd04..c733917c5470 100644 > >>> --- a/drivers/watchdog/s3c2410_wdt.c > >>> +++ b/drivers/watchdog/s3c2410_wdt.c > >>> @@ -118,7 +118,9 @@ struct s3c2410_wdt_variant { > >>> > >>> struct s3c2410_wdt { > >>> struct device *dev; > >>> - struct clk *clock; > >>> + struct clk *bus_clk; /* for register interface (PCLK) */ > >>> + struct clk *src_clk; /* for WDT counter */ > >>> + bool has_src_clk; > >> > >> Why do you need the has_src_clk value? If clk_get() fails, just store > >> there NULL and clk API will handle it. > >> > > > > I've added that 'has_src_clk' field for somewhat different reason. > > > > 1. As we discussed earlier, in case when src_clk is not present, I do > > 'src_clk = bus_clk' in v2. This way I don't have to check if src_clk > > is NULL every time and use bus_clk to get rate. If I set src_clk = > > NULL, I'll have to add selector code, which wouldn't be so elegant, > > and contradicts what we've discussed. > > 2. On the other hand, I don't want to enable bus_clk twice in case > > when src_clk is not present, that just doesn't feel right (user would > > see incorrect refcount value in DebugFS, etc). And if "clk_src = > > bus_clk', and I haven't enabled it second time, then I shouldn't try > > to disable it second time, right? > > > > The only way I can see to accomplish (1) and (2) together, is to use > > that 'has_src_clk' flag. For me it still looks better than enabling > > bus_clk twice, or checking if clk_src is NULL every time we need to > > get clock rate. Please let me know if you still have a strong opinion > > on this one. > > > > This is odd. Why do you need to get the clock rate more than once, > instead of getting it once and storing it locally ? If the clock rate > can change, the watchdog timeout would be unpredictable. > For this particular driver it seems to be needed though. The driver tracks CPU freq change and tries to adjust timeout w.r.t. new clock frequency, as implemented in s3c2410wdt_cpufreq_*() functions. I don't really want to touch that functionality in my series, my goal here is to add Exynos850 support in the first place. But yeah, I did some analysis, and it seems like 25 out of 35 watchdog drivers (that call clk_get_rate()) just store the rate in probe. > Guenter