> >> When OFF/RET mode is selected IO pad is enabled for the port
> wakeup.
> >>
> >> I have seen this in CDP reference code. Is there some specific
> reason
> >> why this is enabled dynamically in code?
> >
> > Not that I am aware.
> >
> > Do you think there is a need to toggle it? Today only the global
> > IOPAD enable is toggled (which is necessary for pad state latching).
>
> No, I might have seen this global IOPAD enable. This is valuable
> information. Currently in linux-omap setting IOPAD enable bit is done
> on initialization. We haven't noticed any problems this far, but this
> feature haven't been used too much. So probably we have been just
> lucky?
The TRM does highlight this procedure of set-before-wake and clear-after-wake in several spots. Search on PM_WKEN_WKUP.
I think I may have not worded that completely right. To clarify, it was my understanding that the wakeup event generated by a pad event wouldn't be cleared with out the toggle.
After you wake up you can read pad status to find out which ball was responsible for the wakeup event. After your done inspecting them, use the toggle to clear it.
Each wakeup capable ball at MUX register has a status bit you read to see if it was the one which woke you up (if you care). Unlike say an IRQ register status register there is no way to clear this at that interface. Note there is no selectable polarity for that pin, so status reflects a change from latched state at sleep.
What is clearly written somewhere is the wake up daisy chain is enabled by turning it on, and disabled and _reset_ at turn off time.
The actual state latching happens at time of transition to sleep. The current level is captured, current padconfs saved into wakeup domain scratch memory and, wakeup armed. On event it all unwinds.
Regards,
Richard W.
Regards,
Richard W.
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
