Re: [PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window

2014-10-03 Thread Tony Lindgren
* 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

2014-10-03 Thread Felipe Balbi
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

2014-10-02 Thread Felipe Balbi
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

2014-10-02 Thread Tony Lindgren
* 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

2014-10-02 Thread Felipe Balbi
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

2014-10-02 Thread Tony Lindgren
* 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

2014-10-02 Thread Tony Lindgren
* 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

2014-09-24 Thread Tero Kristo

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

2014-09-23 Thread Tony Lindgren
* 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

2014-09-23 Thread Tony Lindgren
* 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

2014-09-22 Thread Tero Kristo

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

2014-09-19 Thread Nishanth Menon
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

2014-09-19 Thread Paul Walmsley
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

2014-09-19 Thread Paul Walmsley
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

2014-09-19 Thread Paul Walmsley
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

2014-09-19 Thread Paul Walmsley
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

2014-09-18 Thread Tony Lindgren
* 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

2014-09-18 Thread Tony Lindgren
* 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


[PATCH 00/26] ARM: OMAP2+: PRCM cleanups for 3.18 merge window

2014-09-01 Thread Tero Kristo
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

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