* Tony Lindgren <tony@xxxxxxxxxxx> [140515 17:14]: > * Tony Lindgren <tony@xxxxxxxxxxx> [140514 16:32]: > > * Tony Lindgren <tony@xxxxxxxxxxx> [140514 13:57]: > > > * Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
