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

+ wake-up-from-a-serial-port.patch added to -mm tree

[akpm]

The patch titled
     wake up from a serial port
has been added to the -mm tree.  Its filename is
     wake-up-from-a-serial-port.patch

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

------------------------------------------------------
Subject: wake up from a serial port
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

Enable wakeup from serial ports, make it run-time configurable over sysfs,
e.g.,

echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup

Requires

# CONFIG_SYSFS_DEPRECATED is not set

Linkstation / kurobox systems from Buffalo Tech.  have an AVR controller
connected to host's UART.  The AVR controls power, buttons, fan, LEDs,
sensors...  So, practically the only way to wake the system up is to press a
button, which sends a byte from the AVR to the CPU.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/serial/8250.c        |   30 ++++++++++++++++++++++++++----
 drivers/serial/serial_core.c |    9 ++++++++-
 2 files changed, 34 insertions(+), 5 deletions(-)

diff -puN drivers/serial/8250.c~wake-up-from-a-serial-port drivers/serial/8250.c
--- a/drivers/serial/8250.c~wake-up-from-a-serial-port
+++ a/drivers/serial/8250.c
@@ -129,6 +129,7 @@ struct uart_8250_port {
 	unsigned char		mcr;
 	unsigned char		mcr_mask;	/* mask of user bits */
 	unsigned char		mcr_force;	/* mask of forced bits */
+	char			suspended;
 
 	/*
 	 * Some bits in registers are cleared on a read, so they must
@@ -2701,6 +2702,14 @@ static int __devexit serial8250_remove(s
 	return 0;
 }
 
+static int serial8250_match_port(struct device *dev, void *data)
+{
+	struct uart_port *port = data;
+	dev_t devt = MKDEV(serial8250_reg.major, serial8250_reg.minor) + port->line;
+
+	return dev->devt == devt; /* Actually, only one tty per port */
+}
+
 static int serial8250_suspend(struct platform_device *dev, pm_message_t state)
 {
 	int i;
@@ -2708,8 +2717,16 @@ static int serial8250_suspend(struct pla
 	for (i = 0; i < UART_NR; i++) {
 		struct uart_8250_port *up = &serial8250_ports[i];
 
-		if (up->port.type != PORT_UNKNOWN && up->port.dev == &dev->dev)
-			uart_suspend_port(&serial8250_reg, &up->port);
+		if (up->port.type != PORT_UNKNOWN && up->port.dev == &dev->dev) {
+			struct device *tty_dev = device_find_child(up->port.dev, &up->port,
+								   serial8250_match_port);
+			if (device_may_wakeup(tty_dev))
+				enable_irq_wake(up->port.irq);
+			else {
+				uart_suspend_port(&serial8250_reg, &up->port);
+				up->suspended = 1;
+			}
+		}
 	}
 
 	return 0;
@@ -2722,8 +2739,13 @@ static int serial8250_resume(struct plat
 	for (i = 0; i < UART_NR; i++) {
 		struct uart_8250_port *up = &serial8250_ports[i];
 
-		if (up->port.type != PORT_UNKNOWN && up->port.dev == &dev->dev)
-			serial8250_resume_port(i);
+		if (up->port.type != PORT_UNKNOWN && up->port.dev == &dev->dev) {
+			if (up->suspended) {
+				serial8250_resume_port(i);
+				up->suspended = 0;
+			} else
+				disable_irq_wake(up->port.irq);
+		}
 	}
 
 	return 0;
diff -puN drivers/serial/serial_core.c~wake-up-from-a-serial-port drivers/serial/serial_core.c
--- a/drivers/serial/serial_core.c~wake-up-from-a-serial-port
+++ a/drivers/serial/serial_core.c
@@ -2271,6 +2271,7 @@ int uart_add_one_port(struct uart_driver
 {
 	struct uart_state *state;
 	int ret = 0;
+	struct device *tty_dev;
 
 	BUG_ON(in_interrupt());
 
@@ -2306,7 +2307,13 @@ int uart_add_one_port(struct uart_driver
 	 * Register the port whether it's detected or not.  This allows
 	 * setserial to be used to alter this ports parameters.
 	 */
-	tty_register_device(drv->tty_driver, port->line, port->dev);
+	tty_dev = tty_register_device(drv->tty_driver, port->line, port->dev);
+	if (likely(!IS_ERR(tty_dev))) {
+		device_can_wakeup(tty_dev) = 1;
+		device_set_wakeup_enable(tty_dev, 0);
+	} else
+		printk(KERN_ERR "Cannot register tty device on line %d\n",
+		       port->line);
 
 	/*
 	 * If this driver supports console, and it hasn't been
_

Patches currently in -mm which might be from g.liakhovetski@gmx.de are

git-powerpc.patch
wake-up-from-a-serial-port.patch

[PATCH] wake up from a serial port

[Guennadi Liakhovetski]

Enable wakeup from serial ports, make it run-time configurable over sysfs, 
e.g.,

echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup

Requires

# CONFIG_SYSFS_DEPRECATED is not set

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

---

Following suggestions from Alan and Russell moved the may_wake_up checks 
to serial_core.c. This time actually tested - it does even work. Could 
someone, please, verify, that put_device after device_find_child is 
correct? Also would be nice to test with a Natsemi UART, that can wake up 
the system, if such systems exist.

Thanks
Guennadi

diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index 9c57486..8a3d6ea 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1934,9 +1934,24 @@ static void uart_change_pm(struct uart_state *state, int pm_state)
 	}
 }
 
+struct uart_match {
+	struct uart_port *port;
+	struct uart_driver *driver;
+};
+
+static int serial_match_port(struct device *dev, void *data)
+{
+	struct uart_match *match = data;
+	dev_t devt = MKDEV(match->driver->major, match->driver->minor) + match->port->line;
+
+	return dev->devt == devt; /* Actually, only one tty per port */
+}
+
 int uart_suspend_port(struct uart_driver *drv, struct uart_port *port)
 {
 	struct uart_state *state = drv->state + port->line;
+	struct device *tty_dev;
+	struct uart_match match = {port, drv};
 
 	mutex_lock(&state->mutex);
 
@@ -1947,6 +1962,15 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *port)
 	}
 #endif
 
+	tty_dev = device_find_child(port->dev, &match, serial_match_port);
+	if (device_may_wakeup(tty_dev)) {
+		enable_irq_wake(port->irq);
+		put_device(tty_dev);
+		mutex_unlock(&state->mutex);
+		return 0;
+	}
+	port->suspended = 1;
+
 	if (state->info && state->info->flags & UIF_INITIALIZED) {
 		const struct uart_ops *ops = port->ops;
 
@@ -1995,6 +2019,13 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *port)
 	}
 #endif
 
+	if (!port->suspended) {
+		disable_irq_wake(port->irq);
+		mutex_unlock(&state->mutex);
+		return 0;
+	}
+	port->suspended = 0;
+
 	uart_change_pm(state, 0);
 
 	/*
@@ -2266,6 +2297,7 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *port)
 {
 	struct uart_state *state;
 	int ret = 0;
+	struct device *tty_dev;
 
 	BUG_ON(in_interrupt());
 
@@ -2301,7 +2333,13 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *port)
 	 * Register the port whether it's detected or not.  This allows
 	 * setserial to be used to alter this ports parameters.
 	 */
-	tty_register_device(drv->tty_driver, port->line, port->dev);
+	tty_dev = tty_register_device(drv->tty_driver, port->line, port->dev);
+	if (likely(!IS_ERR(tty_dev))) {
+		device_can_wakeup(tty_dev) = 1;
+		device_set_wakeup_enable(tty_dev, 0);
+	} else
+		printk(KERN_ERR "Cannot register tty device on line %d\n",
+		       port->line);
 
 	/*
 	 * If this driver supports console, and it hasn't been
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 773d8d8..60dedc0 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -291,7 +291,8 @@ struct uart_port {
 	unsigned long		mapbase;		/* for ioremap */
 	struct device		*dev;			/* parent device */
 	unsigned char		hub6;			/* this should be in the 8250 driver */
-	unsigned char		unused[3];
+	unsigned char		suspended;
+	unsigned char		unused[2];
 	void			*private_data;		/* generic platform data pointer */
 };
 

Re: wake up from a serial port

[Michael Mauch]

Guennadi Liakhovetski wrote:

> Enable wakeup from serial ports, make it run-time configurable over sysfs, 
> e.g.,
> 
> echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup

Interesting, but how does that work from a user's/hardware perspective?

Do I have to pull DSR/RI to +12V? Can I use one of the other pins to get
these +12V (i.e. a switch and a resistor to shorten these pins is
enough)?

And probably in the BIOS I have to enable "wake on modem ring" (or
something similar)?

Regards...
		Michael

Re: wake up from a serial port

[Guennadi Liakhovetski]

On Wed, 12 Sep 2007, Michael Mauch wrote:

> Guennadi Liakhovetski wrote:
> 
> > Enable wakeup from serial ports, make it run-time configurable over sysfs, 
> > e.g.,
> > 
> > echo enabled > /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup
> 
> Interesting, but how does that work from a user's/hardware perspective?
> 
> Do I have to pull DSR/RI to +12V? Can I use one of the other pins to get
> these +12V (i.e. a switch and a resistor to shorten these pins is
> enough)?
> 
> And probably in the BIOS I have to enable "wake on modem ring" (or
> something similar)?

It depends on the hardware. In principle, with this patch _if_ your system 
can suspend while keeping the UART powered on and the interrupt from this 
UART can wake up your system, then using this patch and the command above 
you'll be able to also keep the UART configured, i.e., prevent the driver 
from suspending it during suspend and then an interrupt from this UART 
will wake up the system. How you generate this interrupt - doesn't matter. 
Whether it is a received byte, or a modem line toggle, as long as it 
produces an interrupt, the system will wake up.

Don't know whether "normal" PCs can do that and if yes - how.

Thanks
Guennadi
---
Guennadi Liakhovetski