"ext Woodruff, Richard" <r-woodruff2@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
