[PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled

[Tony Lindgren]

* Tony Lindgren <tony at atomide.com> [140515 17:14]:
> * Tony Lindgren <tony at atomide.com> [140514 16:32]:
> > * Tony Lindgren <tony at atomide.com> [140514 13:57]:
> > > * Daniel Lezcano <daniel.lezcano at linaro.org> [140514 13:02]:
> > > > 
> > > > So the broadcast timer does not operate with this revert. Moreover, I am not
> > > > sure reverting this patch is the right solution.
> > > 
> > > OK I'll hold on sending anything until there's some conclusion.
> > > 
> > > Are you able to reproduce the problem with current Linux next?
> > 
> > BTW, I'm also noticing now hangs on omap3 with my PM patches
> > on v3.15-rc4 that seem similar to the panda cpuidle hang.
> > 
> > The hangs on omap3 do not happen on my v3.14 based branch, so
> > I'm wondering if there are some recent cpuidle regressions too
> > in play?
> 
> Looks like the omap3 idle hang is caused by commit 6ddeb6d84459
> (dmaengine: omap-dma: move IRQ handling to omap-dma). This may
> not be related to omap4 cpu_idle hang, but it might.
> 
> I'm trying to figure out if it's related to something like
> omap_dma_global_context_save and omap_dma_global_context_restore.
> 
> Meanwhile, to test the DMA changes have an effect on the omap4
> cpu_idle issue, you can try reverting the following two patches:
> 
> aa4c5b962a7a dmaengine: omap-dma: more consolidation of CCR register setup
> 6ddeb6d84459 dmaengine: omap-dma: move IRQ handling to omap-dma

OK with the above reverted still seeing hangs on my panda es.
So it seems the cpu_idle issue is different.

Regards,

Tony