linux-kernel - Re: ACPI support in common clock framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABe79T6tnWjCZkHgoO+qfHbtTvevPFH_KE6+XsvCa6cKAbVJjg@mail.gmail.com>
Date:   Tue, 26 Jun 2018 14:29:27 +0530
From:   Srinath Mannam <srinath.mannam@...adcom.com>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        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

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 <sboyd@...nel.org> 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 <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 ?
>
> 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.
>