From: Pavel Machek <pavel@ucw.cz>
To: "Ильяс Гасанов" <torso.nafi@gmail.com>
Cc: linux-gpio@vger.kernel.org, linux-leds@vger.kernel.org,
linux-watchdog@vger.kernel.org,
Guenter Roeck <linux@roeck-us.net>,
Wim Van Sebroeck <wim@iguana.be>
Subject: Re: A case of watchdog+LED shared GPIO pin
Date: Sun, 4 Mar 2018 20:19:34 +0100 [thread overview]
Message-ID: <20180304191934.GA14207@amd> (raw)
In-Reply-To: <CAEo2pztutpwd0wvJWVmQ2XaT43nQ99StFbDMT7MQ5dkrMdkJvw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
Hi!
> We (the development team at my current employer company) are having a
> specific case of hardware configuraton. Namely, the same GPIO pin is
> used for both watchdog keepalive signaling and status LED blinking.
> The thing is, there are multiple blinking frequency modes for this
> LED, each with its own meaning (i.e. system/firmware states), so
> there's a need for changing the frequency/period dynamically from
> userspace.
>
> Previously I've done the thing implementing the timer period
> configuration by updating a special sysfs file with new values in the
> gpio_wdt driver. However since recently (commit 03bca15 in the kernel
> Git repo) the timer has been swapped out with the keepalive callback
> thing, which, as far as I can tell, supports updating the timeout
> period via the WDIOC_SETTIMEOUT ioctl. However this ioctl is
> insufficient for our purposes, in the sense that its minimum
> resolution is 1 whole second, while we need a 100 millisecond
> granularity at the very most.
>
> I could also simply disable the gpio_wdt altogether and just use a LED
> trigger driven configuration, but I highly doubt this would be a wise
> thing, since the whole point of the watchdog is monitoring
> responsiveness of the userspace. Also I gather that controlling the
> GPIO entirely from a userspace process is rather undesirable, too, as
> it might lead to confusing latencies sometimes, for a start.
>
> I'd like to hear your opinions on the preferred way(s) of implementing
> this for our product hardware on the most recent kernels, which could
> be sent to upstream to secure further backwards compatibility.
Improving WDIOC_SETTIMEOUT is obvious solution. I'd go for that.
But actually, controlling GPIO entirely from userspace should work
well, too. User is not going to notice the jitter in miliseconds...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-03-04 19:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-04 16:26 A case of watchdog+LED shared GPIO pin Ильяс Гасанов
2018-03-04 19:19 ` Pavel Machek [this message]
2018-03-04 19:45 ` Ильяс Гасанов
2018-03-04 19:53 ` Pavel Machek
2018-03-07 20:02 ` Guenter Roeck
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=20180304191934.GA14207@amd \
--to=pavel@ucw.cz \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=torso.nafi@gmail.com \
--cc=wim@iguana.be \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.