lkml.org 
[lkml]   [2013]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results
From
On 24 May 2013 15:58, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 05/24/2013 11:13 AM, Viresh Kumar wrote:

>> 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, ...).

Cpufreq Drivers don't take a decision on cpu frequency. They just provide
a mechanism to cpufreq core.. Decision must come from governor all the
time.

>> 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.

Yes.. if we set 4 at that place.. 4 cores may run together in overdrive
mode. And that is risky :) ... Maybe a max limit from driver will be another
option along with this.


\
 
 \ /
  Last update: 2013-05-24 13:01    [W:0.068 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site