[PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus

[Koen Kooi]

Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" <hvaibhav at ti.com> het volgende geschreven:

> On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
>> 
>> Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh" <santosh.shilimkar at ti.com> het volgende geschreven:
>> 
>>> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>>>> 
>>>> Op 3 aug. 2012, om 09:21 heeft Koen Kooi <koen at dominion.thruhere.net> het volgende geschreven:
>>>> 
>>>>> 
>>>>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack <zonque at gmail.com> het volgende geschreven:
>>>>> 
>>>>>> On 30.03.2012 15:27, Santosh Shilimkar wrote:
>>>>>>> For coupled cpuidle to work when both cpus are active, it needs a global timer
>>>>>>> that can handle events for both cpus.  This timer is used as the broadcast
>>>>>>> clock-event when the per-cpu timer hardware stop in low power states.
>>>>>>> Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and
>>>>>>> set the irq to allow the clockevent core to determine the affinity of the
>>>>>>> timer.
>>>>>> 
>>>>>> These patches made it to mainline now, shortly befor 3.6-rc1, and it
>>>>>> breaks boot on my AM33xx board.
>>>>>> 
>>>>>> Once I revert 1/3, the board boots again but crashes with the Ooops
>>>>>> below. With the entire series reverted, everything works again as
>>>>>> expected. Any idea?
>>>>>> 
>>>>>> The upstream commit ids are
>>>>>> 
>>>>>> 11d6ec2e "ARM: OMAP: timer: allow gp timer clock-event to be used on
>>>>>> both cpus"
>>>>>> 5b4d5bcc "ARM: OMAP4: CPUidle: add synchronization for coupled idle states"
>>>>>> b93d70ae "ARM: OMAP4: CPUidle: Open broadcast clock-event device."
>>>>> 
>>>>> I've had boot problems with cpuidle enabled as well, what happens if you disable it? Is the revert still needed in that case?
>>>> 
>>>> To answer my own question: No, the reverts aren't needed if you disable cpuidle.
>>> 
>>> This is really strange since CPUIDLE code is really OMAP4 specific.
>>> obj-$(CONFIG_ARCH_OMAP4)                += cpuidle44xx.o
>>> 
>>> May be omap2plus build some how the code gets executed on AMXX
>>> 
>>> Can you try below and see if the boot with CPUIDLE enabled goes away on
>>> AMXX
>>> 
>>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
>>> index ea24174..195e756 100644
>>> --- a/arch/arm/mach-omap2/pm44xx.c
>>> +++ b/arch/arm/mach-omap2/pm44xx.c
>>> @@ -147,6 +147,9 @@ int __init omap4_pm_init(void)
>>>       struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
>>>       struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
>>> 
>>> +       if (!cpu_is_omap44xx())
>>> +               return -ENODEV;
>>> +
>>>       if (omap_rev() == OMAP4430_REV_ES1_0) {
>>>               WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
>>>               return -ENODEV;
>> 
>> That does seem to fix it:
>> 
>> root at beaglebone:~# zcat /proc/config.gz | grep -i cpu_idle
>> CONFIG_CPU_IDLE=y
>> CONFIG_CPU_IDLE_GOV_LADDER=y
>> CONFIG_CPU_IDLE_GOV_MENU=y
>> CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y
>> root at beaglebone:~# zcat /proc/config.gz | grep -i omap4   
>> CONFIG_ARCH_OMAP4=y
>> CONFIG_MACH_OMAP4_PANDA=y
>> # CONFIG_OMAP4_ERRATA_I688 is not set
>> # CONFIG_KEYBOARD_OMAP4 is not set
>> CONFIG_OMAP4_DSS_HDMI=y
>> 
> 
> This patch is not required, Without this patch is works for me,

I just retested and I don't need Santosh' patch, booting with cpuidle enable works now, after refreshing your patchset (and dropping the rtc commit, it conflicts with the other rtc patches out there).

> 
> [root at arago /]# cat /proc/version
> Linux version 3.6.0-rc1-next-20120803-00010-g5f6bf0f (a0393758 at psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Aug 3 15:06:57 IST 2012
> [root at arago /]#
> 
> 
> 
> Do you have below patch??
> ARM: OMAP: cpu: Make cpu_class_is_omap2 true for all non-omap1 platforms
> 
> 
> Also I have pushed branch (based on linux-next/master) to 
> https://github.com/hvaibhav/am335x-linux/tree/am335x-linux-next-master

Thanks! Ajays USB work and AnilKumar's pinctrl work are there as branches, any plans to add da8xx-fb, rtc and networking branches? As you can see from the cpsw patches, they were impossible to test because the davinci_mdio ones were missing.

regards,

Koen