[lkml]   [2018]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ACPI support in common clock framework
On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
<> wrote:
> +Cc: Rafael, ACPI ML
> On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
> <> 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

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,

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.


 \ /
  Last update: 2018-06-13 10:28    [W:0.056 / U:2.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site