All of lore.kernel.org
 help / color / mirror / Atom feed
From: sylvain.rochet@finsecur.com (Sylvain Rochet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clockevents: don't suspend/resume if unused
Date: Mon, 25 May 2015 21:06:42 +0200	[thread overview]
Message-ID: <20150525190641.GA7542@gradator.net> (raw)
In-Reply-To: <alpine.DEB.2.11.1505252046400.5457@nanos>

Hello Thomas,

On Mon, May 25, 2015 at 08:48:06PM +0200, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Alexandre Belloni wrote:
> 
> > There is no point in calling suspend/resume for unused
> > clockevents as they are already stopped and disabled.
> > 
> > Furthermore, it can take some time to wait for some IPs to stop counting.
> 
> While I agree with the patch itself, I really can't understand that
> last sentence.
> 
> If stuff is stopped and disabled, what takes time to stop counting?

Atmel PIT is a bit weird, writing to AT91_PIT_MR restarts the timer even 
if you just want to stop it and then the only way to stop the timer is 
to wait for a complete timer cycle.

The problem is not when suspending, restarting the timer just before 
suspending is not such a problem because is will eventually stop at 
some point in the future.

However it can takes a very long time if the system switchs to slow 
clock, therefore when resuming the timer is still running and we have to 
wait for the PIT to stop counting because we re-enabled it for one cycle 
when suspending, which is weird, it adds about ~128ms resumt time for 
Atmel SoC.

The previous proposed patch was to do nothing in PIT suspend and resume 
callbacks if PIT is unused[1], which fixed the PIT problem, but we 
decided to put the condition in the upper level because other drivers 
might be interested too.

Sylvain

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311496.html

WARNING: multiple messages have this Message-ID (diff)
From: Sylvain Rochet <sylvain.rochet@finsecur.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clockevents: don't suspend/resume if unused
Date: Mon, 25 May 2015 21:06:42 +0200	[thread overview]
Message-ID: <20150525190641.GA7542@gradator.net> (raw)
In-Reply-To: <alpine.DEB.2.11.1505252046400.5457@nanos>

Hello Thomas,

On Mon, May 25, 2015 at 08:48:06PM +0200, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Alexandre Belloni wrote:
> 
> > There is no point in calling suspend/resume for unused
> > clockevents as they are already stopped and disabled.
> > 
> > Furthermore, it can take some time to wait for some IPs to stop counting.
> 
> While I agree with the patch itself, I really can't understand that
> last sentence.
> 
> If stuff is stopped and disabled, what takes time to stop counting?

Atmel PIT is a bit weird, writing to AT91_PIT_MR restarts the timer even 
if you just want to stop it and then the only way to stop the timer is 
to wait for a complete timer cycle.

The problem is not when suspending, restarting the timer just before 
suspending is not such a problem because is will eventually stop at 
some point in the future.

However it can takes a very long time if the system switchs to slow 
clock, therefore when resuming the timer is still running and we have to 
wait for the PIT to stop counting because we re-enabled it for one cycle 
when suspending, which is weird, it adds about ~128ms resumt time for 
Atmel SoC.

The previous proposed patch was to do nothing in PIT suspend and resume 
callbacks if PIT is unused[1], which fixed the PIT problem, but we 
decided to put the condition in the upper level because other drivers 
might be interested too.

Sylvain

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311496.html

  reply	other threads:[~2015-05-25 19:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  9:05 [PATCH] clockevents: don't suspend/resume if unused Alexandre Belloni
2015-01-16  9:05 ` Alexandre Belloni
2015-01-16  9:20 ` Sylvain Rochet
2015-01-16  9:20   ` Sylvain Rochet
2015-01-16 11:17   ` Russell King - ARM Linux
2015-01-16 11:17     ` Russell King - ARM Linux
2015-01-16 11:20     ` Russell King - ARM Linux
2015-01-16 11:20       ` Russell King - ARM Linux
2015-01-16 16:59   ` Alexandre Belloni
2015-01-16 16:59     ` Alexandre Belloni
2015-03-06 12:54     ` Alexandre Belloni
2015-03-06 12:54       ` Alexandre Belloni
2015-05-25 16:19     ` Alexandre Belloni
2015-05-25 16:19       ` Alexandre Belloni
2015-05-25 16:56     ` Thomas Gleixner
2015-05-25 16:56       ` Thomas Gleixner
2015-05-25 18:48 ` Thomas Gleixner
2015-05-25 18:48   ` Thomas Gleixner
2015-05-25 19:06   ` Sylvain Rochet [this message]
2015-05-25 19:06     ` Sylvain Rochet
2015-05-25 20:11     ` Thomas Gleixner
2015-05-25 20:11       ` Thomas Gleixner
2015-05-25 20:53       ` Sylvain Rochet
2015-05-25 20:53         ` Sylvain Rochet
2015-05-26 23:07 ` [tip:timers/core] clockevents: Do not " tip-bot for Alexandre Belloni

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=20150525190641.GA7542@gradator.net \
    --to=sylvain.rochet@finsecur.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.