On Thu, 21 Nov 2013 11:31:10 -0800, Olof Johansson <olof@xxxxxxxxx> wrote: > On Thu, Nov 21, 2013 at 11:01 AM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > On Thu, Nov 21, 2013 at 10:59:41AM -0800, Olof Johansson wrote: > >> On Thu, Nov 21, 2013 at 10:54 AM, Russell King - ARM Linux > >> <linux@xxxxxxxxxxxxxxxx> wrote: > >> > This depends what you want from ACPI, and what market ACPI is being > >> > targetted at. > >> > >> We're talking ACPI on servers here. > > > > Now read the rest of my email, thanks. > > Yes, there are use cases for ACPI on embedded, which is what Intel is > getting into and the standard is changing accordingly. On embedded ARM > we're quite comfortable with DT for now, so it doesn't make sense to > consider ACPI there just for the sake of it, as far as I am concerned. > > And, on servers, using the embedded-targeted bindings that expose all > hardware details (and leaving implementation to the kernel) seems > counter to the main target of forwards- and backwards compatibility. > That can only really be achieved by getting rid of hardware diversity > and reaching standardized hardware platforms with discoverable > devices. Keeping the complex parts of power management out of the > kernel on those platforms is going to be important too. That is something that can definitely push back on. We've got the collision of what have we been required to do for embedded SoCs with technology designed for systems that aren't quite as much "fun". The ACPI team has been investigating what is needed to port existing device drivers to use ACPI bindings, but it is resonable to say that clocks and regulators (for example) have no business being described in the ACPI tree. g. -- 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
