On Thu, 11 Jul 2024 at 15:16, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 11-07-24, 13:05, Ulf Hansson wrote: > > On Thu, 11 Jul 2024 at 12:31, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > > > On Thu, 11 Jul 2024 at 05:13, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > > > > > > On 10-07-24, 15:51, Ulf Hansson wrote: > > > > > I think this should work, but in this case we seem to need a similar > > > > > thing for dev_pm_opp_set_rate(). > > > > > > > > We don't go to that path for genpd's I recall. Do we ? For genpd's, > > > > since there is no freq, we always call _set_opp(). > > > > > > You are right! Although, maybe it's still preferred to do it in > > > _set_opp() as it looks like the code would be more consistent? No? > > Since the function already accepted a flag, it was very easier to just reuse it > without. > > > No matter how we do this, we end up enforcing OPPs for genpds. > > > > It means that we may be requesting the same performance-level that we > > have already requested for the device. Of course genpd manages this, > > but it just seems a bit in-efficient to mee. Or maybe this isn't a big > > deal as consumer drivers should end up doing this anyway? > > Normally I won't expect a consumer driver to do this check and so was the > opp core handling that. But for genpd's we need to make this inefficient to not > miss a vote. > > The problem is at another level though. Normally for any other device, like CPU, > there is one vote for the entire range of devices supported by the OPP table. > For example all CPUs of a cluster will share an OPP table (and they do dvfs > together), and you call set_opp() for any of the CPU, we will go and change the > OPP. There is no per-device vote. > > This whole design is broken in case of genpd, since you are expecting a separate > vote per device. Ideally, each device should have had its own copy of the OPP > table, but it is messy in case of genpd and to make it all work nicely, we may > have to choose this inefficient way of doing it :( Right, I get your point. Although, it seems to me that just limiting required-opps to performance-levels, could avoid us from having to enforce the OPPs for genpd. In other words, doing something along the lines of $subject patch should work fine. In fact, it looks to me that the required-opps handling for the *single* PM domain case, is already limited to solely performance-levels (opp-level), as there are no required_devs being assigned for it. Or did I get that wrong? Kind regards Uffe
