"ext Woodruff, Richard" <[EMAIL PROTECTED]> writes: >> > [x] Has anyone fixed the broken gpio wakeup enable code? >> > Right now this might even kill you as it will clear you >> > wakeup enable register. This could stop you from waking >> > from a partially idle/clock stop condition on the L3? >> >> The problem was actually related to this. There is those >> gpio_prepare_* >> and gpio_resume_* functions which were not run. For some reason >> next_state for powerdomains doesn't update correctly before hw_sup >> mode is disabled. This caused problem that cpuidle thinks that core is >> entering ON state, while it was actually entering state written in >> omap3_pm_init. Now as cpuidle was thinking that core is not entering >> any sleep state it didn't run gpio_prepare_* and gpio_resume_* >> functions. This caused that interrupt was not generated for that gpio >> used by eth chip. >> >> This was fixed in my patches by disabling hw_sup mode before writing >> next_state and then re-enable it. Those patches are also writing next >> state if CORE next state is ON. > > Ok. As I sent in my mail a couple weeks back. The clearing of wakeup events > at GPIOs when the CORE hits INACTIVE might result in windows of you not > waking up, especially with dynamic tick in the system. I would guess the > windows would be around boot & suspend resume. > > It is not so clear if gpio that hack is even needed on OMAP3. There is some > warning about spurious interrupts when going to RET/OFF for OMAP2. I don't > recall for OMAP3. didn't those prepare functions dink with wake up masks in > fear of spurious interrupts. So, wasn't the result for you the opposite, it > kept you from waking, instead of suppressing extra wakes? > > Did you fix the OMAP2 GPIO wakeup mask in use at least? The code > had a hardcoded mask based on OMAP2 wakeup capable gpios which don't > apply to omap3.
No I haven't modified that code. I have begun to use it before retention because it is under #if defined(CONFIG_ARCH_OMAP34XX) statement and used in case of omap2. Maybe we could stop using it in case of omap3 at least this comment in gpio.c supports this: "See OMAP2420 Errata item 1.101"? Seems to be just legacy code from omap2. -- Jouni Högander -- 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
