* PM branch rebased to 2.6.29... for real this time @ 2009-03-25 22:55 Kevin Hilman 2009-03-31 14:55 ` Premi, Sanjeev 0 siblings, 1 reply; 8+ messages in thread From: Kevin Hilman @ 2009-03-25 22:55 UTC (permalink / raw) To: linux-omap Hello, The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is out, I've rebased the PM brach onto linux-omap HEAD just after the 2.6.29 merge. Minimal retention and off-mode on Beagle and RX51. Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: PM branch rebased to 2.6.29... for real this time 2009-03-25 22:55 PM branch rebased to 2.6.29... for real this time Kevin Hilman @ 2009-03-31 14:55 ` Premi, Sanjeev 2009-04-01 5:11 ` Kevin Hilman 0 siblings, 1 reply; 8+ messages in thread From: Premi, Sanjeev @ 2009-03-31 14:55 UTC (permalink / raw) To: Kevin Hilman, linux-omap > -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, March 26, 2009 4:26 AM > To: linux-omap@vger.kernel.org > Subject: PM branch rebased to 2.6.29... for real this time > > Hello, > > The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is > out, I've rebased the PM brach onto linux-omap HEAD just after the > 2.6.29 merge. > > Minimal retention and off-mode on Beagle and RX51. Another problem that I found on OMAP3EVM: When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), the kernel did not boot-up. The last few statements are: <3>clock: dpll5_ck failed transition to 'locked' clock: dpll5_ck failed transition to 'locked' <6>Disabling unused clock "dpll4_m6x2_ck" Disabling unused clock "dpll4_m6x2_ck" <6>Disabling unused clock "dpll3_m3x2_ck" Disabling unused clock "dpll3_m3x2_ck" <6>Disabling unused clock "sys_clkout1" Disabling unused clock "sys_clkout1" The PC is at the WFI statement. Tried other combinations as well: 1) only CPUidle enabled - okay. 2) only CPUfreq enabled - not okay. Best regards, Sanjeev > > 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 > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PM branch rebased to 2.6.29... for real this time 2009-03-31 14:55 ` Premi, Sanjeev @ 2009-04-01 5:11 ` Kevin Hilman 2009-04-01 7:18 ` Premi, Sanjeev 0 siblings, 1 reply; 8+ messages in thread From: Kevin Hilman @ 2009-04-01 5:11 UTC (permalink / raw) To: Premi, Sanjeev; +Cc: linux-omap, Rajendra Nayak "Premi, Sanjeev" <premi@ti.com> writes: >> -----Original Message----- >> From: linux-omap-owner@vger.kernel.org >> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman >> Sent: Thursday, March 26, 2009 4:26 AM >> To: linux-omap@vger.kernel.org >> Subject: PM branch rebased to 2.6.29... for real this time >> >> Hello, >> >> The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is >> out, I've rebased the PM brach onto linux-omap HEAD just after the >> 2.6.29 merge. >> >> Minimal retention and off-mode on Beagle and RX51. > > Another problem that I found on OMAP3EVM: > > When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), > the kernel did not boot-up. The last few statements are: There are known problems with CPUfreq on top of the new clock notifiers series. I am waiting for Rajendra to re-send his series which removes the virt clocks on top of the latest PM branch. > <3>clock: dpll5_ck failed transition to 'locked' > clock: dpll5_ck failed transition to 'locked' > <6>Disabling unused clock "dpll4_m6x2_ck" > Disabling unused clock "dpll4_m6x2_ck" > <6>Disabling unused clock "dpll3_m3x2_ck" > Disabling unused clock "dpll3_m3x2_ck" > <6>Disabling unused clock "sys_clkout1" > Disabling unused clock "sys_clkout1" > > The PC is at the WFI statement. > > Tried other combinations as well: > > 1) only CPUidle enabled - okay. > 2) only CPUfreq enabled - not okay. > Sounds to me like CPUfreq is changing frequencies during bootup. Did you select ondemand as the default CPUfreq governor? If so, can you try with performance as the default governor. If you're already using performance, then u-boot is setting a slower speed and CPUfreq may decide to change it during boot. If so, can you try the userspace governor as the default governor. This should prevent any automatic CPUFreq changes during bootup. Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: PM branch rebased to 2.6.29... for real this time 2009-04-01 5:11 ` Kevin Hilman @ 2009-04-01 7:18 ` Premi, Sanjeev 2009-04-01 18:46 ` Kevin Hilman 0 siblings, 1 reply; 8+ messages in thread From: Premi, Sanjeev @ 2009-04-01 7:18 UTC (permalink / raw) To: Kevin Hilman; +Cc: linux-omap, Nayak, Rajendra > -----Original Message----- > From: Kevin Hilman [mailto:khilman@deeprootsystems.com] > Sent: Wednesday, April 01, 2009 10:42 AM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; Nayak, Rajendra > Subject: Re: PM branch rebased to 2.6.29... for real this time > > "Premi, Sanjeev" <premi@ti.com> writes: > > >> -----Original Message----- > >> From: linux-omap-owner@vger.kernel.org > >> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kevin Hilman > >> Sent: Thursday, March 26, 2009 4:26 AM > >> To: linux-omap@vger.kernel.org > >> Subject: PM branch rebased to 2.6.29... for real this time > >> > >> Hello, > >> > >> The previous rebase was actually to 2.6.29-rc8. Now that 2.6.29 is > >> out, I've rebased the PM brach onto linux-omap HEAD just after the > >> 2.6.29 merge. > >> > >> Minimal retention and off-mode on Beagle and RX51. > > > > Another problem that I found on OMAP3EVM: > > > > When I compiled in CPUidle and CPUfreq (over omap3_evm_defconfig), > > the kernel did not boot-up. The last few statements are: > > There are known problems with CPUfreq on top of the new clock > notifiers series. > > I am waiting for Rajendra to re-send his series which removes the virt > clocks on top of the latest PM branch. > > > <3>clock: dpll5_ck failed transition to 'locked' > > clock: dpll5_ck failed transition to 'locked' > > <6>Disabling unused clock "dpll4_m6x2_ck" > > Disabling unused clock "dpll4_m6x2_ck" > > <6>Disabling unused clock "dpll3_m3x2_ck" > > Disabling unused clock "dpll3_m3x2_ck" > > <6>Disabling unused clock "sys_clkout1" > > Disabling unused clock "sys_clkout1" > > > > The PC is at the WFI statement. > > > > Tried other combinations as well: > > > > 1) only CPUidle enabled - okay. > > 2) only CPUfreq enabled - not okay. > > > > 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. > If so, can you > try the userspace governor as the default governor. This should > prevent any automatic CPUFreq changes during bootup. > > Kevin > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PM branch rebased to 2.6.29... for real this time 2009-04-01 7:18 ` Premi, Sanjeev @ 2009-04-01 18:46 ` Kevin Hilman 2009-04-02 3:58 ` Kim Kyuwon 0 siblings, 1 reply; 8+ messages in thread From: Kevin Hilman @ 2009-04-01 18:46 UTC (permalink / raw) To: Premi, Sanjeev; +Cc: linux-omap, Nayak, Rajendra "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PM branch rebased to 2.6.29... for real this time 2009-04-01 18:46 ` Kevin Hilman @ 2009-04-02 3:58 ` Kim Kyuwon 2009-04-02 16:06 ` Kevin Hilman 0 siblings, 1 reply; 8+ messages in thread From: Kim Kyuwon @ 2009-04-02 3:58 UTC (permalink / raw) To: Kevin Hilman; +Cc: Premi, Sanjeev, linux-omap, Nayak, Rajendra 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 > -- Kyuwon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PM branch rebased to 2.6.29... for real this time 2009-04-02 3:58 ` Kim Kyuwon @ 2009-04-02 16:06 ` Kevin Hilman 2009-04-03 5:21 ` Nayak, Rajendra 0 siblings, 1 reply; 8+ messages in thread From: Kevin Hilman @ 2009-04-02 16:06 UTC (permalink / raw) To: Kim Kyuwon; +Cc: Premi, Sanjeev, linux-omap, Nayak, Rajendra 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 >> > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: PM branch rebased to 2.6.29... for real this time 2009-04-02 16:06 ` Kevin Hilman @ 2009-04-03 5:21 ` Nayak, Rajendra 0 siblings, 0 replies; 8+ messages in thread From: Nayak, Rajendra @ 2009-04-03 5:21 UTC (permalink / raw) To: Kevin Hilman, Kim Kyuwon; +Cc: Premi, Sanjeev, linux-omap > -----Original Message----- > From: Kevin Hilman [mailto:khilman@deeprootsystems.com] > Sent: Thursday, April 02, 2009 9:37 PM > To: Kim Kyuwon > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; 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@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 > >> > > > > > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-04-03 5:21 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-25 22:55 PM branch rebased to 2.6.29... for real this time Kevin Hilman 2009-03-31 14:55 ` Premi, Sanjeev 2009-04-01 5:11 ` Kevin Hilman 2009-04-01 7:18 ` Premi, Sanjeev 2009-04-01 18:46 ` Kevin Hilman 2009-04-02 3:58 ` Kim Kyuwon 2009-04-02 16:06 ` Kevin Hilman 2009-04-03 5:21 ` Nayak, Rajendra
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.