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@xxxxxxxxxxxxxxxxxxx> wrote:
"Premi, Sanjeev" <premi@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
