"ext Woodruff, Richard" <r-woodruff2@xxxxxx> writes: >> > >> > For sure save/restore of IRQENABLE is needed. Our Labrador board >> > which has Ethernet on per-gpio would stop to function after an OFF >> > mode transition with out this save and restore (using CDP reference >> > code). >> >> I think this is not related to OFF mode, because OFF state is not >> used on the boot. This problem seems to disappear when boot is >> done and C6 state is started to be used. Currently it seems to me that >> this problem exists if using states where mpu is in sleep state and >> core is active (C2, C3). This is under investigation. Is there any >> known restrictions in GPIO1 module wake-up capability when mpu is in >> sleep and core active? Any other known restrictions? > > If core is ACTIVE and irq is enabled at MPU then everything should work on any gpio block. > > If the core is INACTIVE (which is possible with hardware auto's on) then the same holds from above IF you have also enabled all wakeup mechanisms. > > If the core is in RET/OFF only selected gpio's will wake the system up. IIRC not all GPIO1 even are capable to wake you from this level of sleep. I don't recall the list. > > You do have the ability to use an IO PAD wake up to wake from those while in RET/OFF. However, I don't believe you will get an IO pad when you in INACTIVE/ACTIVE. You do have to program for this event to be generated at the pad and in the wakeup domain control registers. > > Questions might be: > - Has the prcm init happened and is the entire wake up path been setup? > > [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. > > Regards, > Richard W. > -- 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
