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

On Fri, Aug 3, 2012 at 3:34 PM, Koen Kooi [off-list ref] wrote:

Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" [off-list ref] het volgende geschreven:

quoted

On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:

quoted

Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh" [off-list ref] het volgende geschreven:

quoted

On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi [off-list ref] wrote:

quoted

Op 3 aug. 2012, om 09:21 heeft Koen Kooi [off-list ref] het volgende geschreven:

quoted

Op 3 aug. 2012, om 09:16 heeft Daniel Mack [off-list ref] het volgende geschreven:

quoted

On 30.03.2012 15:27, Santosh Shilimkar wrote:

quoted

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

Thanks Koen for confirming. That means the issues was coming from
additional patching on top of 3.6-rc1
where some patches were not refreshed for AMXX.

Regards
Santosh

Regards
Santosh