Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp1516626imm; Fri, 6 Jul 2018 01:20:05 -0700 (PDT) X-Google-Smtp-Source: AAOMgpehoyzUvNSezXpt9y/p542+CWCMbCBRXgK193uBIWBfxIRKCFNwzNIkec3NUHZ/IcZTowLH X-Received: by 2002:a17:902:246a:: with SMTP id m39-v6mr9411517plg.141.1530865205168; Fri, 06 Jul 2018 01:20:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530865205; cv=none; d=google.com; s=arc-20160816; b=ZgcbePVBwkselH3jppyxVEQllTxBJ9mPmCsr8t6IKcHjlBww6SdmL+rPc84+Ay7NqU Yz4wWXgzmm+xcvE9qZe7Y3n+Tq8znkPS6T4oXsinDfziDf+tUzcD4wYTgVF4zueNQyJQ YGR5dadN/HE1CjzVPilAPJc9S81+swPlPaXf6END7r5/IpjzIk9UHmgVMW8gUbdoWBss VfaV4rP6Y5VeKQNx8jdMAx6lXWFZOc4MfMVYBmD/83yt4KMPEFE7OfIhG76ZQzkm6i+j vR/MLYgTyH2O091QIb9M0UH80nYqVCMaD1tB1pVfwFkPwBBNjPwO/cJqHYAkivz7O4vC qQ5g== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ykZI2s+05xrvUd33CDKkHEEJqVF+SzUuk+QTn/Hhomo=; b=dm8jZl31H6PIuNKImqz+pspc371cTvhq9yRWLZM0DjlWxJMietV/jjiGKykGxhQ9gP MIZtzXp84YxPs4FLY8aVWnewrHYTDfzfXRAe6pRNceh4R7RMrRYSMpM44Q1UbCcz1yTk a0V+f2lbk9CbBjPlgg5K1l9bcIsIl2vARkTJM37Cf1n8t0pPFsHsD1wpQWcCraCu7BaI qu0EtDoyKYh3LrmRBIAl2kFZ63eTxyEQAmhxmSrk6aVLVZpm1EHxhvQAi14TpUse5i4h jXQLp2QDGb9CJot1fEPhu+IHelwv8jkJzWmrORgQtEbZoYds8fCwOeLL8iOGhSAGxJMk Eg7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@broadcom.com header.s=google header.b=fDUbhWhf; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p21-v6si7518152plq.94.2018.07.06.01.19.50; Fri, 06 Jul 2018 01:20:05 -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=@broadcom.com header.s=google header.b=fDUbhWhf; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=broadcom.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753643AbeGFISH (ORCPT + 99 others); Fri, 6 Jul 2018 04:18:07 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:42479 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753630AbeGFISE (ORCPT ); Fri, 6 Jul 2018 04:18:04 -0400 Received: by mail-oi0-f67.google.com with SMTP id n84-v6so21928686oib.9 for ; Fri, 06 Jul 2018 01:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ykZI2s+05xrvUd33CDKkHEEJqVF+SzUuk+QTn/Hhomo=; b=fDUbhWhfGdUughY22QorGhsRHX6zuxceABRYzjDAt2DpPho7KwaZYjDhOEB87VX6BN aqZdAzzMsdV6n3coT1EsFBebHB8Nwid+b8ben8cpWMCgXYbopH757qgeTj+Qx8yq+Zdj ALFJbyO+aVteiwgA1Tclh1+aXR6YoF9SBWuR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ykZI2s+05xrvUd33CDKkHEEJqVF+SzUuk+QTn/Hhomo=; b=JnjVP2ECwSfdOLSr9TmM9LZ+FfXt4U2vHJXEAxPy5tM7i/HBoccKhc4iWbF13eDkvc 7ohhc6ZIcSGzTvy+potUA3RWU2//lnZehCYSuxpTmKcixbQhGpVbZo5/A5zSfeGeNpDn zFtwCpoCMlLn2lDhKwlfs6C0TP9xSHRtyiH3TmFg3jo/p+JLiHMa/L+1WRls0Fz6Q9zI 9NnltL7Xs41ELBwyA1xr74KeUEA+kG67iZkV7rnTfUMF/VChCEkp18RrD1xpcECVI0T0 u/iz/bhKzMlPr73DW1oGl78N14u5RshICnEEBwEhhdVfKxpEwX5caZ4Y4c2IF/i8vWlg qWOQ== X-Gm-Message-State: APt69E1zEItMEQVnvWc56KO9DL+SStv4ekDoCHZKeRsm48hK3ZM7N9W5 uvVeuqzK1J+b+kCbYM8bbpDLzu9RpsKPBFlGZ/c2OA== X-Received: by 2002:aca:d956:: with SMTP id q83-v6mr9693616oig.349.1530865083196; Fri, 06 Jul 2018 01:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:51d2:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 01:18:02 -0700 (PDT) In-Reply-To: References: <1530760968-13104-1-git-send-email-srinath.mannam@broadcom.com> From: Srinath Mannam Date: Fri, 6 Jul 2018 13:48:02 +0530 Message-ID: Subject: Re: [RFC PATCH] watchdog: sp805: Add clock-frequency property To: Guenter Roeck Cc: wim@linux-watchdog.org, Ray Jui , Vladimir Olovyannikov , Vikram Prakash , Scott Branden , Sudeep Holla , linux-watchdog@vger.kernel.org, Linux Kernel Mailing List 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 Hi Guenter, Thank you very much for your feedback. Please find my comments. On Thu, Jul 5, 2018 at 8:58 PM, Guenter Roeck wrote: > On 07/04/2018 08:22 PM, Srinath Mannam wrote: >> >> When using ACPI node, binding clock devices are >> not available as device tree, So clock-frequency >> property given in _DSD object of ACPI device is >> used to calculate Watchdog rate. >> >> Signed-off-by: Srinath Mannam >> --- >> drivers/watchdog/sp805_wdt.c | 29 ++++++++++++++++++++++++----- >> 1 file changed, 24 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c >> index 9849db0..d830dbc 100644 >> --- a/drivers/watchdog/sp805_wdt.c >> +++ b/drivers/watchdog/sp805_wdt.c >> @@ -22,6 +22,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -65,6 +66,7 @@ struct sp805_wdt { >> spinlock_t lock; >> void __iomem *base; >> struct clk *clk; >> + u64 rate; >> struct amba_device *adev; >> unsigned int load_val; >> }; >> @@ -80,7 +82,10 @@ static int wdt_setload(struct watchdog_device *wdd, >> unsigned int timeout) >> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd); >> u64 load, rate; >> - rate = clk_get_rate(wdt->clk); >> + if (wdt->rate) >> + rate = wdt->rate; >> + else >> + rate = clk_get_rate(wdt->clk); > > > No. Get the rate once during probe and store it in wdt->rate. clk_get_rate function was called multiple places in the driver. so that we thought, there may be cases where clock rate can change at run-time. That is the reason, I keep clk_get_rate function. > >> /* >> * sp805 runs counter with given value twice, after the end of >> first >> @@ -108,7 +113,10 @@ static unsigned int wdt_timeleft(struct >> watchdog_device *wdd) >> struct sp805_wdt *wdt = watchdog_get_drvdata(wdd); >> u64 load, rate; >> - rate = clk_get_rate(wdt->clk); >> + if (wdt->rate) >> + rate = wdt->rate; >> + else >> + rate = clk_get_rate(wdt->clk); > > > Same here. > >> spin_lock(&wdt->lock); >> load = readl_relaxed(wdt->base + WDTVALUE); >> @@ -230,11 +238,22 @@ sp805_wdt_probe(struct amba_device *adev, const >> struct amba_id *id) >> wdt->clk = devm_clk_get(&adev->dev, NULL); >> if (IS_ERR(wdt->clk)) { >> - dev_warn(&adev->dev, "Clock not found\n"); >> - ret = PTR_ERR(wdt->clk); >> - goto err; >> + dev_warn(&adev->dev, "Clock device not found\n"); > > > "Clock _device_" ? Why this change ? And why retain that warning > unconditionally ? I mean, peripheral may have clock input but clock device node is not available to this driver. So I keep the warning. I thought to handle this better, divide this part of code into two parts based on device tree and ACPI. But this driver implementation is independent of device tree and ACPI calls. To get device-tree properties watch-dog framework APIs are called ex: timeout. Can I add ACPI and device tree node availability check to get clock device and clock-frequency properties. Please advice. > >> + wdt->clk = NULL; >> + /* >> + * When Driver probe with ACPI device, clock devices >> + * are not available, so watchdog rate get from >> + * clock-frequency property given in _DSD object. >> + */ >> + device_property_read_u64(&adev->dev, "clock-frequency", >> + &wdt->rate); >> + if (!wdt->rate) { >> + ret = -ENODEV; > > > This unconditionally overrides the original error. I accept, I will change. > >> + goto err; >> + } >> } >> + > > > No whitespace changes, please. I will remove. > > Does that mean that ACPI doesn't support the clock subsystem and that each > driver > supporting ACPI must do this ? That would be messy. Also, the above does not > check > if the device was probed through ACPI. It just tries to find an undocumented > "clock-frequency" property which is quite different and would apply to > (probably mis-configured) devicetree files as well. > > Either case, I would rather have this addressed through the clock subsystem. > Otherwise, someone with subject knowledge will have to confirm that this is > the > appropriate solution. If so, the new property will have to be documented as > an > alternative to clock specifiers and accepted by devicetree maintainers. > I checked with ACPI maintainers, ACPI does not support common-clock framework and also no plan. AMBA framework also request for "apb_pclk" clock node to enable pclk. But ACPI does not do the same. So in device-tree use case, both apb_pclk and wdt clock nodes are required properties, so passing clock-frequency alone can not be alternative. Because ACPI does not support clk node method, I came up with alternate fixed-clock property clock-frequency. clock-frequency is only specific to ACPI case, so we can't add in binding document. I will add device tree and ACPI specific check to read clock nodes and clock-frequency properties separately. If you are fine with this I will send the next patch with modifications. > Guenter > >> wdt->adev = adev; >> wdt->wdd.info = &wdt_info; >> wdt->wdd.ops = &wdt_ops; >> > Thank you, Regards, Srinath.