From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Tony Lindgren <tony@atomide.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
balbi@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
mika.westerberg@linux.intel.com
Subject: Re: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
Date: Wed, 09 Jul 2014 13:35:57 +0200 [thread overview]
Message-ID: <53BD291D.3040307@linutronix.de> (raw)
In-Reply-To: <20140709111705.GR28884@atomide.com>
On 07/09/2014 01:17 PM, Tony Lindgren wrote:
> * One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> [140707 06:22]:
>> On Fri, 4 Jul 2014 18:34:10 +0200
>> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>>
>>> 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
WARNING: multiple messages have this Message-ID (diff)
From: bigeasy@linutronix.de (Sebastian Andrzej Siewior)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
Date: Wed, 09 Jul 2014 13:35:57 +0200 [thread overview]
Message-ID: <53BD291D.3040307@linutronix.de> (raw)
In-Reply-To: <20140709111705.GR28884@atomide.com>
On 07/09/2014 01:17 PM, Tony Lindgren wrote:
> * One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> [140707 06:22]:
>> On Fri, 4 Jul 2014 18:34:10 +0200
>> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>>
>>> 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
next prev parent reply other threads:[~2014-07-09 11:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 16:34 [RFC PATCH 1/4] tty: serial: 8250 core: provide a function to export uart_8250_port Sebastian Andrzej Siewior
2014-07-04 16:34 ` Sebastian Andrzej Siewior
2014-07-04 16:34 ` [RFC PATCH 2/4] tty: serial: 8250 core: allow to overwrite & export serial8250_startup() Sebastian Andrzej Siewior
2014-07-04 16:34 ` Sebastian Andrzej Siewior
2014-07-07 13:09 ` One Thousand Gnomes
2014-07-07 13:09 ` One Thousand Gnomes
2014-07-09 17:39 ` Sebastian Andrzej Siewior
2014-07-09 17:39 ` Sebastian Andrzej Siewior
2014-07-04 16:34 ` [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm Sebastian Andrzej Siewior
2014-07-04 16:34 ` Sebastian Andrzej Siewior
2014-07-07 13:20 ` One Thousand Gnomes
2014-07-07 13:20 ` One Thousand Gnomes
2014-07-09 11:17 ` Tony Lindgren
2014-07-09 11:17 ` Tony Lindgren
2014-07-09 11:35 ` Sebastian Andrzej Siewior [this message]
2014-07-09 11:35 ` Sebastian Andrzej Siewior
2014-07-09 11:48 ` Tony Lindgren
2014-07-09 11:48 ` Tony Lindgren
2014-07-09 12:42 ` Sebastian Andrzej Siewior
2014-07-09 12:42 ` Sebastian Andrzej Siewior
2014-07-09 15:12 ` Tony Lindgren
2014-07-09 15:12 ` Tony Lindgren
2014-07-09 16:32 ` Sebastian Andrzej Siewior
2014-07-09 16:32 ` Sebastian Andrzej Siewior
2014-07-10 6:43 ` Tony Lindgren
2014-07-10 6:43 ` Tony Lindgren
2014-07-04 16:34 ` [RFC PATCH 4/4] tty: serial: Add 8250-core based omap driver v2 Sebastian Andrzej Siewior
2014-07-04 16:34 ` Sebastian Andrzej Siewior
2014-07-04 16:34 ` Sebastian Andrzej Siewior
2014-07-07 13:09 ` [RFC PATCH 1/4] tty: serial: 8250 core: provide a function to export uart_8250_port One Thousand Gnomes
2014-07-07 13:09 ` One Thousand Gnomes
2014-07-09 17:23 ` Sebastian Andrzej Siewior
2014-07-09 17:23 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53BD291D.3040307@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=balbi@ti.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.