On 05/23/2015 11:37 AM, Timur Tabi wrote:
Guenter Roeck wrote:
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.
All you need to do is go to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029b/index.html, get a free ARM account, and download the spec.
That helps - thanks a lot!
Folks, please correct me if my understanding of the specification
is wrong.
1) Pretimeout
The document suggests that
WS1 = WS0 * 2
is in fact correct. In essence, there is just one counter,
not two. This means that a separate pretimeout does not really
make sense, since in practice the timeout would always be
twice the pretimeout, and changing just one without affecting
the other is not really possible.
2) 64 bit WCV register
The specification is not clear on how to read this register.
It clearly states that it is comprised of two 32-bit registers,
but it does not specify if a single 64-bit read would be atomic,
or if it would be split into two separate 32-bit operations.
This leaves room for interpretation by the implementer, and
may result in bad values if the implementation changes the
counter from, say, 0x000010000 to 0x0000ffff while the value
is read.
My interpretation of this is that it would be safer to read two
32-bit values and ensure that the values are consistent
instead of relying on the assumption that a single 64-bit read
would be atomic.
3) ACPI vs. FDT
The specification does not say anything about ACPI or FDT support
except that it assumes that there are "System description data
structures such as ACPI or FDT". Given that, the driver should
support both.
4) ARM vs. ARM64
SBSA clearly states that any CPU supporting it shall be ARM v8
compliant (4.1.1, CPU architecture). Personally I think the
discussion around supporting the driver on ARM/ARM64 or ARM64
only is a bit pointless, especially since being able to build
it on ARM doesn't really hurt, even though there is currently
no HW supporting it.
Overall I must admit that I don't really understand why this is
such a contentious issue.
5) Revision support
While it is difficult to predict the future, it is common practice
in the industry to make future revisions of a standard (and chip)
as much backward compatible as possible, and to only add functionality.
As such, I don't see a reason to restrict support to revision 0
of the standard.
6) A note about driver messages
Implementation defined registers are just that, implementation
defined registers. I don't think it makes sense to display any
of those, not even for debugging purposes.
---
Again, please correct me if any of those statements is wrong.
When doing so, please reference the specification, to make sure
that we all know what we are talking about.
My hope is that we can use this as a starting point to converge
on a single driver.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
