On 9 November 2013 00:59, Stratos Karafotis wrote:
> I removed the check you proposed in this commit 934dac1ea072 to avoid
> the duplicate check in cs_check_cpu and in dbs_cpufreq_notifier.
>
> I agree that we don't need dbs_cpufreq_notifier if we transfer checks in
> cs_check_cpu. But I'm not 100
On Fri, Nov 8, 2013 at 8:16 PM, Viresh Kumar wrote:
> On 8 November 2013 23:13, Stratos Karafotis wrote:
>> Please let me rephrase my previous post. In some circumstances (depending
>> on freq_step and freq_table values) CPU frequency will never reach to
>> policy->max.
>>
>> For example suppose
On 8 November 2013 23:13, Stratos Karafotis wrote:
> Please let me rephrase my previous post. In some circumstances (depending
> on freq_step and freq_table values) CPU frequency will never reach to
> policy->max.
>
> For example suppose that (for simplicity values in MHz):
> policy->max = 1000
>
On Fri, Nov 8, 2013 at 6:55 AM, Viresh Kumar wrote:
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if the requested_freq is greater
>> than policy->max in __cpufreq_driver_target.
>
> Yes it does. But the problem is:
> - cs_check_cpu() sets reques
2013/11/8 Viresh Kumar :
> On 8 November 2013 10:31, Xiaoguang Chen wrote:
>> Hi, Viresh, Sorry for the late reply.
>
> That's fine :)
>
>> I'll prepare the patch.
>
> Thanks.
>
>> BTW, do you think we should set requeste_freq to policy->max when such
>> condition happens?
>
> I thought about that
On 8 November 2013 10:31, Xiaoguang Chen wrote:
> Hi, Viresh, Sorry for the late reply.
That's fine :)
> I'll prepare the patch.
Thanks.
> BTW, do you think we should set requeste_freq to policy->max when such
> condition happens?
I thought about that earlier, but then thought this would be a
Hi, Viresh, Sorry for the late reply.
I'll prepare the patch.
BTW, do you think we should set requeste_freq to policy->max when such
condition happens?
Thanks
Xiaoguang
2013/11/8 Viresh Kumar :
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if th
On 8 November 2013 00:36, Stratos Karafotis wrote:
> I think the existing code already checks if the requested_freq is greater
> than policy->max in __cpufreq_driver_target.
Yes it does. But the problem is:
- cs_check_cpu() sets requested_freq above policy->max
- We execute following code because
On 8 November 2013 00:27, Rafael J. Wysocki wrote:
> On Thursday, November 07, 2013 10:39:38 AM Viresh Kumar wrote:
>> We need another patch for fixing the other part of code where we
>> increase freq..
>> We need to replace:
>>
>> if (dbs_info->requested_freq == policy->max)
>> return;
>>
>>
On Thursday, November 07, 2013 10:39:38 AM Viresh Kumar wrote:
> On 7 November 2013 07:58, Xiaoguang Chen wrote:
> > When decreasing frequency, requested_freq may be less than
> > freq_target, So requested_freq minus freq_target may be negative,
> > But reqested_freq's unit is unsigned int, then t
On 7 November 2013 07:58, Xiaoguang Chen wrote:
> When decreasing frequency, requested_freq may be less than
> freq_target, So requested_freq minus freq_target may be negative,
> But reqested_freq's unit is unsigned int, then the negative result
> will be one larger interger which may be even high
When decreasing frequency, requested_freq may be less than
freq_target, So requested_freq minus freq_target may be negative,
But reqested_freq's unit is unsigned int, then the negative result
will be one larger interger which may be even higher than
requested_freq.
This patch is to fix such issue.
12 matches
Mail list logo
