[PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
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.
Signed-off-by: Colin Cross
Signed-off-by: Santosh Shilimkar
---
arch/arm/mach-omap2/timer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fc73567..e33f9c4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,7 @@ static struct clock_event_device clockevent_gpt = {
.name = "gp timer",
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
+ .rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
};
@@ -225,7 +226,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
clockevent_delta2ns(3, &clockevent_gpt);
/* Timer internal resynch latency. */
- clockevent_gpt.cpumask = cpumask_of(0);
+ clockevent_gpt.cpumask = cpu_all_mask;
+ clockevent_gpt.irq = omap_dm_timer_get_irq(&clkev);
clockevents_register_device(&clockevent_gpt);
pr_info("OMAP clockevent source: GPTIMER%d at %lu Hz\n",
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
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." > [2.483556] net eth0: phy found : id is : 0x4dd072 > [2.489176] Unable to handle kernel NULL pointer dereference at virtual > address 0004 > [2.497666] pgd = c0004000 > [2.500507] [0004] *pgd= > [2.504282] Internal error: Oops: 805 [#1] SMP ARM > [2.509309] Modules linked in: > [2.512530] CPU: 0Not tainted (3.6.0-rc1-00036-g6c4c4ee-dirty #152) > [2.519579] PC is at cache_alloc_refill+0x1b0/0x620 > [2.524695] LR is at 0xc0 > [2.527449] pc : []lr : [<00c0>]psr: 6093 > [2.527449] sp : cf83dd70 ip : 0014 fp : 00200200 > [2.539478] r10: 0028 r9 : c0df68c0 r8 : 0028 > [2.544957] r7 : cf928000 r6 : cf87f3c0 r5 : cf88d000 r4 : cf810740 > [2.551800] r3 : 00100100 r2 : cf87f3c8 r1 : r0 : > [2.558647] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [2.566400] Control: 10c5387d Table: 80004019 DAC: 0017 > [2.572425] Process swapper/0 (pid: 1, stack limit = 0xcf83c2f8) > [2.578723] Stack: (0xcf83dd70 to 0xcf83e000) > [2.583297] dd60: > cf83b3c0 cf87f3d0 > [2.591875] dd80: cf87f3e4 0020 0077 cf810740 > cfb2a000 0020 > [2.600453] dda0: 0020 6013 0001 c03fdd40 cfb8d800 c00fd0f4 > 0001 0020 > [2.609031] ddc0: cfb8d800 cfb8d800 cfb2a000 cfb2a000 0700 0700 > cfb46500 c03fdd40 > [2.617609] dde0: cfb8d800 0700 cfb2a000 cfb46500 0001 > cfb46500 c0400588 > [2.626187] de00: cfb8de00 0010 00d0 c0316ae4 00d0 c0964698 > cfb8dea8 cfb8df28 > [2.634766] de20: 76616c73 00302d65 cfb8d800 000d 016b > 1202 c04ce7c4 > [2.643343] de40: cfb8d800 cfb8d800 c0502030 cfb8d82c c089aa80 > 016b 1202 > [2.651922] de60: c07ec0c0 c040bb6c c040bad0 cfb8d800 1203 1202 > 0001 c040bd98 > [2.660500] de80: cfb8d800 1202 0003 c07e4154 c040bee4 > cfb8d800 c07e416c > [2.669076] dea0: 0003 c07cc3cc 0001 0002 > > [2.677653] dec0: cf83c000 0002 > > [2.686230] dee0: c089d23c cf83c000 > 0002 > [2.694807] df00: c008c454 0002 c04526a8 > c02aa9ac > [2.703385] df20: 6013 c0851010 cf806440 c089d22c 0002 cf83c000 > 009e > [2.711963] df40: c07e5dd0 c07ca394 c089d22c c08a35c0 cf83c000 c07d0ee8 > c08a35c0 cf83c000 > [2.720541] df60: 009e c07e5dd8 c07cc230 c00088ec > 8013 > [2.729119] df80: c0776b54 c07cc230 009e c005c48c c06c904c c0776174 > 0007 0007 > [2.737697] dfa0: 6013 c07d0ee8 0007 c07d0ec8 c08a35c0 009e > c07e5dd8 c07a21c4 > [2.746274] dfc0: c07a28fc 0007 0007 c07a21c4 > c07a2800 > [2.754852] dfe0: c00149c0 0013 c00149c0 > 5575 7571 > [2.763444] [] (cache_alloc_refill+0x1b0/0x620) from > [] (kmem_cache_alloc+0xfc/0x184) > [2.773496] [] (kmem_cache_alloc+0xfc/0x184) from [] > (build_skb+0x24/0xa0) > [2.782540] [] (build_skb+0x24/0xa0) from [] > (__netdev_alloc_skb+0x94/0xdc) > [2.791681] [] (__netdev_alloc_skb+0x94/0xdc) from [] > (cpsw_ndo_open+0x364/0x490) > [2.801366] [] (cpsw_ndo_open+0x364/0x490) from [] > (__dev_open+0x9c/0xf8) > [2.810314] [] (__dev_open+0x9c/0xf8) from [] > (__dev_change_flags+0x78/0x13c) > [2.819628] [] (__dev_change_flags+0x78/0x13c) from [] > (dev_change_flags+0x10/0x48) > [2.829493] [] (dev_change_flags+0x10/0x48) from [] > (ip_auto_config+0x19c/0xfec) > [2.839079] [] (ip_auto_config+0x19c/0xfec) from [] > (do_one_initcall+0x34/0x184) > [2.848679] [] (do_one_initcall+0x34/0x184) from [] > (kernel_init+0xfc/0x1c8) > [2.857914]
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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? I'd really want cpufreq and cpuidle to work properly, but right now I'll settle for "it boots". regards, Koen-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 03, 2012 at 12:46:54, Daniel Mack wrote: > 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. > Thanks Daniel for testing and reporting. I haven't tried 3.6-rc1 yet, as omap-linux/master has not yet migrated to it. I am testing it now, and will let you know on the status. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 09:21 heeft Koen Kooi het volgende geschreven: > > Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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.-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi wrote:
>
> Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
> volgende geschreven:
>
>>
>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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;
Regards
Ssantosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh"
het volgende geschreven:
> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi wrote:
>>
>> Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
>> volgende geschreven:
>>
>>>
>>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
>
> Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh"
> het volgende geschreven:
>
> > On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
> > wrote:
> >>
> >> Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
> >> volgende geschreven:
> >>
> >>>
> >>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
>
This patch is not required, Without this patch is works for me,
[root@arago /]# cat /proc/version
Linux version 3.6.0-rc1-next-20120803-00010-g5f6bf0f (a0393758@psplinux064)
(gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Aug 3 15:06:57 IST
2012
[root@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,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 3, 2012 at 3:12 PM, Hiremath, Vaibhav wrote:
> On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
>>
>> Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh"
>> het volgende geschreven:
>>
>> > On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
>> > wrote:
>> >>
>> >> Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
>> >> volgende geschreven:
>> >>
>> >>>
>> >>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
>>
>
> This patch is not required, Without this patch is works for me,
>
Which is good news.Do you have CPUIDLE enabled in your build when you tested
it. Note that CPUIDLE is not enabled by-default in omap2plus build and as I see
from Koen's email, he did enable it in his testing.
Please confirm that 3.6-rc1 boots fine even with CPUIDLE enabled and
we don't need
the above mentioned patch. If it is not the case, I can post the fix.
Thanks for testing.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" 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"
>> het volgende geschreven:
>>
>>> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
>>> wrote:
Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
volgende geschreven:
>
> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
>>
>
> 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@arago /]# cat /proc/version
> Linux version 3.6.0-rc1-next-20120803-00010-g5f6bf0f (a0393758@psplinux064)
> (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Aug 3 15:06:57
> IST 2012
> [root@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--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 wrote:
>
> Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" 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"
>>> het volgende geschreven:
>>>
On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
wrote:
>
> Op 3 aug. 2012, om 09:21 heeft Koen Kooi het
> volgende geschreven:
>
>>
>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
>>>
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 03, 2012 at 15:34:25, Koen Kooi wrote:
>
> Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" 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"
> >> het volgende geschreven:
> >>
> >>> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
> >>> wrote:
>
> Op 3 aug. 2012, om 09:21 heeft Koen Kooi
> het volgende geschreven:
>
> >
> > Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
> >>
> >
> > 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 for conforming Koen.
> >
> > [root@arago /]# cat /proc/version
> > Linux version 3.6.0-rc1-next-20120803-00010-g5f6bf0f (a0393758@psplinux064)
> > (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Fri Aug 3 15:06:57
> > IST 2012
> > [root@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.
>
Yes that's the plan, I am in the process of updating it.
Hopefully I will have branch for each major module.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 03, 2012 at 15:18:15, Shilimkar, Santosh wrote:
> On Fri, Aug 3, 2012 at 3:12 PM, Hiremath, Vaibhav wrote:
> > On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
> >>
> >> Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh"
> >> het volgende geschreven:
> >>
> >> > On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
> >> > wrote:
> >> >>
> >> >> Op 3 aug. 2012, om 09:21 heeft Koen Kooi
> >> >> het volgende geschreven:
> >> >>
> >> >>>
> >> >>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
> >>
> >
> > This patch is not required, Without this patch is works for me,
> >
> Which is good news.Do you have CPUIDLE enabled in your build when you tested
> it. Note that CPUIDLE is not enabled by-default in omap2plus build and as I
> see
> from Koen's email, he did enable it in his testing.
>
> Please confirm that 3.6-rc1 boots fine even with CPUIDLE enabled and
> we don't need
> the above mentioned patch. If it is not the case, I can post the fix.
>
Just FYI, I have also tested with CPUIDLE enabled and it worked for me.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 3, 2012 at 4:02 PM, Hiremath, Vaibhav wrote:
> On Fri, Aug 03, 2012 at 15:18:15, Shilimkar, Santosh wrote:
>> On Fri, Aug 3, 2012 at 3:12 PM, Hiremath, Vaibhav wrote:
>> > On Fri, Aug 03, 2012 at 15:03:07, Koen Kooi wrote:
>> >>
>> >> Op 3 aug. 2012, om 11:27 heeft "Shilimkar, Santosh"
>> >> het volgende geschreven:
>> >>
>> >> > On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
>> >> > wrote:
>> >> >>
>> >> >> Op 3 aug. 2012, om 09:21 heeft Koen Kooi
>> >> >> het volgende geschreven:
>> >> >>
>> >> >>>
>> >> >>> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
>> >>
>> >
>> > This patch is not required, Without this patch is works for me,
>> >
>> Which is good news.Do you have CPUIDLE enabled in your build when you tested
>> it. Note that CPUIDLE is not enabled by-default in omap2plus build and as I
>> see
>> from Koen's email, he did enable it in his testing.
>>
>> Please confirm that 3.6-rc1 boots fine even with CPUIDLE enabled and
>> we don't need
>> the above mentioned patch. If it is not the case, I can post the fix.
>>
>
> Just FYI, I have also tested with CPUIDLE enabled and it worked for me.
>
Thanks Vaibhav for update.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
On Fri, Aug 03, 2012 at 15:44:32, Shilimkar, Santosh wrote:
> On Fri, Aug 3, 2012 at 3:34 PM, Koen Kooi wrote:
> >
> > Op 3 aug. 2012, om 11:42 heeft "Hiremath, Vaibhav" 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"
> >>> het volgende geschreven:
> >>>
> On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi
> wrote:
> >
> > Op 3 aug. 2012, om 09:21 heeft Koen Kooi
> > het volgende geschreven:
> >
> >>
> >> Op 3 aug. 2012, om 09:16 heeft Daniel Mack 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
> >>>
> >>
> >> 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.
>
Actually its not that.
AM335x needs to be added as part of cpu_class_is_omap2(), without this it
gets into issues.
The patch has been already submitted to the list, but still not merged by
Tony.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
* Hiremath, Vaibhav [120803 03:34]: > > Actually its not that. > AM335x needs to be added as part of cpu_class_is_omap2(), without this it > gets into issues. > The patch has been already submitted to the list, but still not merged by > Tony. Let's just add it to the list of cpu_class_is_omap2() with a proper patch description for the fix. Then we still need to sort it out properly from common zImage point of view without having to maintain that list. Vaibhav, can you please post your original patch with the description updated for v3.6-rc1? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
