On 24-06-19, 22:29, Saravana Kannan wrote: > No, the CPUs will be the "parent" and the cache will be the "child". > CPU is a special case when it comes to the actual software (not DT) as > we'll need the devfreq governor to look at all the CPUfreq policies to > decide the cache frequency (max of all their requirements). > > I think "master" and "slave" would have been a better term as the > master device determines its frequency using whatever means and the > "slave" device just "follows" the master device.
Okay, so to confirm again this is what we will have: - CPUs are called masters and Caches are slaves. - The devfreq governor we are talking about takes care of changing frequency of caches (slaves) and chooses a target frequency for caches based on what the masters are running at. - The CPUs OPP nodes will have required-opps property and will be pointing to the caches OPP nodes. The CPUs may already be using required-opps node for PM domain performance state thing. Now the problem is "required-opp" means something really *required* and it is not optional. Like a specific voltage level before we can switch to a particular frequency. And this is how I have though of it until now. And this shouldn't be handled asynchronously, i.e. required OPPs must be set while configuring OPP of a device. So, when a CPU changes frequency, we must change the performance state of PM domain and change frequency/bw of the cache synchronously. And in such a case "required-opps" can be a very good fit for this use case. But with what you are trying to do it is no longer required-opp but good-to-have-opp. And that worries me. -- viresh
