On 20 March 2014 15:15, Srivatsa S. Bhat
wrote:
> By the way, I'm also thinking of using a spinlock instead of a mutex.
> The critical section is tiny and we don't sleep inside the critical
> section - sounds like the perfect case for a spinlock.
Probably yes.
--
To unsubscribe from this list: se
On 03/20/2014 03:03 PM, Viresh Kumar wrote:
> On 20 March 2014 14:54, Srivatsa S. Bhat
> wrote:
>> On 03/20/2014 02:07 PM, Viresh Kumar wrote:
>>> WARN_ON(policy->transition_ongoing);
>>>
>>
>> I guess you meant WARN_ON(!policy->transition_ongoing)
>> perhaps?
>
> Ooops!!
>
>> I'm not sure w
On 20 March 2014 14:54, Srivatsa S. Bhat
wrote:
> On 03/20/2014 02:07 PM, Viresh Kumar wrote:
>> WARN_ON(policy->transition_ongoing);
>>
>
> I guess you meant WARN_ON(!policy->transition_ongoing)
> perhaps?
Ooops!!
> I'm not sure whether its really worth it, because it kinda looks
> obvious.
On 03/20/2014 02:07 PM, Viresh Kumar wrote:
> On 20 March 2014 14:02, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 199b52b..5283f10 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -349,6 +349,39 @@ void
On 20 March 2014 14:02, Srivatsa S. Bhat
wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 199b52b..5283f10 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -349,6 +349,39 @@ void cpufreq_notify_post_transition(struct
> cpufreq_poli
On 03/20/2014 10:09 AM, Viresh Kumar wrote:
> On 19 March 2014 17:45, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 199b52b..e90388f 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -349,6 +349,38 @@ void
On 19 March 2014 17:45, Srivatsa S. Bhat
wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 199b52b..e90388f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -349,6 +349,38 @@ void cpufreq_notify_post_transition(struct
> cpufreq_poli
On 03/19/2014 08:18 PM, Srivatsa S. Bhat wrote:
> On 03/19/2014 07:05 PM, Viresh Kumar wrote:
>> On 19 March 2014 17:45, Srivatsa S. Bhat
>> wrote:
>>> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
>>> + booltransition_ongoing; /* Tracks transition
>>> s
On 03/19/2014 07:05 PM, Viresh Kumar wrote:
> On 19 March 2014 17:45, Srivatsa S. Bhat
> wrote:
>> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
>> + booltransition_ongoing; /* Tracks transition
>> status */
>> + struct mutextransition_
On 19 March 2014 17:45, Srivatsa S. Bhat
wrote:
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> + booltransition_ongoing; /* Tracks transition
> status */
> + struct mutextransition_lock;
> + wait_queue_head_t transition_w
On 03/19/2014 03:39 PM, Viresh Kumar wrote:
> On 19 March 2014 15:20, Srivatsa S. Bhat
> wrote:
>> No, its not about burden. Its about the elegance of the design. We should
>> not be overly "smart" in the cpufreq core. Hiding the synchronization inside
>> the cpufreq core only encourages people to
11 matches
Mail list logo
