>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch series adds a generic devfreq governor that can >listen to the frequency transitions of each CPU frequency domain and then >adjusts the frequency of the cache (or any devfreq device) based on the >frequency of the CPUs. I agree that we have some hardware pieces that want to configure frequencies based on the CPUfreq. Creating a devfreq governor that configures devfreq-freq based on incoming events (CPUFreq-transition-event in this case) is indeed a good idea. However, I would like to ask the followings: The overall code appears to be overly complex compared what you need. - Do you really need to revive "CPUFREQ POLICY" events for this? especially when you are going to look at "first CPU" only? Cheers, MyungJoo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
