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 > -- Kyuwon -- 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
