[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <914341e7-ca94-054d-6127-522b745006b4@arm.com>
Date: Mon, 25 Jun 2018 18:15:45 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Stephen Boyd <sboyd@...nel.org>,
Srinath Mannam <srinath.mannam@...adcom.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Sudeep Holla <sudeep.holla@....com>,
Andy Shevchenko <andy.shevchenko@...il.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 25/06/18 17:37, Stephen Boyd wrote:
> Quoting Rafael J. Wysocki (2018-06-16 08:50:18)
>> On Fri, Jun 15, 2018 at 7:43 PM, Stephen Boyd <sboyd@...nel.org> wrote:
>>>
>>> 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.
>
> Alright. We may need to add a better way for device drivers to get
> handles to clk pointers on ACPI firmware so they can change frequencies
> or phase, etc.
Is there any specific usecase/device needing this in the kernel ? SPI
slaves ?
> Right now it's all through clkdev and it looks to be
> mostly based on string matching of connection names instead of
> associating clks with devices.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Sudeep
Powered by blists - more mailing lists