On 07/09/2014 01:17 PM, Tony Lindgren wrote:

* One Thousand Gnomes [off-list ref] [140707 06:22]:

quoted

On Fri,  4 Jul 2014 18:34:10 +0200
Sebastian Andrzej Siewior [off-list ref] wrote:

quoted

While comparing the OMAP-serial and the 8250 part of this I noticed that
the the latter does not use runtime-pm.

Yes it does, but 8250 parts (generally - omap presumably is special
here ?) need to be powered on to transmit/receive not just for register
access. The core uart layer implements a "pm" operation for this.

At least for omaps the UARTs need to be idled for the SoC to
hit off-idle where the SoC is powered off and rebooted during
idle.

So we can certainly enable this in a generic way, however, this
can only be done under the following conditions:

1. We can save and restore the serial register context and detect
   when context was lost in the serial driver. The context loss
   can be detected by looking at some registers that are only
   initialized during init.

A register check on restore context? DLL+DLH might be a good hint here
since its value should be >0 in the running case.

2. There's a way for the serial RX pin to wake the SoC. On some
   omaps there's a separate pin specific wake-up interrupt that
   can be used for that.

That one would be handled by omap separately.

3. The serial PM features must be only enabled if requested by
   the user via sysfs. Typically extra latency and loss of the
   first RX character occur which is not acceptable to most
   applications.

Unless I'm mistaken the omap driver now initializes the timeout to -1.
So nothing happens unless this is enabled separately.

Regards,

Tony

Sebastian