[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gA76NwwgRnuztY+dUOKXS+__-7Ghw7Azb-84h_eMRt4w@mail.gmail.com>
Date: Sat, 16 Jun 2018 17:50:18 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Stephen Boyd <sboyd@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Srinath Mannam <srinath.mannam@...adcom.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Michael Turquette <mturquette@...libre.com>,
linux-clk <linux-clk@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: ACPI support in common clock framework
On Fri, Jun 15, 2018 at 7:43 PM, Stephen Boyd <sboyd@...nel.org> wrote:
> Quoting Rafael J. Wysocki (2018-06-13 01:27:39)
>> On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
>> <andy.shevchenko@...il.com> wrote:
>> > +Cc: Rafael, ACPI ML
>> >
>> > On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
>> > <srinath.mannam@...adcom.com> 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.
>
> This matches my understanding.
>
>>
>> >> 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.
>>
>
> Is this for clk_enable/disable? What about clk_set_rate() or
> clk_set_phase()? Is ACPI's AML taking care of that?
That's for clk_enable/disable AFAICS.
AML doesn't manage device performance states at all.
Powered by blists - more mailing lists