* [email protected] <[email protected]> [100309 00:20]: > > > >Changes in wakeup state should not be directly correlated to interrupt > >enabled GPIOs. Rather, this should only be done for GPIOs that are > >explicitly wakeup enabled (via enable_irq_wake(), which in turn > >calls gpio_wake_enable()). > > This logic somehow escapes me... I would guess drivers should not care during > dynamic idle whether the device is in off/ret/ina and interrupts should just > work. This is done to make this happen. Also, I understood that gpio wakeup > logic is needed for the suspend wakeup, which is quite different from dynamic > idle wakeup. > > However, if this is intended behavior for the kernel, then I will accept it. > You are saying the code below should be moved into the gpio_wake_enable() / > disable() calls?
I agree. I'd assume during the idle modes we want everything to automatically wake the system up. Otherwise we again have non-standard Linux behaviour that's mysterious to track down. The enable_irq_wake should only be needed for suspend states. > >This change isn't explained in the changelog and appears unrelated to > >this patch. > > The reason for this change is that we need the gpio->pad mapping early now to > enable wakeups properly. Otherwise some components can enable gpio interrupts > early in the boot cycle and they will miss their wakeup setting because the > map does not exist yet. I think another way to do this would be to enable > wakeups for all enabled interrupts during the omap3_gpio_pads_init(). Don't have the original patch, but it smells like you're trying to do gpio to mux register mapping? If so, your already have that available via omap_mux_get/set_gpio() for 34xx in the new muxcode already in mainline. Those work even if you don't have CONFIG_OMAP_MUX set. And I still need to convert 24xx to the new mux code so we can get rid of the old omap1 style code.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
