On 05/26/2015 11:58 AM, Timur Tabi wrote: > 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. Ah. I have to think on that a bit; it sounds reasonable. I guess I was wondering about how the DT usage would work vs the ACPI usage and trying to make them very similar in my head. That may just give me a headache, however. >> 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. Oh, I see. I think I was misunderstanding the SBSA, too; I saw the word "signal" and was thinking that had to be an interrupt, which is not correct. > 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. Right. I think I've got the mapping now. Thanks, that helped clarify things for me. I appreciate the time spent. > 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. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone@xxxxxxxxxx ----------------------------------- -- 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
