"Menon, Nishanth" <[email protected]> writes:

> On Fri, Jun 3, 2011 at 07:16, Santosh Shilimkar
> <[email protected]> wrote:
>> Current OMAP2PLUS CPUfreq tagret() functions returns when all
>> the CPU's are not online. This breaks CPUfreq when secondary CPUs
>> are offlined on SMP system.
>>
>> The intention of that check was just avoid CPU frequency change
>> during the window when CPU becomes online but it's cpufreq_init is
>> not done yet. Otherwise it can lead to notifiers being sent on
>> a CPU which is not yet registered to the governor.
>>
>> But this race conditions is already managed by the CPUfreq
>> core driver by updating the available cpumask accordingly.
>>
>> OMAP CPUFReq driver make use same cpumask for the notifiers
>> so the above problem doesn't exist. In my initial implementation
>> of the OMAP4 CPUFreq driver, I was using 'for_each_online_cpu()'
>> for notifiers which lead me to add that check. Later I fixed
>> the notifies but didn't realise that the check has become
>> redundant then.
>>
>> Fix it by removing the superfluous check in target().
>>
>> Thanks for Nishant Menon <[email protected]> for reporting issue
>> with hot-plug and Kevin Hilman <[email protected]> for his
>> comment on excessive check in target().
>>
>> Signed-off-by: Santosh Shilimkar <[email protected]>
>> Reported-by: Nishanth Menon <[email protected]>
>> Tested-by: Vishwanath BS <[email protected]>
>> Cc: Kevin Hilman <[email protected]>
>
> Tested-by: Nishanth Menon <[email protected]>

Thanks, applied to pm-wip/cpufreq

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to