UART IRQ (suspend/resume) question

i'm connecting a GSM/3G modem to a beagleboard, and its Digital Voice
PCM interface to the McBSP on the expansion port. in order to wake
the beagleboard up on an incoming phone call, i was _expecting_ to be
able to connect the "incoming call" GPIO pin on the modem to a GPIO
pin on the expansion port aaannnd.... now i learn that there's
something called "mux" and that completely buggers up any plans to do
that!

so, the next best thing is to rely on interrupts from the UART (on an
incoming phone call). and so - my question is: _can_ you in fact rely
on interrupts from the UART to wake up an OMAP3530 that is in
"suspend"?

many thanks,

l.

i'm connecting a GSM/3G modem to a beagleboard, and its Digital Voice
PCM interface to the McBSP on the expansion port. in order to wake
the beagleboard up on an incoming phone call, i was _expecting_ to be
able to connect the "incoming call" GPIO pin on the modem to a GPIO
pin on the expansion port aaannnd.... now i learn that there's
something called "mux" and that completely buggers up any plans to do
that!

Why do you think the pin-muxing feature of the OMAP would hinder you doing a
wakeup on a GPIO?
You can certainly wakeup the system on a GPIO event.

so, the next best thing is to rely on interrupts from the UART (on an
incoming phone call). and so - my question is: _can_ you in fact rely
on interrupts from the UART to wake up an OMAP3530 that is in
"suspend"?

You can wake up on a UART event as well...

It's all a matter of SW and a matter of configuring the OMAP peripherals
correctly. That being said it might be that the current SW mainlines doesn't
yet support all the features equally stable (as power saving is still an
items being worked heavily on), but seen from a HW point of view both UART
and GPIO events/activity can wake up the system in case configured
correctly...

Best regards - Good luck
  Søren

> i'm connecting a GSM/3G modem to a beagleboard, and its Digital Voice
> PCM interface to the McBSP on the expansion port. in order to wake
> the beagleboard up on an incoming phone call, i was _expecting_ to be
> able to connect the "incoming call" GPIO pin on the modem to a GPIO
> pin on the expansion port aaannnd.... now i learn that there's
> something called "mux" and that completely buggers up any plans to do
> that!

Why do you think the pin-muxing feature of the OMAP would hinder you doing a
wakeup on a GPIO?

ahh, because i didn't realise that you could change the default
settings in u-boot or, if you're feeling frisky, at runtime with
CONFIG_OMAP_MUX :slight_smile:

so, relying on the default configuration, i thought that one of the
McBSPs would not be accessible at the same time as one of the UARTs at
the same time as at least one GPIO pin.

now i know different, but it took several brain-twisting moments to
work it out.

> so, the next best thing is to rely on interrupts from the UART (on an
> incoming phone call). and so - my question is: _can_ you in fact rely
> on interrupts from the UART to wake up an OMAP3530 that is in
> "suspend"?

You can wake up on a UART event as well...

okaaaaay.

It's all a matter of SW and a matter of configuring the OMAP peripherals
correctly. That being said it might be that the current SW mainlines doesn't
yet support all the features equally stable (as power saving is still an
items being worked heavily on),

oh dear. looovely :slight_smile: ... so, in four years, since i was working
with PXA270 last, nothing's changed: linux kernel still being worked
on ha ha :slight_smile:

but seen from a HW point of view both UART
and GPIO events/activity can wake up the system in case configured
correctly...

thanks soren.

l.