[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180510164831.GH98604@atomide.com>
Date: Thu, 10 May 2018 09:48:31 -0700
From: Tony Lindgren <tony@...mide.com>
To: Johan Hovold <johan@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh@...nel.org>,
Sebastian Reichel <sre@...nel.org>,
"H. Nikolaus Schaller" <hns@...delico.com>,
Andreas Kemnade <andreas@...nade.info>,
Mark Rutland <mark.rutland@....com>,
Arnd Bergmann <arnd@...db.de>, Pavel Machek <pavel@....cz>,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH 1/2] serdev: add controller runtime PM support
* Johan Hovold <johan@...nel.org> [180509 09:46]:
> Add support for controller runtime power management to serdev core. This
> is needed to allow slave drivers to manage the runtime PM state of the
> underlying serial controller when its driver, in turn, implements more
> aggressive runtime power management (e.g. using autosuspend).
>
> For some applications, for example, where loss off initial data after a
> remote-wakeup event is acceptable or where rx is not used at all,
> aggressive serial controller runtime PM may be used without further
> involvement of the slave driver. But when this is not the case, the
> slave driver must be able to indicate when incoming data is expected in
> order to avoid data loss.
>
> To facilitate the common case, where the serial controller power state
> is active whenever the port is open (which is the case with just about
> every serial driver), and where data loss is not acceptable and cannot
> even be prevented by explicit controller runtime power management, an
> RPM reference is taken in serdev open and put again at close. This
> reference can later be balanced by any serdev driver which wants and/or
> can handle aggressive controller runtime PM.
>
> Note that the .ignore_children flag is set for the serdev controller to
> allow the underlying hardware to idle when no I/O is expected, regardless
> of the slave device RPM state.
If this solution works for GPS then this should also work for modems
that might produce data. And as long as the serdev consumer driver
can wake up the UART with pm_runtime_get(&serdev->ctrl->dev) then
the out of band GPIO wake interrupts will work to. And for TX,
the serdev consumer driver can toggle the wake GPIO, and then call
pm_runtime_get(&serdev->ctrl->dev). So yeah, looks nice to me:
Acked-by: Tony Lindgren <tony@...mide.com>
Powered by blists - more mailing lists