Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Felipe Balbi [141003 07:53]: > On Thu, Oct 02, 2014 at 04:59:30PM -0500, Felipe Balbi wrote: > > On Thu, Oct 02, 2014 at 02:19:08PM -0700, Tony Lindgren wrote: > > > * Felipe Balbi [141002 13:18]: > > > > On Thu, Oct 02, 2014 at 12:52:38PM -0700, Tony Lindgren wrote: > > > > > > > > > > Hmm here seems to be a link to similar issues from 2011: > > > > > > > > > > http://e2e.ti.com/support/arm/sitara_arm/f/791/p/113593/628790.aspx > > > > > > > > > > Looks like the issue can be potentially reproduced with: > > > > > > > > > > # cyclictest -l1 -m -a0 -t1 -n -p99 -i200 -h200 -q > > > > > > > > running here on am335x and am437x. On that same post, on person > > > > mentions he reproduced on beagle bone. > > > > > > OK I'll run it here too on my am37xx evm. Looks like Stanley was > > > running both cyclictest and hackbench the same time. > > > > yeah I did that. > > > > BTW, just got the following on BBB, AM437x SK is still running. > > > > [ 3952.432262] Kernel panic - not syncing: Attempted to kill the idle > > task!752763 > > [ 3952.442403] CPU: 0 PID: 0 Comm: hackbench Not tainted > > 3.17.0-rc6-00456-gd8da063 #222 > > [ 3952.450517] [] (unwind_backtrace) from [] > > (show_stack+0x20/0x24) > > [ 3952.458620] [] (show_stack) from [] > > (dump_stack+0x8c/0xa4) > > [ 3952.466168] [] (dump_stack) from [] > > (panic+0xa4/0x224) > > [ 3952.473358] [] (panic) from [] (do_exit+0x924/0x9d8) > > [ 3952.480358] [] (do_exit) from [] > > (do_group_exit+0x50/0xc0) > > [ 3952.487903] [] (do_group_exit) from [] > > (__wake_up_parent+0x0/0x30) > > [ 3952.496179] [] (__wake_up_parent) from [] > > (ret_fast_syscall+0x0/0x48) > > [ 3952.504875] drm_kms_helper: panic occurred, switching back to text > > console > > [ 3952.517844] ---[ end Kernel panic - not syncing: Attempted to kill the > > idle task! > > > > > > > And I'll also queue the following patch during the -rc cycle to > > > avoid apps segfaulting occasionally at random on omap3. > > > > and maybe this will fix BBB :-) I'll add that locally. If I survive > > until tomorrow, I'll add a Tested-by. > > BBB died again with the same behavior as above, but I think it's > unrelated to this errata. Therefore: > > Tested-by: Felipe Balbi BTW, I have revision r3p2: CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d And it still seems to need 430973. Looks like my 37xx evm produced no errors overnight running cyclictest and hackbench the same time. 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
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, Oct 02, 2014 at 04:59:30PM -0500, Felipe Balbi wrote: > Hi, > > On Thu, Oct 02, 2014 at 02:19:08PM -0700, Tony Lindgren wrote: > > * Felipe Balbi [141002 13:18]: > > > On Thu, Oct 02, 2014 at 12:52:38PM -0700, Tony Lindgren wrote: > > > > * Tony Lindgren [141002 09:36]: > > > > > * Tero Kristo [140924 02:04]: > > > > > > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > > > > > > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > > > > > > > > > > > >>However, I saw the following crash at boot on 37xxevm during one > > > > > > >>of > > > > > > >>the boot test. Ran thirty more boot tests afterwards on that > > > > > > >>board > > > > > > >>and it did not recur. It seems unlikely that the problem is > > > > > > >>related > > > > > > >>to this series, but looks like we may have some intermittent boot > > > > > > >>failure or race on 37xx :-( > > > > > > > > > > > > > >... > > > > > > > > > > > > > >>[4.892211] Unhandled fault: external abort on non-linefetch > > > > > > >>(0x1028) at 0xfa318034 > > > > > > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > > > > > > >>[4.905090] Modules linked in: > > > > > > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > > > > >>3.17.0-rc5-12866-g0164b2d #1 > > > > > > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > > > > > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > > > > > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > > > > > > >>[4.933715] pc : []lr : []psr: > > > > > > >>0193 > > > > > > >>[4.933715] sp : c082bed8 ip : fp : > > > > > > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > > > > > > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : > > > > > > >>3d9759e7 > > > > > > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : > > > > > > >>fec1 > > > > > > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA > > > > > > >>ARM Segment kernel > > > > > > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > > > > > >>[4.978942] Process swapper/0 (pid: 0, stack limit = > > > > > > >>0xc082a248) > > > > > > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > > > > > > >>[4.989868] bec0: > > > > > > >> 237bc339 0001 > > > > > > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 > > > > > > >>cfc7da50 cfc7d720 c00a4780 > > > > > > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > > > > > >> 0001 c08256c8 > > > > > > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 > > > > > > >>0001 0002 a193 > > > > > > >>[5.024414] bf40: 00989680 24101100 0001 > > > > > > >>cfc7da50 c108cc78 > > > > > > >>[5.033020] bf60: c00962b0 0002 0001 > > > > > > >> c108cc78 c00a56f0 > > > > > > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 > > > > > > >>c082a000 c08c8ce8 > > > > > > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 > > > > > > >>c08270f0 c08caf40 c080fdc0 > > > > > > >>[5.058929] bfc0: c07c3b74 c07c35f0 > > > > > > >> c080fdc0 > > > > > > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 > > > > > > >>80008074 > > > > > > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > > > > > > >>[] (clockevents_program_event+0xc0/0x148) > > > > > > >>[5.087005] [] (clockevents_program_event) from > > > > > > >>[] (tick_program_event+0x44/0x54) > > > > > > >>[5.096771] [] (tick_program_event) from > > > > > > >>[] (__hrtimer_start_range_ns+0x3c0/0x4a0) > > > > > > >>[5.106597] [] (__hrtimer_start_range_ns) from > > > > > > >>[] (hrtimer_start_range_ns+0x24/0x2c) > > > > > > >>[5.116577] [] (hrtimer_start_range_ns) from > > > > > > >>[] (tick_nohz_idle_exit+0x140/0x1ec) > > > > > > >>[5.126342] [] (tick_nohz_idle_exit) from > > > > > > >>[] (cpu_startup_entry+0xf4/0x2d0) > > > > > > >>[5.135528] [] (cpu_startup_entry) from [] > > > > > > >>(start_kernel+0x340/0x3a8) > > > > > > >>[5.144165] [] (start_kernel) from [<80008074>] > > > > > > >>(0x80008074) > > > > > > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c > > > > > > >>(e5931000) > > > > > > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > > > > > > >>[5.162353] Kernel panic - not syncing: Attempted to kill the > > > > > > >>idle task! > > > > > > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to > > > > > > >>kill the idle task! > > > > > > > > > > > > > >Actually it just occurred to me that if something broke > > > > > > >*wait_target_ready(), we'd expect to see intermittent failures > > > > > > >like this, > > > > > > >and this series touches *wait_target_ready().
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
Hi, On Thu, Oct 02, 2014 at 02:19:08PM -0700, Tony Lindgren wrote: > * Felipe Balbi [141002 13:18]: > > On Thu, Oct 02, 2014 at 12:52:38PM -0700, Tony Lindgren wrote: > > > * Tony Lindgren [141002 09:36]: > > > > * Tero Kristo [140924 02:04]: > > > > > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > > > > > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > > > > > > > > > >>However, I saw the following crash at boot on 37xxevm during one of > > > > > >>the boot test. Ran thirty more boot tests afterwards on that board > > > > > >>and it did not recur. It seems unlikely that the problem is related > > > > > >>to this series, but looks like we may have some intermittent boot > > > > > >>failure or race on 37xx :-( > > > > > > > > > > > >... > > > > > > > > > > > >>[4.892211] Unhandled fault: external abort on non-linefetch > > > > > >>(0x1028) at 0xfa318034 > > > > > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > > > > > >>[4.905090] Modules linked in: > > > > > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > > > >>3.17.0-rc5-12866-g0164b2d #1 > > > > > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > > > > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > > > > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > > > > > >>[4.933715] pc : []lr : []psr: > > > > > >>0193 > > > > > >>[4.933715] sp : c082bed8 ip : fp : > > > > > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > > > > > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : > > > > > >>3d9759e7 > > > > > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : > > > > > >>fec1 > > > > > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > > > > > >> Segment kernel > > > > > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > > > > >>[4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > > > > > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > > > > > >>[4.989868] bec0: > > > > > >> 237bc339 0001 > > > > > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 > > > > > >>cfc7da50 cfc7d720 c00a4780 > > > > > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > > > > >> 0001 c08256c8 > > > > > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 > > > > > >>0001 0002 a193 > > > > > >>[5.024414] bf40: 00989680 24101100 0001 > > > > > >>cfc7da50 c108cc78 > > > > > >>[5.033020] bf60: c00962b0 0002 0001 > > > > > >> c108cc78 c00a56f0 > > > > > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 > > > > > >>c082a000 c08c8ce8 > > > > > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 > > > > > >>c08270f0 c08caf40 c080fdc0 > > > > > >>[5.058929] bfc0: c07c3b74 c07c35f0 > > > > > >> c080fdc0 > > > > > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 > > > > > >>80008074 > > > > > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > > > > > >>[] (clockevents_program_event+0xc0/0x148) > > > > > >>[5.087005] [] (clockevents_program_event) from > > > > > >>[] (tick_program_event+0x44/0x54) > > > > > >>[5.096771] [] (tick_program_event) from [] > > > > > >>(__hrtimer_start_range_ns+0x3c0/0x4a0) > > > > > >>[5.106597] [] (__hrtimer_start_range_ns) from > > > > > >>[] (hrtimer_start_range_ns+0x24/0x2c) > > > > > >>[5.116577] [] (hrtimer_start_range_ns) from > > > > > >>[] (tick_nohz_idle_exit+0x140/0x1ec) > > > > > >>[5.126342] [] (tick_nohz_idle_exit) from [] > > > > > >>(cpu_startup_entry+0xf4/0x2d0) > > > > > >>[5.135528] [] (cpu_startup_entry) from [] > > > > > >>(start_kernel+0x340/0x3a8) > > > > > >>[5.144165] [] (start_kernel) from [<80008074>] > > > > > >>(0x80008074) > > > > > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > > > > > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > > > > > >>[5.162353] Kernel panic - not syncing: Attempted to kill the > > > > > >>idle task! > > > > > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to > > > > > >>kill the idle task! > > > > > > > > > > > >Actually it just occurred to me that if something broke > > > > > >*wait_target_ready(), we'd expect to see intermittent failures like > > > > > >this, > > > > > >and this series touches *wait_target_ready(). So it might be worth > > > > > >taking > > > > > >a look at that with a magnifying glass to make sure that it's > > > > > >working. > > > > > > > > > > I think this is probably something else, and most likely more > > > > > hideous. The > > > > > clock source timers are only enabled once during a boot, and
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Felipe Balbi [141002 13:18]: > On Thu, Oct 02, 2014 at 12:52:38PM -0700, Tony Lindgren wrote: > > * Tony Lindgren [141002 09:36]: > > > * Tero Kristo [140924 02:04]: > > > > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > > > > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > > > > > > > >>However, I saw the following crash at boot on 37xxevm during one of > > > > >>the boot test. Ran thirty more boot tests afterwards on that board > > > > >>and it did not recur. It seems unlikely that the problem is related > > > > >>to this series, but looks like we may have some intermittent boot > > > > >>failure or race on 37xx :-( > > > > > > > > > >... > > > > > > > > > >>[4.892211] Unhandled fault: external abort on non-linefetch > > > > >>(0x1028) at 0xfa318034 > > > > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > > > > >>[4.905090] Modules linked in: > > > > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > > >>3.17.0-rc5-12866-g0164b2d #1 > > > > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > > > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > > > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > > > > >>[4.933715] pc : []lr : []psr: 0193 > > > > >>[4.933715] sp : c082bed8 ip : fp : > > > > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > > > > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : > > > > >>3d9759e7 > > > > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : > > > > >>fec1 > > > > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > > > > >>Segment kernel > > > > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > > > >>[4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > > > > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > > > > >>[4.989868] bec0: > > > > >> 237bc339 0001 > > > > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 > > > > >>cfc7da50 cfc7d720 c00a4780 > > > > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > > > >> 0001 c08256c8 > > > > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 > > > > >>0001 0002 a193 > > > > >>[5.024414] bf40: 00989680 24101100 0001 > > > > >>cfc7da50 c108cc78 > > > > >>[5.033020] bf60: c00962b0 0002 0001 > > > > >> c108cc78 c00a56f0 > > > > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 > > > > >>c082a000 c08c8ce8 > > > > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 > > > > >>c08270f0 c08caf40 c080fdc0 > > > > >>[5.058929] bfc0: c07c3b74 c07c35f0 > > > > >> c080fdc0 > > > > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 > > > > >>80008074 > > > > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > > > > >>[] (clockevents_program_event+0xc0/0x148) > > > > >>[5.087005] [] (clockevents_program_event) from > > > > >>[] (tick_program_event+0x44/0x54) > > > > >>[5.096771] [] (tick_program_event) from [] > > > > >>(__hrtimer_start_range_ns+0x3c0/0x4a0) > > > > >>[5.106597] [] (__hrtimer_start_range_ns) from > > > > >>[] (hrtimer_start_range_ns+0x24/0x2c) > > > > >>[5.116577] [] (hrtimer_start_range_ns) from > > > > >>[] (tick_nohz_idle_exit+0x140/0x1ec) > > > > >>[5.126342] [] (tick_nohz_idle_exit) from [] > > > > >>(cpu_startup_entry+0xf4/0x2d0) > > > > >>[5.135528] [] (cpu_startup_entry) from [] > > > > >>(start_kernel+0x340/0x3a8) > > > > >>[5.144165] [] (start_kernel) from [<80008074>] > > > > >>(0x80008074) > > > > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > > > > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > > > > >>[5.162353] Kernel panic - not syncing: Attempted to kill the idle > > > > >>task! > > > > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to kill > > > > >>the idle task! > > > > > > > > > >Actually it just occurred to me that if something broke > > > > >*wait_target_ready(), we'd expect to see intermittent failures like > > > > >this, > > > > >and this series touches *wait_target_ready(). So it might be worth > > > > >taking > > > > >a look at that with a magnifying glass to make sure that it's working. > > > > > > > > I think this is probably something else, and most likely more hideous. > > > > The > > > > clock source timers are only enabled once during a boot, and they are > > > > never > > > > idled after that. This error happens almost 5 seconds after the initial > > > > module enable...? > > > > > > I have not seen this and I've had this branch merged in for testing > > > here for about a week now. I've also merged it into l
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, Oct 02, 2014 at 12:52:38PM -0700, Tony Lindgren wrote: > * Tony Lindgren [141002 09:36]: > > * Tero Kristo [140924 02:04]: > > > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > > > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > > > > > >>However, I saw the following crash at boot on 37xxevm during one of > > > >>the boot test. Ran thirty more boot tests afterwards on that board > > > >>and it did not recur. It seems unlikely that the problem is related > > > >>to this series, but looks like we may have some intermittent boot > > > >>failure or race on 37xx :-( > > > > > > > >... > > > > > > > >>[4.892211] Unhandled fault: external abort on non-linefetch > > > >>(0x1028) at 0xfa318034 > > > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > > > >>[4.905090] Modules linked in: > > > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > >>3.17.0-rc5-12866-g0164b2d #1 > > > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > > > >>[4.933715] pc : []lr : []psr: 0193 > > > >>[4.933715] sp : c082bed8 ip : fp : > > > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > > > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : > > > >>3d9759e7 > > > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : > > > >>fec1 > > > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > > > >>Segment kernel > > > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > > >>[4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > > > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > > > >>[4.989868] bec0: > > > >> 237bc339 0001 > > > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 > > > >>cfc7da50 cfc7d720 c00a4780 > > > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > > >> 0001 c08256c8 > > > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 > > > >>0001 0002 a193 > > > >>[5.024414] bf40: 00989680 24101100 0001 > > > >>cfc7da50 c108cc78 > > > >>[5.033020] bf60: c00962b0 0002 0001 > > > >> c108cc78 c00a56f0 > > > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 > > > >>c082a000 c08c8ce8 > > > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 > > > >>c08270f0 c08caf40 c080fdc0 > > > >>[5.058929] bfc0: c07c3b74 c07c35f0 > > > >> c080fdc0 > > > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 > > > >>80008074 > > > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > > > >>[] (clockevents_program_event+0xc0/0x148) > > > >>[5.087005] [] (clockevents_program_event) from > > > >>[] (tick_program_event+0x44/0x54) > > > >>[5.096771] [] (tick_program_event) from [] > > > >>(__hrtimer_start_range_ns+0x3c0/0x4a0) > > > >>[5.106597] [] (__hrtimer_start_range_ns) from > > > >>[] (hrtimer_start_range_ns+0x24/0x2c) > > > >>[5.116577] [] (hrtimer_start_range_ns) from [] > > > >>(tick_nohz_idle_exit+0x140/0x1ec) > > > >>[5.126342] [] (tick_nohz_idle_exit) from [] > > > >>(cpu_startup_entry+0xf4/0x2d0) > > > >>[5.135528] [] (cpu_startup_entry) from [] > > > >>(start_kernel+0x340/0x3a8) > > > >>[5.144165] [] (start_kernel) from [<80008074>] > > > >>(0x80008074) > > > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > > > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > > > >>[5.162353] Kernel panic - not syncing: Attempted to kill the idle > > > >>task! > > > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to kill > > > >>the idle task! > > > > > > > >Actually it just occurred to me that if something broke > > > >*wait_target_ready(), we'd expect to see intermittent failures like this, > > > >and this series touches *wait_target_ready(). So it might be worth > > > >taking > > > >a look at that with a magnifying glass to make sure that it's working. > > > > > > I think this is probably something else, and most likely more hideous. The > > > clock source timers are only enabled once during a boot, and they are > > > never > > > idled after that. This error happens almost 5 seconds after the initial > > > module enable...? > > > > I have not seen this and I've had this branch merged in for testing > > here for about a week now. I've also merged it into linux-omap master > > branch for merging now, let's keep it there and plan on merging it early > > for v3.19 merge window unless some issues are found. > > Hmm here seems to be a link to similar issues from 2011: > > http://e2e.ti.com
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Tony Lindgren [141002 09:36]: > * Tero Kristo [140924 02:04]: > > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > > > >>However, I saw the following crash at boot on 37xxevm during one of > > >>the boot test. Ran thirty more boot tests afterwards on that board > > >>and it did not recur. It seems unlikely that the problem is related > > >>to this series, but looks like we may have some intermittent boot > > >>failure or race on 37xx :-( > > > > > >... > > > > > >>[4.892211] Unhandled fault: external abort on non-linefetch (0x1028) > > >>at 0xfa318034 > > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > > >>[4.905090] Modules linked in: > > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > >>3.17.0-rc5-12866-g0164b2d #1 > > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > > >>[4.933715] pc : []lr : []psr: 0193 > > >>[4.933715] sp : c082bed8 ip : fp : > > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 > > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 > > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > > >>Segment kernel > > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > >>[4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > > >>[4.989868] bec0: > > >> 237bc339 0001 > > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 > > >>cfc7da50 cfc7d720 c00a4780 > > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > >> 0001 c08256c8 > > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 > > >>0001 0002 a193 > > >>[5.024414] bf40: 00989680 24101100 0001 > > >>cfc7da50 c108cc78 > > >>[5.033020] bf60: c00962b0 0002 0001 > > >> c108cc78 c00a56f0 > > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 > > >>c082a000 c08c8ce8 > > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 > > >>c08270f0 c08caf40 c080fdc0 > > >>[5.058929] bfc0: c07c3b74 c07c35f0 > > >> c080fdc0 > > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 > > >>80008074 > > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > > >>[] (clockevents_program_event+0xc0/0x148) > > >>[5.087005] [] (clockevents_program_event) from [] > > >>(tick_program_event+0x44/0x54) > > >>[5.096771] [] (tick_program_event) from [] > > >>(__hrtimer_start_range_ns+0x3c0/0x4a0) > > >>[5.106597] [] (__hrtimer_start_range_ns) from [] > > >>(hrtimer_start_range_ns+0x24/0x2c) > > >>[5.116577] [] (hrtimer_start_range_ns) from [] > > >>(tick_nohz_idle_exit+0x140/0x1ec) > > >>[5.126342] [] (tick_nohz_idle_exit) from [] > > >>(cpu_startup_entry+0xf4/0x2d0) > > >>[5.135528] [] (cpu_startup_entry) from [] > > >>(start_kernel+0x340/0x3a8) > > >>[5.144165] [] (start_kernel) from [<80008074>] (0x80008074) > > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > > >>[5.162353] Kernel panic - not syncing: Attempted to kill the idle > > >>task! > > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the > > >>idle task! > > > > > >Actually it just occurred to me that if something broke > > >*wait_target_ready(), we'd expect to see intermittent failures like this, > > >and this series touches *wait_target_ready(). So it might be worth taking > > >a look at that with a magnifying glass to make sure that it's working. > > > > I think this is probably something else, and most likely more hideous. The > > clock source timers are only enabled once during a boot, and they are never > > idled after that. This error happens almost 5 seconds after the initial > > module enable...? > > I have not seen this and I've had this branch merged in for testing > here for about a week now. I've also merged it into linux-omap master > branch for merging now, let's keep it there and plan on merging it early > for v3.19 merge window unless some issues are found. Hmm here seems to be a link to similar issues from 2011: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/113593/628790.aspx Looks like the issue can be potentially reproduced with: # cyclictest -l1 -m -a0 -t1 -n -p99 -i200 -h200 -q Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to maj
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Tero Kristo [140924 02:04]: > On 09/19/2014 08:27 PM, Paul Walmsley wrote: > >On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > >>However, I saw the following crash at boot on 37xxevm during one of > >>the boot test. Ran thirty more boot tests afterwards on that board > >>and it did not recur. It seems unlikely that the problem is related > >>to this series, but looks like we may have some intermittent boot > >>failure or race on 37xx :-( > > > >... > > > >>[4.892211] Unhandled fault: external abort on non-linefetch (0x1028) at > >>0xfa318034 > >>[4.900299] Internal error: : 1028 [#1] SMP ARM > >>[4.905090] Modules linked in: > >>[4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > >>3.17.0-rc5-12866-g0164b2d #1 > >>[4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > >>[4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > >>[4.928009] LR is at clockevents_program_event+0xc0/0x148 > >>[4.933715] pc : []lr : []psr: 0193 > >>[4.933715] sp : c082bed8 ip : fp : > >>[4.945800] r10: r9 : 24101100 r8 : c0839080 > >>[4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 > >>[4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 > >>[4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > >>Segment kernel > >>[4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > >>[4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > >>[4.985290] Stack: (0xc082bed8 to 0xc082c000) > >>[4.989868] bec0: > >>237bc339 0001 > >>[4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 cfc7da50 > >>cfc7d720 c00a4780 > >>[5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > >>0001 c08256c8 > >>[5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 0001 > >>0002 a193 > >>[5.024414] bf40: 00989680 24101100 0001 cfc7da50 > >> c108cc78 > >>[5.033020] bf60: c00962b0 0002 0001 > >>c108cc78 c00a56f0 > >>[5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 c082a000 > >> c08c8ce8 > >>[5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 c08270f0 > >>c08caf40 c080fdc0 > >>[5.058929] bfc0: c07c3b74 c07c35f0 > >> c080fdc0 > >>[5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 80008074 > >> > >>[5.076171] [] (omap2_gp_timer_set_next_event) from > >>[] (clockevents_program_event+0xc0/0x148) > >>[5.087005] [] (clockevents_program_event) from [] > >>(tick_program_event+0x44/0x54) > >>[5.096771] [] (tick_program_event) from [] > >>(__hrtimer_start_range_ns+0x3c0/0x4a0) > >>[5.106597] [] (__hrtimer_start_range_ns) from [] > >>(hrtimer_start_range_ns+0x24/0x2c) > >>[5.116577] [] (hrtimer_start_range_ns) from [] > >>(tick_nohz_idle_exit+0x140/0x1ec) > >>[5.126342] [] (tick_nohz_idle_exit) from [] > >>(cpu_startup_entry+0xf4/0x2d0) > >>[5.135528] [] (cpu_startup_entry) from [] > >>(start_kernel+0x340/0x3a8) > >>[5.144165] [] (start_kernel) from [<80008074>] (0x80008074) > >>[5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > >>[5.157470] ---[ end trace f92de024d996d904 ]--- > >>[5.162353] Kernel panic - not syncing: Attempted to kill the idle task! > >>[5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the > >>idle task! > > > >Actually it just occurred to me that if something broke > >*wait_target_ready(), we'd expect to see intermittent failures like this, > >and this series touches *wait_target_ready(). So it might be worth taking > >a look at that with a magnifying glass to make sure that it's working. > > I think this is probably something else, and most likely more hideous. The > clock source timers are only enabled once during a boot, and they are never > idled after that. This error happens almost 5 seconds after the initial > module enable...? I have not seen this and I've had this branch merged in for testing here for about a week now. I've also merged it into linux-omap master branch for merging now, let's keep it there and plan on merging it early for v3.19 merge window unless some issues are found. 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
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On 09/19/2014 08:27 PM, Paul Walmsley wrote: On Fri, 19 Sep 2014, Paul Walmsley wrote: However, I saw the following crash at boot on 37xxevm during one of the boot test. Ran thirty more boot tests afterwards on that board and it did not recur. It seems unlikely that the problem is related to this series, but looks like we may have some intermittent boot failure or race on 37xx :-( ... [4.892211] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa318034 [4.900299] Internal error: : 1028 [#1] SMP ARM [4.905090] Modules linked in: [4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc5-12866-g0164b2d #1 [4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 [4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 [4.928009] LR is at clockevents_program_event+0xc0/0x148 [4.933715] pc : []lr : []psr: 0193 [4.933715] sp : c082bed8 ip : fp : [4.945800] r10: r9 : 24101100 r8 : c0839080 [4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 [4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 [4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 [4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) [4.985290] Stack: (0xc082bed8 to 0xc082c000) [4.989868] bec0: 237bc339 0001 [4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 cfc7da50 cfc7d720 c00a4780 [5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 0001 c08256c8 [5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 0001 0002 a193 [5.024414] bf40: 00989680 24101100 0001 cfc7da50 c108cc78 [5.033020] bf60: c00962b0 0002 0001 c108cc78 c00a56f0 [5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 c082a000 c08c8ce8 [5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 c08270f0 c08caf40 c080fdc0 [5.058929] bfc0: c07c3b74 c07c35f0 c080fdc0 [5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 80008074 [5.076171] [] (omap2_gp_timer_set_next_event) from [] (clockevents_program_event+0xc0/0x148) [5.087005] [] (clockevents_program_event) from [] (tick_program_event+0x44/0x54) [5.096771] [] (tick_program_event) from [] (__hrtimer_start_range_ns+0x3c0/0x4a0) [5.106597] [] (__hrtimer_start_range_ns) from [] (hrtimer_start_range_ns+0x24/0x2c) [5.116577] [] (hrtimer_start_range_ns) from [] (tick_nohz_idle_exit+0x140/0x1ec) [5.126342] [] (tick_nohz_idle_exit) from [] (cpu_startup_entry+0xf4/0x2d0) [5.135528] [] (cpu_startup_entry) from [] (start_kernel+0x340/0x3a8) [5.144165] [] (start_kernel) from [<80008074>] (0x80008074) [5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) [5.157470] ---[ end trace f92de024d996d904 ]--- [5.162353] Kernel panic - not syncing: Attempted to kill the idle task! [5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! Actually it just occurred to me that if something broke *wait_target_ready(), we'd expect to see intermittent failures like this, and this series touches *wait_target_ready(). So it might be worth taking a look at that with a magnifying glass to make sure that it's working. I think this is probably something else, and most likely more hideous. The clock source timers are only enabled once during a boot, and they are never idled after that. This error happens almost 5 seconds after the initial module enable...? -Tero -- 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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Paul Walmsley [140919 10:28]: > On Fri, 19 Sep 2014, Paul Walmsley wrote: > > > However, I saw the following crash at boot on 37xxevm during one of > > the boot test. Ran thirty more boot tests afterwards on that board > > and it did not recur. It seems unlikely that the problem is related > > to this series, but looks like we may have some intermittent boot > > failure or race on 37xx :-( > > ... > > > [4.892211] Unhandled fault: external abort on non-linefetch (0x1028) at > > 0xfa318034 > > [4.900299] Internal error: : 1028 [#1] SMP ARM > > [4.905090] Modules linked in: > > [4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > 3.17.0-rc5-12866-g0164b2d #1 > > [4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > > [4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > > [4.928009] LR is at clockevents_program_event+0xc0/0x148 > > [4.933715] pc : []lr : []psr: 0193 > > [4.933715] sp : c082bed8 ip : fp : > > [4.945800] r10: r9 : 24101100 r8 : c0839080 > > [4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 > > [4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 > > [4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM > > Segment kernel > > [4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > > [4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > > [4.985290] Stack: (0xc082bed8 to 0xc082c000) > > [4.989868] bec0: > > 237bc339 0001 > > [4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 cfc7da50 > > cfc7d720 c00a4780 > > [5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > > 0001 c08256c8 > > [5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 0001 > > 0002 a193 > > [5.024414] bf40: 00989680 24101100 0001 cfc7da50 > > c108cc78 > > [5.033020] bf60: c00962b0 0002 0001 > > c108cc78 c00a56f0 > > [5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 c082a000 > > c08c8ce8 > > [5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 c08270f0 > > c08caf40 c080fdc0 > > [5.058929] bfc0: c07c3b74 c07c35f0 > > c080fdc0 > > [5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 80008074 > > > > [5.076171] [] (omap2_gp_timer_set_next_event) from > > [] (clockevents_program_event+0xc0/0x148) > > [5.087005] [] (clockevents_program_event) from [] > > (tick_program_event+0x44/0x54) > > [5.096771] [] (tick_program_event) from [] > > (__hrtimer_start_range_ns+0x3c0/0x4a0) > > [5.106597] [] (__hrtimer_start_range_ns) from [] > > (hrtimer_start_range_ns+0x24/0x2c) > > [5.116577] [] (hrtimer_start_range_ns) from [] > > (tick_nohz_idle_exit+0x140/0x1ec) > > [5.126342] [] (tick_nohz_idle_exit) from [] > > (cpu_startup_entry+0xf4/0x2d0) > > [5.135528] [] (cpu_startup_entry) from [] > > (start_kernel+0x340/0x3a8) > > [5.144165] [] (start_kernel) from [<80008074>] (0x80008074) > > [5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > > [5.157470] ---[ end trace f92de024d996d904 ]--- > > [5.162353] Kernel panic - not syncing: Attempted to kill the idle task! > > [5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the > > idle task! > > Actually it just occurred to me that if something broke > *wait_target_ready(), we'd expect to see intermittent failures like this, > and this series touches *wait_target_ready(). So it might be worth taking > a look at that with a magnifying glass to make sure that it's working. Yes errors like this should not happen. Let's make sure things are working reliably before merging this. 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
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Tero Kristo [140922 06:18]:
> On 09/19/2014 07:30 PM, Paul Walmsley wrote:
> >On Thu, 18 Sep 2014, Tony Lindgren wrote:
> >
> >>* Tero Kristo [140901 11:09]:
> >>>Hi,
> >>>
> >>>This set contains PRCM related cleanups meant for 3.18 merge window.
> >>>These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon
> >>>(http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's
> >>>set is used as basis to avoid merge issues.
> >>>
> >>>Purpose of this work is to eventually convert the PRCM code into a
> >>>separate driver, but this is done in incremental parts as the amount
> >>>of changes is substantial. Expected conclusion of this work is 3.19
> >>>if everything goes fine.
> >>>
> >>>This part of the work mostly moves some of the SoC specific PRCM driver
> >>>calls under generic version of the same, and adds SoC-ops to support
> >>>these on the driver level.
> >>>
> >>>Working branch posted here:
> >>>
> >>>tree: https://github.com/t-kristo/linux-pm.git
> >>>branch: for-v3.18/prcm-cleanup
>
> Hi,
>
> I pushed v2 of this set as 'for-v3.18/prcm-cleanup-v2' to my tree. Basically
> to address the below comments, and additionally I changed a few public cm_*
> api names to omap_cm_* + add the tested-by/acked-by statuses. Tony/Paul, do
> you want me to repost the series, or are you ok with a local diff / pull
> only?
If the changes were minor, at least I'm fine without reposting.
But let's wait to hear from Paul in case he has further comments.
Regards,
Tony
> >>
> >>Paul, any comments on this series?
> >
> >Patches 1, 3, 5, 8, 10, 13, 17, 18, 20, 21, 22, 23, 24 are:
> >
> >Acked-by: Paul Walmsley
>
> Thanks, added acks to v2 patches.
>
> >
> >Here are some specific comments on a few other patches:
> >
> >Regarding patch 7: The kerneldoc-nano function comments are good, but
> >should begin with "/**" rather than "/*". When that's fixed, it can be
> >considered acked by me.
>
> Yea, this was a typo, thanks for noticing.
>
> >
> >Regarding patches 14, 15, 16: Non-static prm_* functions really should
> >start with omap*_ to avoid potential naming conflicts with other drivers
> >when these are moved to drivers/. (Obviously the same would apply for any
> >CM function names in other, future patches.) When that's fixed, it can be
> >considered acked by me.
>
> Ok, changed. Additionally I changed some cm_* prototypes in patches #6, #7
> and #9 to be of form omap_cm_*.
>
> >Regarding patch 25: What are "I/O wakeup gaes" -- gates? When that's
> >fixed, an acked-by for me can be added.
>
> Yes, gates. Fixed.
>
> >Regarding patch 26: It seems wise to ensure that omap_prm_reset_system()
> >ends with a 'while(1) { cpu_relax(); }' or something similar, to ensure
> >that execution flow does not proceed past that point. At that point, it
> >should be possible to remove the "while(1) {}"s from omap44xx_restart(),
> >omap2xxx_restart(), etc. When that's fixed, an acked-by for me can be
> >added.
>
> Ok, changed this also. Added the while(1) cpu_relax(); part to the public
> API, and removed the loops from everywhere else.
>
> >
> >...
> >
> >And some general comments: none of which should probably block this
> >series, but seemed worth noting:
> >
> >Regarding patches 6 and 19: Tero, could you please share the DT node data
> >that you're planning to submit for the PRM, CM1, and CM2 on the OMAP4*
> >platforms? According to the TRM, these are separate IP blocks, with
> >separate OCP header register areas. So these should probably have
> >separate DT nodes, regs, etc. if the DTS files are to match the hardware.
> >The planned DTS data may impact the way these patches are written, at
> >least, if more patches are to be avoided later.
>
> We already have the nodes for these. Check out omap4.dtsi for example, we
> have nodes for prm/cm1/cm2/scrm there already. These were already defined
> when the clock DT data was introduced, and I don't foresee any changes to
> the nodes as of now. The nodes only contain register space info as of now,
> and Nishanth is adding the interrupt property for PRM interrupt purposes,
> but rest of the features are probably going to be hardcoded within the PRCM
> drivers themselves.
>
> If you are interested, feel free to look at for-3.19/prcm-cleanup branch in
> my git tree, this contains the remaining patches I have for PRCM cleanup
> after this set available as of now.
>
> -Tero
>
> >
> >As far as patches 2, 4, 9, 11, and 12 go, I'll let those go without
> >comment.
> >
> >
> >- Paul
> >
>
--
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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On 09/19/2014 07:30 PM, Paul Walmsley wrote:
On Thu, 18 Sep 2014, Tony Lindgren wrote:
* Tero Kristo [140901 11:09]:
Hi,
This set contains PRCM related cleanups meant for 3.18 merge window.
These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon
(http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's
set is used as basis to avoid merge issues.
Purpose of this work is to eventually convert the PRCM code into a
separate driver, but this is done in incremental parts as the amount
of changes is substantial. Expected conclusion of this work is 3.19
if everything goes fine.
This part of the work mostly moves some of the SoC specific PRCM driver
calls under generic version of the same, and adds SoC-ops to support
these on the driver level.
Working branch posted here:
tree: https://github.com/t-kristo/linux-pm.git
branch: for-v3.18/prcm-cleanup
Hi,
I pushed v2 of this set as 'for-v3.18/prcm-cleanup-v2' to my tree.
Basically to address the below comments, and additionally I changed a
few public cm_* api names to omap_cm_* + add the tested-by/acked-by
statuses. Tony/Paul, do you want me to repost the series, or are you ok
with a local diff / pull only?
Paul, any comments on this series?
Patches 1, 3, 5, 8, 10, 13, 17, 18, 20, 21, 22, 23, 24 are:
Acked-by: Paul Walmsley
Thanks, added acks to v2 patches.
Here are some specific comments on a few other patches:
Regarding patch 7: The kerneldoc-nano function comments are good, but
should begin with "/**" rather than "/*". When that's fixed, it can be
considered acked by me.
Yea, this was a typo, thanks for noticing.
Regarding patches 14, 15, 16: Non-static prm_* functions really should
start with omap*_ to avoid potential naming conflicts with other drivers
when these are moved to drivers/. (Obviously the same would apply for any
CM function names in other, future patches.) When that's fixed, it can be
considered acked by me.
Ok, changed. Additionally I changed some cm_* prototypes in patches #6,
#7 and #9 to be of form omap_cm_*.
Regarding patch 25: What are "I/O wakeup gaes" -- gates? When that's
fixed, an acked-by for me can be added.
Yes, gates. Fixed.
Regarding patch 26: It seems wise to ensure that omap_prm_reset_system()
ends with a 'while(1) { cpu_relax(); }' or something similar, to ensure
that execution flow does not proceed past that point. At that point, it
should be possible to remove the "while(1) {}"s from omap44xx_restart(),
omap2xxx_restart(), etc. When that's fixed, an acked-by for me can be
added.
Ok, changed this also. Added the while(1) cpu_relax(); part to the
public API, and removed the loops from everywhere else.
...
And some general comments: none of which should probably block this
series, but seemed worth noting:
Regarding patches 6 and 19: Tero, could you please share the DT node data
that you're planning to submit for the PRM, CM1, and CM2 on the OMAP4*
platforms? According to the TRM, these are separate IP blocks, with
separate OCP header register areas. So these should probably have
separate DT nodes, regs, etc. if the DTS files are to match the hardware.
The planned DTS data may impact the way these patches are written, at
least, if more patches are to be avoided later.
We already have the nodes for these. Check out omap4.dtsi for example,
we have nodes for prm/cm1/cm2/scrm there already. These were already
defined when the clock DT data was introduced, and I don't foresee any
changes to the nodes as of now. The nodes only contain register space
info as of now, and Nishanth is adding the interrupt property for PRM
interrupt purposes, but rest of the features are probably going to be
hardcoded within the PRCM drivers themselves.
If you are interested, feel free to look at for-3.19/prcm-cleanup branch
in my git tree, this contains the remaining patches I have for PRCM
cleanup after this set available as of now.
-Tero
As far as patches 2, 4, 9, 11, and 12 go, I'll let those go without
comment.
- Paul
--
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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On 09/18/2014 02:16 PM, Tony Lindgren wrote: > * Tony Lindgren [140918 10:17]: >> * Tero Kristo [140901 11:09]: >>> Hi, >>> >>> This set contains PRCM related cleanups meant for 3.18 merge window. >>> These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon >>> (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's >>> set is used as basis to avoid merge issues. >>> >>> Purpose of this work is to eventually convert the PRCM code into a >>> separate driver, but this is done in incremental parts as the amount >>> of changes is substantial. Expected conclusion of this work is 3.19 >>> if everything goes fine. >>> >>> This part of the work mostly moves some of the SoC specific PRCM driver >>> calls under generic version of the same, and adds SoC-ops to support >>> these on the driver level. >>> >>> Working branch posted here: >>> >>> tree: https://github.com/t-kristo/linux-pm.git >>> branch: for-v3.18/prcm-cleanup >> >> Paul, any comments on this series? > > Just gave this branch a quick try, it seems to work with off-idle > for me when merged with current linux-omap master branch. The following > merge resolution is needed because of the recent pre es3.1 fix though. > > I've pushed out this merged with all the other pending patches into > omap-for-v3.18/tmp-merge-2014-09-18. > > Nishant, care to give it a try and check your recent PM related > changes work with it? > Sure. Sorry about the delay.. needed to find some workarounds for working with my board farm.. Tested-by: Nishanth Menon Based on: omap-for-v3.18/tmp-merge-2014-09-18 0164b2d Merge branch 'omap-for-v3.18/prcm' into omap-for-v3.18/tmp-merge Test #1: basic testing Added 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d BASIC boot 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zy9OUOMM 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2t0JaiHYf 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2SRkMMQwp 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20T0sq5dp 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2AVYqDVBf 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s213N14B9r 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21yyMkFRS 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s2SYJOHRwI 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s214QDgb06 10: beaglebone: Boot PASS: http://slexy.org/raw/s21SOLcjMD 11: craneboard: Boot PASS: http://slexy.org/raw/s218cXoYSl 12: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21BAnAW8N 13: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21kf4G5Sh 14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s21QIGwFOM 15: n900: Boot PASS: http://slexy.org/raw/s21T5xECo2 16: omap5-evm: Boot PASS: http://slexy.org/raw/s20qxa3iPw 17: pandaboard-es: Boot PASS: http://slexy.org/raw/s2Fh0hMW7n 18: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2vqUc528i 19:sdp2430: Boot PASS: http://slexy.org/raw/s21gAsEAeD 20:sdp3430: Boot PASS: http://slexy.org/raw/s2dvThSn5D TOTAL = 20 boards, Booted Boards = 19, No Boot boards = 1 Test #2: PM test (cpufreq/cpuidle/suspend-resume where applicable) Testing script: (http://slexy.org/view/s21SRQehwu) Added the following patches: 59bf40d ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support (discussion still going on https://patchwork.kernel.org/patch/4764661/ - but good to know if it still continues to work with PRM changes). 69c6133 HACK: Makefile: Build a uImage with dtb already appended (for legacy boards) b854ca8 gpio: omap: Fix interrupt names (https://patchwork.kernel.org/patch/4854511/) c50fc8b pinctrl: single: AM437x: Add pinctrl compatibility 37d17bf pinctrl: single: Add DRA7 pinctrl compatibility 74121c6 pinctrl: bindings: Add OMAP pinctrl binding (all of the above are in linux-next) efb2486 clk: prevent erronous parsing of children during rate change b92ac70 clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate 96e8b6b clk: ti: divider: Provide error check for incoming parameters in set_rate (all above picked up by mike) 92e5e74 ARM: OMAP2+ / pm_debug: add support for wakeup_timer configuration (wakeup timer for testing purposes - remote boards) with these: commit 0164b2dbe83e885a53b0c9a99a508bdbfdf7ee6d + Additional patches basic PM test 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2xRMuVHvj 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2qEHyI9Rs 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2Vptpboop 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21TKVsyet 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20KGye4N9 6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s201uuCOp2 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21ChQP74I 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20oagBAsl 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2VT200vL0 10: beaglebone: Boot PASS: http://slexy.org/raw/s20raoHSya 11: craneboard:
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Fri, 19 Sep 2014, Paul Walmsley wrote: > However, I saw the following crash at boot on 37xxevm during one of > the boot test. Ran thirty more boot tests afterwards on that board > and it did not recur. It seems unlikely that the problem is related > to this series, but looks like we may have some intermittent boot > failure or race on 37xx :-( ... > [4.892211] Unhandled fault: external abort on non-linefetch (0x1028) at > 0xfa318034 > [4.900299] Internal error: : 1028 [#1] SMP ARM > [4.905090] Modules linked in: > [4.908325] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.17.0-rc5-12866-g0164b2d #1 > [4.916320] task: c0835db0 ti: c082a000 task.ti: c082a000 > [4.922027] PC is at omap2_gp_timer_set_next_event+0x24/0x78 > [4.928009] LR is at clockevents_program_event+0xc0/0x148 > [4.933715] pc : []lr : []psr: 0193 > [4.933715] sp : c082bed8 ip : fp : > [4.945800] r10: r9 : 24101100 r8 : c0839080 > [4.951324] r7 : 0001 r6 : 237bc339 r5 : 009f r4 : 3d9759e7 > [4.958190] r3 : fa318034 r2 : c08cb920 r1 : 0003 r0 : fec1 > [4.965087] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment > kernel > [4.972900] Control: 10c5387d Table: 80004019 DAC: 0015 > [4.978942] Process swapper/0 (pid: 0, stack limit = 0xc082a248) > [4.985290] Stack: (0xc082bed8 to 0xc082c000) > [4.989868] bec0: > 237bc339 0001 > [4.998504] bee0: 0001 24101100 0001 cfc7d6c8 0001 cfc7da50 > cfc7d720 c00a4780 > [5.007141] bf00: c00962b0 cfc7d720 c0096180 0001 > 0001 c08256c8 > [5.015777] bf20: c082a000 c08256c8 c00962b0 237b4c04 0001 > 0002 a193 > [5.024414] bf40: 00989680 24101100 0001 cfc7da50 > c108cc78 > [5.033020] bf60: c00962b0 0002 0001 > c108cc78 c00a56f0 > [5.041656] bf80: 0002 237b4c04 0001 c08c8ce8 c082a000 > c08c8ce8 > [5.050292] bfa0: c08329dc c0832978 cfc7f0f8 c0072808 c0559928 c08270f0 > c08caf40 c080fdc0 > [5.058929] bfc0: c07c3b74 c07c35f0 > c080fdc0 > [5.067535] bfe0: c08cb154 c0832968 c080fdbc c083763c 80004059 80008074 > > [5.076171] [] (omap2_gp_timer_set_next_event) from [] > (clockevents_program_event+0xc0/0x148) > [5.087005] [] (clockevents_program_event) from [] > (tick_program_event+0x44/0x54) > [5.096771] [] (tick_program_event) from [] > (__hrtimer_start_range_ns+0x3c0/0x4a0) > [5.106597] [] (__hrtimer_start_range_ns) from [] > (hrtimer_start_range_ns+0x24/0x2c) > [5.116577] [] (hrtimer_start_range_ns) from [] > (tick_nohz_idle_exit+0x140/0x1ec) > [5.126342] [] (tick_nohz_idle_exit) from [] > (cpu_startup_entry+0xf4/0x2d0) > [5.135528] [] (cpu_startup_entry) from [] > (start_kernel+0x340/0x3a8) > [5.144165] [] (start_kernel) from [<80008074>] (0x80008074) > [5.151031] Code: 13a0c000 0a04 ee07cfba e592301c (e5931000) > [5.157470] ---[ end trace f92de024d996d904 ]--- > [5.162353] Kernel panic - not syncing: Attempted to kill the idle task! > [5.169433] ---[ end Kernel panic - not syncing: Attempted to kill the > idle task! Actually it just occurred to me that if something broke *wait_target_ready(), we'd expect to see intermittent failures like this, and this series touches *wait_target_ready(). So it might be worth taking a look at that with a magnifying glass to make sure that it's working. - Paul -- 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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote: > * Tony Lindgren [140918 10:17]: > > * Tero Kristo [140901 11:09]: > > > Hi, > > > > > > This set contains PRCM related cleanups meant for 3.18 merge window. > > > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > > > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > > > set is used as basis to avoid merge issues. > > > > > > Purpose of this work is to eventually convert the PRCM code into a > > > separate driver, but this is done in incremental parts as the amount > > > of changes is substantial. Expected conclusion of this work is 3.19 > > > if everything goes fine. > > > > > > This part of the work mostly moves some of the SoC specific PRCM driver > > > calls under generic version of the same, and adds SoC-ops to support > > > these on the driver level. > > > > > > Working branch posted here: > > > > > > tree: https://github.com/t-kristo/linux-pm.git > > > branch: for-v3.18/prcm-cleanup > > > > Paul, any comments on this series? > > Just gave this branch a quick try, it seems to work with off-idle > for me when merged with current linux-omap master branch. The following > merge resolution is needed because of the recent pre es3.1 fix though. > > I've pushed out this merged with all the other pending patches into > omap-for-v3.18/tmp-merge-2014-09-18. Ran the tests here, they seemed to pass: http://www.pwsan.com/omap/testlogs/tmp-merge-2014-09-18/20140918132302/ However, I saw the following crash at boot on 37xxevm during one of the boot test. Ran thirty more boot tests afterwards on that board and it did not recur. It seems unlikely that the problem is related to this series, but looks like we may have some intermittent boot failure or race on 37xx :-( - Paul Texas Instruments X-Loader 1.47 (Jan 14 2011 - 15:43:28) Starting X-loader on MMC Reading boot sector 212836 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... U-Boot 2010.06 (Jan 14 2011 - 15:43:45) OMAP34xx/35xx-GP ES2.1, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 512 MiBhelp |230400 8N1 | NOR | script /home/p | VT102 | Offline In:serial Out: serial Err: serial Read back SMSC id 0x9220 Die ID #368000229ff8016071640902c013 Net: smc911x-0 Hit any key to stop autoboot: 0 OMAP3_EVM # OMAP3_EVM # OMAP3_EVM # dhcp smc911x: detected LAN9220 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:99:42 BOOTP broadcast 1 DHCP client bound to address 192.168.57.131 Using smc911x-0 device TFTP from server 192.168.57.1; our IP address is 192.168.57.131 Filename 'uImage-dtb.omap3-evm-37xx'. Load address: 0x8200 Loading: # # # # # # # # # # # # # # done Bytes transferred = 4452813 (43f1cd hex) OMAP3_EVM # setenv bootargs console=ttyO0,115200n8 ignore_loglevel earlyprintk root=/dev/nfs nfsroot=192.168.57.1:/srv/nfs4/rootfs2 nfsrootdebug ip=dhcp init=/bin/sh OMAP3_EVM # OMAP3_EVM # bootm ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux- Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4452749 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.17.0-rc5-12866-g0164b2d (paul@nozomi) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Thu Sep 18 13:29:12 MDT 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI OMAP37XX EVM (TMDSEVM3730) [0.00] debug: ignoring loglevel setting. [0.00] cma: Reserved 16 MiB at 8e80 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c08c5480,
Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote:
> * Tero Kristo [140901 11:09]:
> > Hi,
> >
> > This set contains PRCM related cleanups meant for 3.18 merge window.
> > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon
> > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's
> > set is used as basis to avoid merge issues.
> >
> > Purpose of this work is to eventually convert the PRCM code into a
> > separate driver, but this is done in incremental parts as the amount
> > of changes is substantial. Expected conclusion of this work is 3.19
> > if everything goes fine.
> >
> > This part of the work mostly moves some of the SoC specific PRCM driver
> > calls under generic version of the same, and adds SoC-ops to support
> > these on the driver level.
> >
> > Working branch posted here:
> >
> > tree: https://github.com/t-kristo/linux-pm.git
> > branch: for-v3.18/prcm-cleanup
>
> Paul, any comments on this series?
Patches 1, 3, 5, 8, 10, 13, 17, 18, 20, 21, 22, 23, 24 are:
Acked-by: Paul Walmsley
Here are some specific comments on a few other patches:
Regarding patch 7: The kerneldoc-nano function comments are good, but
should begin with "/**" rather than "/*". When that's fixed, it can be
considered acked by me.
Regarding patches 14, 15, 16: Non-static prm_* functions really should
start with omap*_ to avoid potential naming conflicts with other drivers
when these are moved to drivers/. (Obviously the same would apply for any
CM function names in other, future patches.) When that's fixed, it can be
considered acked by me.
Regarding patch 25: What are "I/O wakeup gaes" -- gates? When that's
fixed, an acked-by for me can be added.
Regarding patch 26: It seems wise to ensure that omap_prm_reset_system()
ends with a 'while(1) { cpu_relax(); }' or something similar, to ensure
that execution flow does not proceed past that point. At that point, it
should be possible to remove the "while(1) {}"s from omap44xx_restart(),
omap2xxx_restart(), etc. When that's fixed, an acked-by for me can be
added.
...
And some general comments: none of which should probably block this
series, but seemed worth noting:
Regarding patches 6 and 19: Tero, could you please share the DT node data
that you're planning to submit for the PRM, CM1, and CM2 on the OMAP4*
platforms? According to the TRM, these are separate IP blocks, with
separate OCP header register areas. So these should probably have
separate DT nodes, regs, etc. if the DTS files are to match the hardware.
The planned DTS data may impact the way these patches are written, at
least, if more patches are to be avoided later.
As far as patches 2, 4, 9, 11, and 12 go, I'll let those go without
comment.
- Paul
--
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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
On Thu, 18 Sep 2014, Tony Lindgren wrote: > * Tero Kristo [140901 11:09]: > > Hi, > > > > This set contains PRCM related cleanups meant for 3.18 merge window. > > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > > set is used as basis to avoid merge issues. > > > > Purpose of this work is to eventually convert the PRCM code into a > > separate driver, but this is done in incremental parts as the amount > > of changes is substantial. Expected conclusion of this work is 3.19 > > if everything goes fine. > > > > This part of the work mostly moves some of the SoC specific PRCM driver > > calls under generic version of the same, and adds SoC-ops to support > > these on the driver level. > > > > Working branch posted here: > > > > tree: https://github.com/t-kristo/linux-pm.git > > branch: for-v3.18/prcm-cleanup > > Paul, any comments on this series? Yeah, I'll send a few comments today. - Paul -- 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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Tony Lindgren [140918 10:17]:
> * Tero Kristo [140901 11:09]:
> > Hi,
> >
> > This set contains PRCM related cleanups meant for 3.18 merge window.
> > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon
> > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's
> > set is used as basis to avoid merge issues.
> >
> > Purpose of this work is to eventually convert the PRCM code into a
> > separate driver, but this is done in incremental parts as the amount
> > of changes is substantial. Expected conclusion of this work is 3.19
> > if everything goes fine.
> >
> > This part of the work mostly moves some of the SoC specific PRCM driver
> > calls under generic version of the same, and adds SoC-ops to support
> > these on the driver level.
> >
> > Working branch posted here:
> >
> > tree: https://github.com/t-kristo/linux-pm.git
> > branch: for-v3.18/prcm-cleanup
>
> Paul, any comments on this series?
Just gave this branch a quick try, it seems to work with off-idle
for me when merged with current linux-omap master branch. The following
merge resolution is needed because of the recent pre es3.1 fix though.
I've pushed out this merged with all the other pending patches into
omap-for-v3.18/tmp-merge-2014-09-18.
Nishant, care to give it a try and check your recent PM related
changes work with it?
Regards,
Tony
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@@ -30,6 -30,12 +30,11 @@@
#include "cm3xxx.h"
#include "cm-regbits-34xx.h"
+ static void omap3xxx_prm_read_pending_irqs(unsigned long *events);
+ static void omap3xxx_prm_ocp_barrier(void);
+ static void omap3xxx_prm_save_and_clear_irqen(u32 *saved_mask);
+ static void omap3xxx_prm_restore_irqen(u32 *saved_mask);
-static void omap3xxx_prm_reconfigure_io_chain(void);
+
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
OMAP_PRCM_IRQ("wkup", 0, 0),
OMAP_PRCM_IRQ("io", 9, 1),
@@@ -391,9 -382,9 +396,9 @@@ void omap3430_pre_es3_1_reconfigure_io_
* I/O wakeup gates are aligned with the current mux settings. Works
* by asserting WUCLKIN, waiting for WUCLKOUT to be asserted, and then
* deasserting WUCLKIN and clearing the ST_IO_CHAIN WKST bit. No
- * return value.
+ * return value. These registers are only available in 3430 es3.1 and later.
*/
- void omap3_prm_reconfigure_io_chain(void)
-static void omap3xxx_prm_reconfigure_io_chain(void)
++static void omap3_prm_reconfigure_io_chain(void)
{
int i = 0;
--
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 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window
* Tero Kristo [140901 11:09]: > Hi, > > This set contains PRCM related cleanups meant for 3.18 merge window. > These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > (http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > set is used as basis to avoid merge issues. > > Purpose of this work is to eventually convert the PRCM code into a > separate driver, but this is done in incremental parts as the amount > of changes is substantial. Expected conclusion of this work is 3.19 > if everything goes fine. > > This part of the work mostly moves some of the SoC specific PRCM driver > calls under generic version of the same, and adds SoC-ops to support > these on the driver level. > > Working branch posted here: > > tree: https://github.com/t-kristo/linux-pm.git > branch: for-v3.18/prcm-cleanup Paul, any comments on this series? Regards, Tony > Testing done: > am335x-evm: boot > am335x-bone: boot > am335x-boneblack: boot > am3517-evm: boot > am437x-gp-evm: boot > omap3-beagle-xm: boot > omap3-beagle: boot suspend/resume (ret/off) > dra7-evm: boot (with additional clock patches to fix boot issues) > omap3-n900: boot > omap5-uevm: boot > omap4-panda-es: boot suspend/resume (ret) > omap2430-sdp: boot > > -Tero > -- 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
