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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> het volgende geschreven:

> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi <koen@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> 
>> Op 3 aug. 2012, om 09:21 heeft Koen Kooi <koen@xxxxxxxxxxxxxxxxxxxxx> het volgende geschreven:
>> 
>>> 
>>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack <zonque@xxxxxxxxx> 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@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@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

regards,

Koen--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux