wake up from a serial port

wake up from a serial port

[Budhee Jamaich]

hello list,

i am working on 2430 and I need to enable
wakeup from a serial port.

a patch which does this very thing has just been posted on lkml:
http://article.gmane.org/gmane.linux.kernel/574545

is it relevant to me ?

or is there already a way to do that ?

thank you very much
budhee

Re: wake up from a serial port

[Tony Lindgren]

* Budhee Jamaich <budheej@gmail.com> [070827 00:00]:
> hello list,
> 
> i am working on 2430 and I need to enable
> wakeup from a serial port.
> 
> a patch which does this very thing has just been posted on lkml:
> http://article.gmane.org/gmane.linux.kernel/574545
> 
> is it relevant to me ?
> 
> or is there already a way to do that ?

You also need to use the omap serial wake-up events, or mux rx pin
temporarily to a wake-up capable GPIO pin.

Tony

Re: wake up from a serial port

[Budhee Jamaich]

On 8/27/07, Tony Lindgren <tony@atomide.com> wrote:
> * Budhee Jamaich <budheej@gmail.com> [070827 00:00]:
> > i am working on 2430 and I need to enable
> > wakeup from a serial port.
> >
> > a patch which does this very thing has just been posted on lkml:
> > http://article.gmane.org/gmane.linux.kernel/574545
> >
> > is it relevant to me ?
> >
> > or is there already a way to do that ?
>
> You also need to use the omap serial wake-up events, or mux rx pin
> temporarily to a wake-up capable GPIO pin.

Are there any examples how to do either of these ?

If I mux the rx pin to a wake-up capable GPIO pin - should I still apply the
patch I mentioned above ?

(And how can I do this muxing ? Is there an API for that ?)

Thank you very much Tony.

Budhee

Re: wake up from a serial port

[Tony Lindgren]

* Budhee Jamaich <budheej@gmail.com> [070827 01:38]:
> On 8/27/07, Tony Lindgren <tony@atomide.com> wrote:
> > * Budhee Jamaich <budheej@gmail.com> [070827 00:00]:
> > > i am working on 2430 and I need to enable
> > > wakeup from a serial port.
> > >
> > > a patch which does this very thing has just been posted on lkml:
> > > http://article.gmane.org/gmane.linux.kernel/574545
> > >
> > > is it relevant to me ?
> > >
> > > or is there already a way to do that ?
> >
> > You also need to use the omap serial wake-up events, or mux rx pin
> > temporarily to a wake-up capable GPIO pin.
> 
> Are there any examples how to do either of these ?

Well it used to work at least for 5912OSK. Maybe grep for 
CONFIG_OMAP_SERIAL_WAKE.

> If I mux the rx pin to a wake-up capable GPIO pin - should I still apply the
> patch I mentioned above ?

That means you still have to have the functional clock for the UART
on, which will block omap retention. So using the async GPIO wake-up
events will be better.

> (And how can I do this muxing ? Is there an API for that ?)

See CONFIG_OMAP_SERIAL_WAKE.

> Thank you very much Tony.

No problem, if you get it working on 2430, please send patches :)

BTW, I never got the 2420 serial wake events to work, maybe they
need separate interrupt handlers registered. But the GPIO trick
should still work even if the serial wake-up events won't work.

Regards,

Tony

RE: wake up from a serial port

[Woodruff, Richard]

> > > You also need to use the omap serial wake-up events, or mux rx pin
> > > temporarily to a wake-up capable GPIO pin.
> >
> > Are there any examples how to do either of these ?

This is necessary to get a wake up on the RX ball if you are in
retention. IE non-functional mode.  In effect it is a GPIO wake up not a
serial one.

If you want to wake up from UART from a functional mode, then having
that patch is fine, but you still need to do some work on the OMAP side
to link the module wake up into the PRCM wake up mechanism.

Then needs parallel what is necessary for the GPIO wake up.  The same
kind of thing can be said for USB.  If you want to go to a low power
state but have USB still able to respond to events, you need to make USB
bus suspend work so its capable of asserting its mstandby signal
properly and you must also do the linkage into the PRCM.

> Well it used to work at least for 5912OSK. Maybe grep for
> CONFIG_OMAP_SERIAL_WAKE.
> 
> > If I mux the rx pin to a wake-up capable GPIO pin - should I still
apply
> the
> > patch I mentioned above ?

I doubt it would be necessary.  It really depends on what level you how
to sleep to and what functionally you need at wake up.

If its ok to loose the first character perhaps two and consider them
wake up events then going GPIO is likely fine.  You must think about how
its all connected.  You may need your DMA handsake lines set with
something similar.

> That means you still have to have the functional clock for the UART
> on, which will block omap retention. So using the async GPIO wake-up
> events will be better.
> 
> > (And how can I do this muxing ? Is there an API for that ?> 
> See CONFIG_OMAP_SERIAL_WAKE.
> 
> > Thank you very much Tony.
> 
> No problem, if you get it working on 2430, please send patches :)
> 
> BTW, I never got the 2420 serial wake events to work, maybe they
> need separate interrupt handlers registered. But the GPIO trick
> should still work even if the serial wake-up events won't work.

These in 2420 can't wake core from RETETION.  They can wake the core
from  clockstop.

I'll throw rough numbers out for (chip) each domain has its own
combination.  Each lower state requires the previous state to be hit all
at 1.05v. clcokstop=~1.2mA, ~retention=150uA, off=~50uA.  Clock stop can
be higher depending on the 'partial' activity necessary, and perhaps
also lower.

Regards,
Richard W.

Re: wake up from a serial port

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [070827 05:21]:
> > 
> > BTW, I never got the 2420 serial wake events to work, maybe they
> > need separate interrupt handlers registered. But the GPIO trick
> > should still work even if the serial wake-up events won't work.
> 
> These in 2420 can't wake core from RETETION.  They can wake the core
> from  clockstop.

OK, thanks that explains. So multiplexing the rx lines for GPIO
temporarily is the way to go then.

> I'll throw rough numbers out for (chip) each domain has its own
> combination.  Each lower state requires the previous state to be hit all
> at 1.05v. clcokstop=~1.2mA, ~retention=150uA, off=~50uA.  Clock stop can
> be higher depending on the 'partial' activity necessary, and perhaps
> also lower.

OK

Tony