Hi Tero, Tero Kristo <t-kristo@xxxxxx> writes: > On Wed, 2011-09-07 at 19:59 +0200, Hilman, Kevin wrote: >> Tero Kristo <t-kristo@xxxxxx> writes: [...] >> > After thinking about this problem and looking at possible ways to fix >> > it, I am planning to change the PRCM chain handler to be a driver, which >> > gets suspended along with the rest of the system. This means the PRCM >> > interrupt would get disabled also during this time, and it would be >> > enabled in the driver->complete() call, which should happen after rest >> > of the drivers have been able to enable their PM runtime in the >> > driver->resume() call chain. Do you see any problems with this approach? >> >> How will the system wakeup from retention or off-mode if the PRCM IRQ is >> disabled? > > This is actually some sort of an issue with retention if we disable PRCM > irq completely, off works purely with wakeup signals as we come out of > reset. Anyway, I did some experimentation with this, and OMAP3 is able > to wake up if we leave WKUP irq up, but disable IO chain irq. IO chain > events seem to trigger a WKUP event also always, we just postpone the > processing of IO chain until later. I had to also split the wakeup > clearing for OMAP3 into 2 parts, one part handles wakeups and another IO > chain. Currently both IO chain and WKUP are acked by the same handler. Here's another option, which is kind of a hybrid of what's been discussed so far. The PRCM driver would leave the IRQs enabled during suspend, but would just delay delivering them to the drivers. IOW, handle/clear the PRCM IRQ normally, but delay delivery of the *device* IRQ until the ->complete callback of the PRCM driver. Doing this ensures all the drivers are resumed before any device IRQ is delivered, and doesn't require any additional queuing of events in the drivers. Kevin -- 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
