On 07-02-19, 14:37, Ulf Hansson wrote: > I think we also need to consider cross SoC drivers. One SoC may have > both clocks and OPPs to manage, while another may have only clocks. We already have that case with CPUs as well and dev_pm_opp_set_rate() takes care of it. > Even it this may be fairly uncommon, we should consider it, before we > decide to fold in additional clock management, like > clk_prepare|unprepare() for example, behind the dev_pm_opp_set_rate() > API. > > The point is, the driver may need to call clk_prepare|enable() > anyways, unless we make that conditional depending on a DT compatible > string, for example. Of course, because the clock prepare/enable is > reference counted, there may not be a problem in practice to have both > the OPP and driver to deal with it. -- viresh
