On 19/01/2015 10:22, Amit Kucheria wrote: > On Thu, Jan 15, 2015 at 10:54 PM, Mason wrote: > >> This is a follow-up to my previous thread. >> "How many frequencies would cpufreq optimally like to manage?" >> http://thread.gmane.org/gmane.linux.ports.arm.kernel/373669 >> >> As I originally wrote, I'm running 3.14 on an ARM Cortex-A9 >> based SoC (namely Tango4 from Sigma Designs). I'd like to get >> some feedback on the cpufreq driver I wrote for that platform. >> >> I decided to expose only a small subset of frequencies (namely >> {999,500,333,111} MHz) because, in my tests, the ondemand gov >> chose mostly min and max, and the intermediate frequencies not >> so much; so I figured "2 intermediate freqs" is good enough. >> (I'm ready to hear otherwise.) > > How many states are really enough depends on the main workloads > running on your system. In a closed system (limited number of > applications) you can easily characterise your workloads and see what > operating points (OPP = voltage, frequency pair) the system spends > most of its time in (CPU_FREQ_STAT_DETAILS) and optimize out the > remaining OPPs. Testing with CPU_FREQ_STAT_DETAILS enabled is on my TODO list. Thanks for reminding me! > In an open-ended system where you don't control what applications will > run on the system (e.g. android phone), it is probably a good idea to > expose more OPPs while keeping in mind that exposing 50 frequencies is > probably overkill (and silly) since you're spending more time reaching > the "optimum" OPP. Pick some high-impact ones e.g. ones that allow you > to lower your voltage. The current SoC does not support dynamic voltage scaling at all. So I'm just tweaking the frequency. IIUC, if I divide freq by 4, power should be divided by 4? >> I tried to use as much generic framework as possible, but I've >> read about the clk framework, and it looks to be an even greater >> generalization. Are new platforms encouraged to use that, rather >> than provide a cpufreq driver? Does it work when voltage scaling >> comes in play? (This SoC doesn't have it, but the next will.) >> >> I'm also wondering how cpufreq and cpuidle interact? Is one a >> subset of the other? Are they orthogonal? > > These queries have been answered by Krzysztof. The current SoC does not support any "deep" sleep; I was told that the core just powers "itself" down after a WFI, nothing fancier. Regards. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
