On 02/23/2014 07:58 PM, Mark Brown wrote: > On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote: > >> The current regulator model provides the basic building blocks for the >> transitions, however SoC drivers specific to each of these devices, be >> it cpufreq/devfreq have to replicate the logic for functionality. > >> To simply the logic, we can hence introduce a layer that takes care >> of the mundane transition logic, registration mechanisms to provide >> the "user drivers" such as cpufreq/devfreq a generic interface, whose >> details are abstracted by the device tree description for the SoC on >> which the driver operates on. > > This doesn't really provide a picture of what the generic interface > that's being offered is and... I should have probably picked up part of the cover letter[1] and elaborated further in the commit message here. Intent here is to allow drivers such as cpufreq-cpu0 to be reused on platforms such as TI's OMAP derivatives, and other SoCs which differ only by the sequence involved in voltage scale operations. So, this patch provides a framework for registering the underlying implementation of the SoC specific voltage change methodology. Overall the sequence takes place after this patch is as follows: a) voltage domain drivers such as those of TI or others register with voltage domain with devm_voltdm_register. b) cpufreq-cpu0/devfreq drivers: of_pm_voltdm_notifier_register(introduced as part of patch #1) to register notifiers around clk of interest. This request is linked to the specific voltage domain using phandle in device tree. c) when cpufreq-cpu0/devfreq does a clk_set_rate, the common clock framework triggers notifiers in voltage domain core which in turn, invokes the corresponding handlers for the voltage domain driver ensuring the right dvfs sequence specific to the SoC is triggered. With this patch, the logic for a SoC specific voltage domain intricacies can now be abstracted out to the voltage domain layer. This allows reuse of the logic by multiple drivers such as devfreq/cpufreq and allows these to remain consistent with very minimal SoC(if any at all) specific implementations in them. Among the other obvious alternatives to this approach are: a) To duplicate the logic multiple times for various drivers such as devfreq/cpufreq and try to ensure the logic sequences are proper. basically, create cpufreq-abb-omap, cpufreq-avs-omap, devfreq-abb-omap, devfreq-avs-omap etc.. b) introduce a specific API for voltage change (something like pm_dev_scale_opp_frequency or the equivalent). > >> drivers/power/voltdm/Kconfig | 5 + >> drivers/power/voltdm/Makefile | 3 + >> drivers/power/voltdm/core.c | 347 +++++++++++++++++++++++-- >> drivers/power/voltdm/voltage_domain_private.h | 86 ++++++ >> 4 files changed, 424 insertions(+), 17 deletions(-) > > ...the diffstat doesn't make it obvious what the external interface is > either. It would be much easier to review this with a clearer picture > of what it's aiming to implement. The drivers such as cpufreq/devfreq has the same interface introduced by patch #1 in this series of_pm_voltdm_notifier_register/unregister which is exposed by include/linux/pm_voltage_domain.h Underlying implementation of the SoC specific voltage change methodology can now be isolated by voltage domain driver using voltage_domain_private.h and services provided by core.c > >> + voltdm_np = of_parse_phandle(np, prop_name, 0); >> + if (voltdm_np) { >> + ret = of_parse_phandle_with_args(np, prop_name, "#voltdm-cells", >> + 0, args); >> + if (ret) >> + return ERR_PTR(ret); > > There seems to be some DT stuff going on here, is the interface DT only? > yes. i will make that clear in the documentation. [1] http://marc.info/?l=linux-kernel&m=139275560531711&w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html