On 13 June 2013 12:49, Xiaoguang Chen wrote:
> So you add the return value checking, I was about to do it in another patch :)
What? I couldn't related that statement to my code.
> this patch is simpler than my previous patch, it is ok for me.
> Do I need to submit it again or it can be merged?
2013/6/13 Viresh Kumar :
> On 13 June 2013 11:10, Xiaoguang Chen wrote:
>> 2013/6/12 Viresh Kumar :
>>> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>>>
ret = policy->governor->governor(policy, event);
>>>
>>> We again reached to the same problem. We shouldn't call
>>> this between t
On 13 June 2013 11:10, Xiaoguang Chen wrote:
> 2013/6/12 Viresh Kumar :
>> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>>
>>> ret = policy->governor->governor(policy, event);
>>
>> We again reached to the same problem. We shouldn't call
>> this between taking locks, otherwise recursive l
2013/6/12 Viresh Kumar :
> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>
>> ret = policy->governor->governor(policy, event);
>
> We again reached to the same problem. We shouldn't call
> this between taking locks, otherwise recursive locks problems
> would be seen again.
But this is not
On 12 June 2013 14:39, Xiaoguang Chen wrote:
> ret = policy->governor->governor(policy, event);
We again reached to the same problem. We shouldn't call
this between taking locks, otherwise recursive locks problems
would be seen again.
--
To unsubscribe from this list: send the line "unsu
cpufreq governor stop and start should be kept in sequence.
If not, there will be unexpected behavior, for example:
we have 4 cpus and policy->cpu=cpu0, cpu1/2/3 are linked to cpu0.
the normal sequence is as below:
1) Current governor is userspace, one application tries to set
governor to ondeman
6 matches
Mail list logo
