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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
