[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180328223020.GL5700@atomide.com>
Date: Wed, 28 Mar 2018 15:30:21 -0700
From: Tony Lindgren <tony@...mide.com>
To: Vignesh R <vigneshr@...com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH] serial: 8250: omap: Provide ability to enable/disable
UART as wakeup source
* Vignesh R <vigneshr@...com> [180327 12:03]:
> Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
> return value of device_may_wakeup() in .suspend(). This allows
> userspace to use sysfs to control the ability of UART to wakeup the
> system from deep sleep state. Register is restored back in .startup()
> call that happens as part of resume sequence.
>
> With this patch, userspace can control UART wakeup capability via sysfs:
> To enable wakeup capability:
> echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
> For disabling wakeup capability:
> echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
To avoid confusion, can you please add this to the description:
Note that the UART wakeup events configured in the 8250 hardware only
work for idle modes that do not cut off power for the UART. For deeper
idle states, dedicated padconf wakeirqs must be used. Or in some cases
the UART RX pin can be remuxed to GPIO input if the GPIO block stays
powered.
I tested this briefly and the dedicated wakeirqs still work for me,
so from that point of view:
Tested-by: Tony Lindgren <tony@...mide.com>
Powered by blists - more mailing lists