Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Rafael J. Wysocki
On Wednesday, March 19, 2014 03:39:16 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

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Viresh Kumar
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 write buggy code in their drivers. What kind of b

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Srivatsa S. Bhat
On 03/19/2014 02:50 PM, Viresh Kumar wrote: > On 19 March 2014 14:47, Srivatsa S. Bhat > wrote: >> Wait, I think I remember. The problem was about dealing with drivers that >> do asynchronous notification (those that have the ASYNC_NOTIFICATION flag >> set). In particular, exynos-5440 driver sends

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Srivatsa S. Bhat
On 03/19/2014 11:38 AM, Viresh Kumar wrote: > On 18 March 2014 18:20, Srivatsa S. Bhat > wrote: >> On 03/14/2014 01:13 PM, Viresh Kumar wrote: >>> + if ((state != CPUFREQ_PRECHANGE) && (state != CPUFREQ_POSTCHANGE)) >> >> Wait a min, when is this condition ever true? I mean, what else can >> '

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Viresh Kumar
On 19 March 2014 14:47, Srivatsa S. Bhat wrote: > Wait, I think I remember. The problem was about dealing with drivers that > do asynchronous notification (those that have the ASYNC_NOTIFICATION flag > set). In particular, exynos-5440 driver sends out the POSTCHANGE notification > from a workqueue

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-19 Thread Srivatsa S. Bhat
On 03/19/2014 11:38 AM, Viresh Kumar wrote: > On 18 March 2014 18:20, Srivatsa S. Bhat > wrote: >> On 03/14/2014 01:13 PM, Viresh Kumar wrote: >>> + if ((state != CPUFREQ_PRECHANGE) && (state != CPUFREQ_POSTCHANGE)) >> >> Wait a min, when is this condition ever true? I mean, what else can >> '

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-18 Thread Viresh Kumar
On 18 March 2014 18:20, Srivatsa S. Bhat wrote: > On 03/14/2014 01:13 PM, Viresh Kumar wrote: >> + if ((state != CPUFREQ_PRECHANGE) && (state != CPUFREQ_POSTCHANGE)) > > Wait a min, when is this condition ever true? I mean, what else can > 'state' ever be, apart from CPUFREQ_PRECHANGE and POST

Re: [RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-18 Thread Srivatsa S. Bhat
On 03/14/2014 01:13 PM, Viresh Kumar wrote: > Whenever we are changing frequency of a cpu, we are calling PRECHANGE and > POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE > shouldn't be called twice continuously. Following examples show why this is > important: > [...]

[RFC V2] cpufreq: make sure frequency transitions are serialized

2014-03-14 Thread Viresh Kumar
Whenever we are changing frequency of a cpu, we are calling PRECHANGE and POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE shouldn't be called twice continuously. Following examples show why this is important: Scenario 1: --- One thread reading value of cpuinfo_c