[PATCH 4/7] powerpc/85xx: add support to JOG feature using cpufreq interface

[Scott Wood]

On 11/07/2011 04:27 AM, Zhao Chenhui wrote:
> On Fri, Nov 04, 2011 at 02:42:54PM -0500, Scott Wood wrote:
>> On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
>>> +	cpufreq_frequency_table_target(policy,
>>> +				       mpc85xx_freqs,
>>> +				       target_freq,
>>> +				       relation,
>>> +				       &new);
>>> +
>>> +	freqs.old = policy->cur;
>>> +	freqs.new = mpc85xx_freqs[new].frequency;
>>> +	freqs.cpu = policy->cpu;
>>> +
>>> +	mutex_lock(&mpc85xx_switch_mutex);
>>> +	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
>>> +
>>> +	pr_info("Setting frequency for core %d to %d kHz, " \
>>> +		 "PLL ratio is %d/2\n",
>>> +		 policy->cpu,
>>> +		 mpc85xx_freqs[new].frequency,
>>> +		 mpc85xx_freqs[new].index);
>>> +
>>> +	set_pll(mpc85xx_freqs[new].index, policy->cpu);
>>> +
>>> +	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
>>> +	mutex_unlock(&mpc85xx_switch_mutex);
>>> +
>>> +	ppc_proc_freq = freqs.new * 1000ul;
>>
>> ppc_proc_freq is global -- can CPUs not have their frequencies adjusted
>> separately?
>>
>> It should be under the lock, if the lock is needed at all.
>>
> 
> There is only one ppc_proc_freq. no lock.

I realize there's only one.

I'm asking whether CPUs can have their frequencies set indpendently --
if the answer is no, and this function is not specific to a CPU, my only
concern is the lock.  Either this function can be called multiple times
in parallel, in which case the ppc_proc_freq update should be inside the
lock, or it can't, in which case why do we need the lock at all?

-Scott