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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
