Re: [PATCH 00/11] OMAP3 CPUidle patches

[jouni.hogander@nokia.com (Högander Jouni)]

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