Re: [RFC 0/2] Proposal for Watchdog Timer Resolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/29/2013 01:20 PM, Markus Mayer wrote:
I would like to propose the following extension to the watchdog
framework to allow userland programs access to the resolution of the
watchdog timer should the hardware support such a feature. The first
driver to make use of this feature would be the BCM Kona watchdog
driver.

I would also like to propose introducing a sysfs interface to the
watchdog framework in a later phase of updating the watchdog framework.
The sysfs interface would exist in addition to the existing ioctl
interface. In the future, the ioctl interface could be deprecated in
favour of the sysfs interface or both interfaces could be kept
indefinitely.

Phase 1:

Add get resolution/set resolution ioctls.

Hi Markus,

I am not entirely sure I understand the rationale for this one, or if it is really
valuable for the user.

One example where a resolution might be applicable is the w83627hf_wdt.c driver.
The Winbond/Nuvoton chips support watchdog timeouts either in seconds or in
minutes, based on some configuration register. Currently the driver supports
only seconds (1..255). I had thought about extending it to minutes, but my
approach would have been to automatically select minutes-based timeouts if the
requested timeout is too large (> 255 seconds).

The same approach should be possible for the bcm_kona driver as well; just select
the optimal resolution based on the requested timeout. I think this would make more
sense than manual configuration from a user perspective, to keep the API as simple
as possible while supporting a wide range of timeouts.

On a side note, I don't think you specify anywhere what "resolution" actually means;
it is just a number which, as far as I can see, does not seem to resemble a specific
time. In the case of the bcm_kona driver, it appears to be that values of 0..15 map
to 30us .. 1s in reverse order, which translates to a maximum timeout of anywhere
between 32s and about 12 days.

Based on this, you could set the maximum permitted timeout for the driver to 12 days
or 748800 seconds (or , and then calculate the required resolution from the actually
selected timeout.

Example:
	requested timeout: 24 x 3600 = 86400 seconds, ie 1 day
	Required resolution: 86400 s / 0xfffff = 82.4 ms ==> resolution = 3.

On the other side, I am not sure if all this complexity is really needed.
Even at maximum resolution of 1s you can always provide the remaining timeout
exactly down to the second to the user, which is the granularity provided
by the watchdog subsystem. So, if you want to be able to support 12-day
timeouts, why don't you just set the resolution to the maximum supported ?

Add necessary flags and call-back functions.
Extend bcm_kona_wdt.c to make use of the new functionality.

Phase 2:

Abstract the ioctl interface (into watchdog_ioctl.c) with a new set of
per-driver ops, similar to what other frameworks are already doing.

Phase 3:

Introduce a sysfs interface (watchdog_sysfs.c) hooking into the already
established per-driver ops. ioctl and sysfs calls would use the same
framework and driver functions, requiring no code duplication.

Please let me know if this sounds sensible or whether an alternate
approach would be preferred.

I would like to see a sysfs interface, so I would like to see phase 3.
I'd have to see a patch set for phase 2; not really sure what this entails.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux