On Fri, 8 Feb 2019 at 08:17, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > 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. I think you may have misunderstood my point. Or maybe I don't get yours. :-) What if there is no OPP at all to use, then dev_pm_opp_set_rate() is just a noop, right? In this scenario the driver still need to call clk_set_rate(). How do we cope with these cases? > > > 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. > Kind regards Uffe
