On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > +Cc: Rafael, ACPI ML > > On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam > <srinath.mannam@xxxxxxxxxxxx> wrote: >> Hi Michael, Stephen, >> >> We are adding ACPI support in our Linux based platform. >> At present our clock hierarchy using common clock framework through DTS. >> Now we required ACPI support in common clock framework to upgrade our platform. >> >> For example, clk_get API called in many drivers to get clock device is >> tightly coupled with DT framework. >> >> Please let us know, if anybody in Open Source community have plans to >> add ACPI support for common clock framework. There are no plans for doing that AFAICS. Moreover, it generally would not be consistent with ACPI power management defined by the specification. >> If not please suggest us alternative method to use common clock >> framework in ACPI use case. The problem with using the clock framework on systems with ACPI is that, in general, the clock manipulation is expected to be carried out by ACPI power management and therefore it is "owned" by AML. Currently, there are no defined methods for synchronizing the AML's use of clocks for power management with what the OS may do with them directly. In theory, that can be worked around to some extent by representing clocks as power resources in ASL (even though the provider information would be missing then) and manipulating those power resources directly from the OS. I'm not aware of anyone doing that successfully, however. For simple power management it should be sufficient to let drivers rely on the ACPI PM domain which should happen automatically in the majority of cases anyway. Thanks, Rafael -- 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
