On 17 December 2014 at 00:37, Al Stone al.stone@linaro.org wrote:
I have not seen good guidelines on the usage of _DSD in that respect, and I'm worried we'll end up with clock controllers half-owned by AML and half-owned by the kernel's clock framework, and this separation varying from board to board (and FW revision to FW revision). I think that needs to be clarified at the ACPI spec level in addition to anything we have in the kernel documentation.
Hrm. The spec (section 6.2.5) basically says that there exists a thing called _DSD and that when invoked, it returns a UUID followed by a data structure. A separate document (on http://www.uefi.org/acpi) for each UUID defines the data structure it corresponds to. The only one defined so far is for device properties:
http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-...
I think you are suggesting good guidelines for both, yes? The usage of new UUIDs and data structures, along with the usage of device properties for the UUID we have, right? I've been trying to write such a thing but all I've accomplished so far is throwing away a couple of drafts that got ugly. I'll keep at it, though.
Of course the way the spec is written also gives us the option, if the OEMs and kernel guys and MS all agree on a different format for aarch64 then all that is needed is a new UUID and we are no longer tied to trying to insert DT into ACPI. I personally think this is the way to go, I do not like the blindly copying DT into ACPI. I suspect the information that a ACPI platform "needs" is probably significantly simplified compared to some of the DT bindings.
Graeme