On 12/18/14, 12:04 AM, Jon Masters wrote:
On 12/16/14, 7:37 PM, Al Stone wrote:
On 12/16/2014 08:48 AM, Mark Rutland wrote:
I am rather concerned about the relationship between items described with _DSD and ACPI's existing device model. Describing the relationship between devices and their input clocks, regulators, and so on defeats much of the benefit ACPI is marketed as providing w.r.t. abstraction of the underlying platform (and as Arnd mentioned above, that's not the kind of platform we want to support with ACPI).
My belief is that all those things should be set up into a known good state by UEFI on initial boot.
Correct. There should never be a situation in which any clocks are explicitly exposed in the DSDT. Clock state should be set as a side effect of calling ACPI methods to transition device state. _DSD is intended to implement simple additions to the core spec, such as metadata describing the MAC address, interface type, and PHY on a network device. But it should never be used to expose clock nets.
I've spoken with nearly everyone building a 64-bit ARM server using ACPI and in nearly every case also reviewed their tables. Nobody is going to be so foolish on day one. The trick to some of the ongoing discussion/planning is to ensure that guidance prevents mistakes later.
Btw a little clarification. RH of course has commercial relations with many of those building first/second/third generation 64-bit ARM server designs. In that capacity we have reviewed nearly every SoC design as well as the firmware platform (including ACPI tables). We have a vested interest in ensuring that nobody builds anything that is crazy, and we're not the only OS vendor that is working to ensure such sanity.
Jon.