On 05/24/2013 11:13 AM, Viresh Kumar wrote: > On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: >> I agree with Viresh, a new governor is not necessary here for that. > > Their patchset had two parts.. One is LAB and other is overclocking. > We are trying to solve overclocking for which they never wanted a > new governor. :) > >> There is the /sys/devices/system/cpufreq/boost option existing for x86 >> platform, why do not reuse it ? It is supposed to do exactly what you >> want to achieve. > > The problem is that it was added at the wrong place.. It should have > been at cpu/cpuX/cpufreq/boost... Yes, I saw in the commit log (615b7300717b9ad5c23d1f391843484fe30f6c12), that should be done. > Consider how will we achieve it for big LITTLE.. We know we can > go to overdrive only for a single core in big but for two cores in > LITTLE at the same time.. So, we need that in the location I just > mentioned... I thought the constraints should be hardcoded in the driver and only one option is exposed to the userspace. If the user sets ondemand|performance + boost, then the exynos's or b.L's drivers know when they can go to boost (1x core, 1x big core, 2x little core, ...). > Over that.. I believe it is governor specific too.. It shouldn't be part > of conservative as it should be conservative rather then aggressive :) Yes, it is part of the governor policy and maybe that could fall in the common cpufreq framework. >> IMO, the logic of boosting one core when the other are idle should be in >> the driver itself and certainly not setup by the user, except if we >> consider acceptable the user can burn its board ... :) > > I didn't get it completely.. So, with the options I gave user can only > say.. boost if required and only when few cores are active. User > can't just set max freq continuously if he wishes.. Ok, may be I misunderstood. You suggested to define 'overdrive_cores' where the user can setup when to overdrive a core. If the user set an incorrect value, IIUC, the thermal value can go beyond the thermal limit and break the board. I am just worried this option is dangerous. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- 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
