From: Guenter Roeck <linux@roeck-us.net>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Arnd Bergmann <arnd@arndb.de>, Stephen Boyd <sboyd@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v2 0/3] add "delay" clock support to gpio_wdt
Date: Mon, 8 Mar 2021 21:51:51 -0800 [thread overview]
Message-ID: <1c0cd771-6067-69be-9838-9d3ab24a2503@roeck-us.net> (raw)
In-Reply-To: <20210304221247.488173-1-linux@rasmusvillemoes.dk>
On 3/4/21 2:12 PM, Rasmus Villemoes wrote:
> As Arnd and Guenther suggested, this adds support to the gpio_wdt
> driver for being a consumer of the clock driving the ripple
> counter. However, I don't think it should be merged as-is, see below.
>
> The first patch makes sense on its own, quick grepping suggests plenty
> of places that could benefit from this, and I thought it would be odd
> to have to re-introduce a .remove callback in the gpio_wdt driver.
>
This has zero chance to be accepted. As suggested in the patch,
just use devm_add_action(), like many other watchdog drivers.
> Unfortunately, this turns out to be a bit of an "operation succeeded,
> patient (almost) died": We use CONFIG_GPIO_WATCHDOG_ARCH_INITCALL
> because the watchdog has a rather short timeout (1.0-2.25s, 1.6s
> typical according to data sheet). At first, I put the new code right
> after the devm_gpiod_get(), but the problem is that this early, we get
> -EPROBE_DEFER since the clock provider (the RTC which sits off i2c)
> isn't probed yet. But then the board would reset because it takes way
> too long for the rest of the machine to initialize. [The bootloader
> makes sure to turn on the RTC's clock output so the watchdog is
> actually functional, the task here is to figure out the proper way to
> prevent clk_disable_unused() from disabling it.]
>
Is there a property indicating always-on for clocks, similar to
regulator-always-on ? The idea seems to exist, but it looks like
it is always explict (ie mentioned somewhere in the code that a clock
is always on, or "safe"). It would help if the clock in question
can be marked as always-on without explicit consumer.
Thanks,
Guenter
> Moving the logic to after the first "is it always-running and if so
> give it an initial ping" made the board survive, but unfortunately the
> second, and succesful, probe happens a little more than a second
> later, which happens to work on this particular board, but is
> obviously not suitable for production given that it's already above
> what the spec says, and other random changes in the future might make
> the gap even wider.
>
> So I don't know. The hardware is obviously misdesigned, and I don't
> know how far the mainline kernel should stretch to support this; OTOH
> the kernel does contain lots of workarounds for quirks and hardware
> bugs.
>
>
>
>
> Rasmus Villemoes (3):
> clk: add devm_clk_prepare_enable() helper
> dt-bindings: watchdog: add optional "delay" clock to gpio-wdt binding
> watchdog: gpio_wdt: implement support for optional "delay" clock
>
> .../devicetree/bindings/watchdog/gpio-wdt.txt | 6 ++++
> .../driver-api/driver-model/devres.rst | 1 +
> drivers/clk/clk-devres.c | 29 +++++++++++++++++++
> drivers/watchdog/gpio_wdt.c | 9 ++++++
> include/linux/clk.h | 13 +++++++++
> 5 files changed, 58 insertions(+)
>
prev parent reply other threads:[~2021-03-09 5:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 14:14 [PATCH 0/2] add ripple counter dt binding and driver Rasmus Villemoes
2021-02-26 14:14 ` [PATCH 1/2] dt-bindings: misc: add binding for generic ripple counter Rasmus Villemoes
2021-03-08 17:21 ` Rob Herring
2021-03-08 20:02 ` Rasmus Villemoes
2021-03-08 21:38 ` Rob Herring
2021-03-09 7:39 ` Rasmus Villemoes
2021-03-09 15:44 ` Rob Herring
2021-02-26 14:14 ` [PATCH 2/2] drivers: misc: add ripple counter driver Rasmus Villemoes
2021-02-28 5:47 ` Chen, Mike Ximing
[not found] ` <CAHp75Vc8S2E0vWFcqK-jO9Nhd-Us_7t-aWNj-7k+fWDcqR1XkQ@mail.gmail.com>
2021-02-28 9:29 ` Andy Shevchenko
2021-02-28 9:33 ` Andy Shevchenko
2021-03-01 8:29 ` Rasmus Villemoes
2021-02-26 14:35 ` [PATCH 0/2] add ripple counter dt binding and driver Arnd Bergmann
2021-02-26 16:35 ` Rasmus Villemoes
2021-02-26 19:53 ` Guenter Roeck
2021-03-01 8:34 ` Rasmus Villemoes
2021-03-01 9:44 ` Arnd Bergmann
2021-03-01 14:21 ` Guenter Roeck
2021-03-04 22:12 ` [PATCH v2 0/3] add "delay" clock support to gpio_wdt Rasmus Villemoes
2021-03-04 22:12 ` [PATCH v2 1/3] clk: add devm_clk_prepare_enable() helper Rasmus Villemoes
2021-03-09 5:28 ` Guenter Roeck
2022-03-05 2:41 ` Dmitry Torokhov
2021-03-04 22:12 ` [PATCH v2 2/3] dt-bindings: watchdog: add optional "delay" clock to gpio-wdt binding Rasmus Villemoes
2021-03-04 22:12 ` [PATCH v2 3/3] watchdog: gpio_wdt: implement support for optional "delay" clock Rasmus Villemoes
2021-03-09 5:51 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c0cd771-6067-69be-9838-9d3ab24a2503@roeck-us.net \
--to=linux@roeck-us.net \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).