Re: bisected regression: arm: omap3: voltage: fix channel configuration

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3402 bytes --]

On Mon, 23 Jul 2012 17:24:54 +0300 Tero Kristo <t-kristo@ti.com> wrote:

> Hi Neil,
> 
> On Mon, 2012-07-23 at 21:06 +1000, NeilBrown wrote:
> > My GTA04 (mobile phone using OMAP3 and TWL4030 PMIC) has difficulty rebooting
> > with 3.5.
> > The first boot (after power on) works fine.  But when I reboot it hangs just
> > before
> > 
> >   Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/800 MHz
> > 
> > is printed.  If I remove "mpurate=800" from the kernel command line the
> > problem goes away.
> > 
> > If I boot into 3.5, which works, and then reboot into an older working kernel
> > it freezes too.  So the 3.5 kernel leaves the device in a state which causes
> > any kernel to hang.
> 
> TWL chip retains its settings over warm boot which most likely explains
> this.
> 
> > 
> > I spent a while bisecting and narrowed it down to 
> > 
> > commit f9d29f1617eb1b2f1fd41622bd1a0fc51658d2f0
> > Author: Tero Kristo <t-kristo@ti.com>
> > Date:   Mon Feb 20 12:26:06 2012 +0200
> > 
> >     arm: omap3: voltage: fix channel configuration
> > 
> > 
> > If I revert this patch then the problem goes away.  So that is the fix I'll
> > go with for now, but if anyone wants me to try something else to help find
> > out what the real problem is and to find a proper fix, I'm happy to help.
> 
> Do you have cpufreq enabled in your build? If yes, then most likely the
> crash occurs because cpufreq scales the used OPP to minimum after boot
> and the warm reset doesn't switch the voltages properly and crashes as
> it attempts to raise CPU frequency.

Yes, I have cpufreq enabled.
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARM_OMAP2PLUS_CPUFREQ=y

Interestingly cpufreq thinks the range is 300MHz to 600MHz:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:300000 600000 

where 600 is that the freq is at boot:

# dmesg | grep Cryst
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[    0.056365] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/800 MHz

Does that mean the mpurate=800 isn't doing anything at all?

> 
> Also, if cpufreq is enabled, mpurate command line option doesn't really
> do much... it will just switch the frequency to the desired target
> during beginning of boot until cpufreq kicks in and switches the OPP to
> its own understanding of desired cpu rate. I think the handling of
> mpurate command line option should probably be ignored in cpufreq
> builds, or moved within the cpufreq driver.

So it looks like you are suggesting that I simply remove the "mpurate=800"
as it isn't doing anything useful anyway.  Is that right?

Might there be some way to get it to scale higher than 600MHz?
The first message from U-boot says:

OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz

and the board manufacturer thinks it should be capable of 800MHz.

Thanks,
NeilBrown


> 
> I tried to craft a quick boot time fix for this problem, but it seems
> the voltage layer is not properly initialized yet when the mpurate
> setting kicks in and it is not very straightforward to scale voltage
> during this time without writing a serious hack.
> 
> If you don't have cpufreq enabled, then the vdd routing on your board
> might be interesting (I don't think this is the case as the kernel works
> okay after 1st boot.)
> 
> -Tero
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]