On 05/23/2015 10:26 AM, Fu Wei wrote:
Hi Timur,
On 23 May 2015 at 23:08, Timur Tabi timur@codeaurora.org wrote:
Arnd Bergmann wrote:
I think it's a reasonable assumption that someone will sooner or later put that hardware into an ARM32 machine,
I'm going to have to disagree. If they haven't done it by now, I can't imagine any ARM SOC vendor creating a 32-bit ARM SOC with an SBSA watchdog in it. I can imagine a vendor trying to repurpose an existing 32-bit ARM SOC for the server market, but that SOC won't have an SBSA watchdog in it.
I will agree with you on this, ONLY IF a people can represent ARM and all chip vendors say publicly: " We never ever use SBSA watchdog IP core on ARM32!" or " SBSA watchdog IP core is imcompatible with ARM32"
Although the SBSA is all about ARMv8, but in "5 APPENDIX A: GENERIC WATCHDOG", it doesn't say "this is only for ARMv8". and its clock source "system counter" and arm_arch_timer have been in ARM32 Soc for years, and all the regs in SBSA watchdog is 32bit. I can't see why we can not do that, unless I miss something.
I wonder why you are so sure "that SOC won't have an SBSA watchdog in it." any documentation ? Sorry, I am not a chip design engineer, I can't see why 32-bit ARM won't have an SBSA watchdog in it.
I think it is quite unfortunate that the specification is not public. We have heard many statements about what is in the spec or not. We have two possible implementations of the SBSA watchdog, but not even the implementers of those two implementations seem to be able to agree what the specification actually mandates/supports, or what it doesn't mandate/support.
We have heard that the SBSA watchdog would require ACPI, and that it doesn't. We have heard that it would require ARM64, and that it doesn't. We have heard various assumptions about how WS0 and WS1 are supposed to be wired. We have heard that all its registers are 32 bit (which would suggest they have to be treated as such), but then we have a 64 bit register access in one of the drivers, and a more complex implementation to read the same value as two 32-bit reads in the other. We have heard that WS0 and WS1 are at least to some degree independent of each other (and thus that it makes sense to set them separately), and we have heard that WS1 is always equal to WS0 * 2. We have one implementation limiting support to architecture revision 0, and the other not imposing such a restriction.
Is the specification really that vague in such key areas ? How do you expect anyone who doesn't have access to the specification to be able to figure out what is actually correct and how to proceed ?
Thanks, Guenter