> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, April 02, 2009 9:37 PM > To: Kim Kyuwon > Cc: Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx; Nayak, Rajendra > Subject: Re: PM branch rebased to 2.6.29... for real this time > > Yes, this locking problem requires Rajendra's patchset which > needs to be > updated for the PM branch. I will send the updated patch set on the latest PM branch maybe later today. > > 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
