Re: PM branch rebased to 2.6.29... for real this time

[Kevin Hilman <khilman@deeprootsystems.com>]

Yes, this locking problem requires Rajendra's patchset which needs to be 
updated for the PM branch.

Kevin

Kim Kyuwon wrote:
> Hi Kevin, Sanjeev,
> 
> I'm having the same problem.
> 
> when clk_set_rate() is invoked in omap_cpu_init() as shown below:
> 
> 	clk_set_rate(mpu_clk, policy->cpuinfo.max_freq * 1000);
> 
> It acquires the clocks mutex by the next statement.
> 
> 	mutex_lock(&clocks_mutex);
> 
> But after invoking arch_clock->clk_set_rate() in the middle of
> clk_set_rate(), clock_set_rate() is invoked again. So deadlock occurs
> due to mutex_lock() in clock_set_rate().
> 
> I think setting the default governor can not help this deadlock.
> 
> Regards,
> Kyuwon
> 
> On Thu, Apr 2, 2009 at 3:46 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Premi, Sanjeev" <premi@ti.com> writes:
>>
>> [...]
>>
>>>> Sounds to me like CPUfreq is changing frequencies during bootup.  Did
>>>> you select ondemand as the default CPUfreq governor?
>>> [sp] Yes. This is what I feel too. Only I was not clear why the process
>>> gets stuck at WFI. Haven't been able to debug further. So far...
>>>
>>>> If so, can you try with performance as the default governor.
>>> [sp] It was performance governor only.
>>>
>>>> If you're already using performance, then u-boot is setting a slower
>>>> speed and CPUfreq may decide to change it during boot.
>>> [sp] That is the case.
>>>
>> Can you try setting the default governor to userspace so that no DVFS
>> changes will happen during boot?
>>
>> Kevin
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
>