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

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

[Kevin Hilman]

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

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

[Premi, Sanjeev]

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

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

[Kevin Hilman]

"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

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

[Premi, Sanjeev]

 

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

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

[Kevin Hilman]

"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

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

[Kim Kyuwon]

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

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

[Kevin Hilman]

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

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

[Nayak, Rajendra]

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