On 05/23/2015 10:26 AM, Fu Wei wrote:
Hi Timur,
On 23 May 2015 at 23:08, Timur Tabi <timur@xxxxxxxxxxxxxx> 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
--
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
