On 05/26/2015 12:11 PM, Al Stone wrote:
So, this is meant to be SBSA compliant; is it also meant to be SBBR compliant? I suspect not, since there is no ACPI initialization and SBBR requires both UEFI and ACPI. Is there any reason for not being SBBR compliant? I'm not saying this is good or bad; I'm only trying to understand the reasoning.
The driver expects some platform code to read the ACPI tables and initialize a platform device.
I'll also admit that I'm not an expert in ARM timers. Could I ask a really big favor, please? When I read the SBSA (section 5.2, specifically), that implies to me that there are two interrupts: a first interrupt for the timer itself set to go off after the timeout expires, and a second interrupt that is required when the timeout expires to force some "executive action". I only see one IRQ in the patch; what am I missing?
My driver just uses the first interrupt as a software reset. The second reset is treated as a "backup" hardware reset, in case the software reset didn't work.
Fu's driver, which I admit is better at handling this, uses the first interrupt as an optional pre-timeout that can be used for debugging. The second timeout, which is a hardware reset, is the "real" timeout.
Note that the ACPI specification for the watchdog device only allows for one interrupt to be specified. For these drivers, we expect the first interrupt (WS0) to be specified in the ACPI tables. We assume that the second timeout (WS1) will just cause an immediate hardware reset, without an interrupt.
Also, Fu and I have discussed this, and I think it makes sense to pick up his driver instead of mine. So I'm withdrawing my driver.
-- 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 linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
