Al Stone wrote:
The issue for me in that case is that the SBSA requires a two stage timeout,
>
>Hmm - really ? This makes me want to step back a bit and re-read the specification
>to understand where it says that, and what the reasoning might be for such a
>requirement.
As far as I can tell, that's what the SBSA is requiring. My understanding is
that the hardware is to first assert a WS0 signal when the timer expires. If
the timer expires and WS0 has already been asserted, the WS1 signal is to be
asserted. When WS1 is asserted, the system is to do a hard reset (Section 5.2,
"Server Base System Architecture", ARM-DEN-0029 Version 2.3). I'm interpreting
the occurrence of WS0 as the first stage and WS1 as the second.
To me, at least, this makes sense in a server environment. The WS0 occurs,
which gives me some time to save key info or try to recover before WS1 occurs
(or kexec, or any other cleverness).
I'm having some problem with the word "requires".
I think it applies only to the hardware. That is, there must be a WS0
timeout/event, and then after that there must be a WS1 timeout/event.
I don't think there is any "requirement" for software to do anything
with WS0. That's why I don't think pre-timeout is necessary for the
driver to be SBSA-compliant. All of the drivers for existing two-stage
watchdog devices treat the device as a one-stage device, because the
watchdog API does not support pre-timeout. Are all of them also
"broken"? No. So it would not be broken for an SBSA watchdog driver to
ignore WS0.
I would have no problem with the following sequence of events:
1) We merge in a driver that treats the SBSA watchdog as a single-stage
watchdog that does a hard reset at WS1 and ignores WS0. My driver, with
a few changes, would qualify.
2) We add support for pre-timeout to the Watchdog interface. Fu can
take all the time in the world (as far as I'm concerned) getting this
perfected. My only request is that the new pre-timeout API supports
hardware where the timeout between stages must be equal. That is, if
timeout to stage 1 (call it T1) is X seconds, then the timeout to stage
2 (call it T2) is another X seconds. T2 = T1. Of course, the API
should also support hardware where T2 != T1.
3) The existing SBSA watchdog driver is updated to support the new
pre-timeout API. It would enforce the requirement that T2 = T1.
This approach will allow us to get a working SBSA watchdog driver into
4.5 without much fuss.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
