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.
If not please suggest us alternative method to use common clock
framework in ACPI use case.
Thanks in advance.
Regards,
Srinath.
+Cc: Rafael, ACPI ML
On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
<[email protected]> 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.
> If not please suggest us alternative method to use common clock
> framework in ACPI use case.
>
> Thanks in advance.
>
> Regards,
> Srinath.
--
With Best Regards,
Andy Shevchenko
On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
<[email protected]> wrote:
> +Cc: Rafael, ACPI ML
>
> On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
> <[email protected]> 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
Thank you Andy,
Regards,
Srinath.
On Wed, Jun 13, 2018 at 1:43 PM, Andy Shevchenko
<[email protected]> wrote:
> +Cc: Rafael, ACPI ML
>
> On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
> <[email protected]> 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.
>> If not please suggest us alternative method to use common clock
>> framework in ACPI use case.
>>
>> Thanks in advance.
>>
>> Regards,
>> Srinath.
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
On 2018-06-14 06:58, Srinath Mannam wrote:
> Thank you Andy,
>
> Regards,
> Srinath.
>
> On Wed, Jun 13, 2018 at 1:43 PM, Andy Shevchenko
> <[email protected]> wrote:
>> +Cc: Rafael, ACPI ML
>>
>> On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
>> <[email protected]> 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.
>>> If not please suggest us alternative method to use common clock
>>> framework in ACPI use case.
Are you hooking up clk apis to PS0/PS3 calls?
Clk api didn't play nice with acpi until now.
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Srinath.
>>
>>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Rafael J. Wysocki (2018-06-13 01:27:39)
> On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
> <[email protected]> wrote:
> > +Cc: Rafael, ACPI ML
> >
> > On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
> > <[email protected]> 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?
On Fri, Jun 15, 2018 at 7:43 PM, Stephen Boyd <[email protected]> wrote:
> Quoting Rafael J. Wysocki (2018-06-13 01:27:39)
>> On Wed, Jun 13, 2018 at 10:13 AM, Andy Shevchenko
>> <[email protected]> wrote:
>> > +Cc: Rafael, ACPI ML
>> >
>> > On Wed, Jun 13, 2018 at 7:14 AM, Srinath Mannam
>> > <[email protected]> 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.
Quoting Rafael J. Wysocki (2018-06-16 08:50:18)
> On Fri, Jun 15, 2018 at 7:43 PM, Stephen Boyd <[email protected]> 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. 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.
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Sudeep
Quoting Sudeep Holla (2018-06-25 10:15:45)
>
>
> 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 <[email protected]> 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 ?
Mark Brown has been pushing x86 folks to use clk framework for audio
drivers in ASoC. I haven't seen other uses besides that really.
Hi Rafael, Stephen,
Thank you so much for detailed inputs.
In our platform, all HW clocks are accessed (enable/disable/set rate)
in Linux through common clock framework (drivers/clk/) using clock
nodes exported by device tree.
To manage our HW clocks operations (enable/disable/set rate) we have
driver in common clock framework (clk-iproc-pll.c, clk-sr.c).
At present, clock drivers get properties information from device tree framework.
Also many devices to access (enable/disable/set rate) its clock source
in their driver. it must call clk_get function and clocks phandler in
its device tree node.
It means, common clock framework is tightly coupled with device tree framework.
We want to upgrade our platforms to ACPI support in the place of
device tree support.
So that we need to have ACPI support in common clock framework, to
modify our HW clock drivers.
At the same time we also configure few clocks as "fixed-factor-clock".
so fixed-factor-clock also need ACPI support.
These are all the reasons insists to have ACPI support in common clock
framework.
Ex: SP805 watch dog used in our platform whose driver is register as
AMBA device.
In this case both apb_pclk and watch dog clock devices get (clk_get
API) through device tree APIs.
AMBA framework has ACPI support. so probe function of sp805_wdt driver
is called. But failed with clk_get API
because common clock does not have ACPI support.
I thought a solution to upgrade ACPI support in common clock
framework, in the similar way we have ACPI support in normal device
drivers using DSDT ACPI tables.
DSDT table of all devices including clock devices contain all resource
specific information of device and clock device name.
Need to implement similar APIs like of_clk* for ACPI purpose also to
get clock device in driver software.
Ex:
of_clk_src_simple_get
of_clk_hw_simple_get
of_clk_src_onecell_get
of_clk_hw_onecell_get
of_clk_add_provider
of_clk_add_hw_provider
of_clk_del_provider
of_clk_get_from_provider
of_clk_get_parent_count
of_clk_get_parent_name
of_clk_parent_fill
With this approach no dependency on AML to provide clock rate, enable,
disable. It is like translating device tree into ACPI.
Please provide your inputs.
Regards,
Srinath.
On Tue, Jun 26, 2018 at 5:07 AM, Stephen Boyd <[email protected]> wrote:
> Quoting Sudeep Holla (2018-06-25 10:15:45)
>>
>>
>> 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 <[email protected]> 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 ?
>
> Mark Brown has been pushing x86 folks to use clk framework for audio
> drivers in ASoC. I haven't seen other uses besides that really.
>
On Tue, Jun 26, 2018 at 2:37 AM, Stephen Boyd <[email protected]> wrote:
> Quoting Sudeep Holla (2018-06-25 10:15:45)
>>
>>
>> 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 <[email protected]> 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 ?
>
> Mark Brown has been pushing x86 folks to use clk framework for audio
> drivers in ASoC. I haven't seen other uses besides that really.
All LPSS code based on fixed rate clocks created by some platform
code. Since we have no board files for modern x86 platforms the clock
providers and consumers often are located in the same / adjoining
drivers.
--
With Best Regards,
Andy Shevchenko