From mboxrd@z Thu Jan 1 00:00:00 1970 From: sylvain.rochet@finsecur.com (Sylvain Rochet) Date: Mon, 25 May 2015 21:06:42 +0200 Subject: [PATCH] clockevents: don't suspend/resume if unused In-Reply-To: References: <1421399151-26800-1-git-send-email-alexandre.belloni@free-electrons.com> Message-ID: <20150525190641.GA7542@gradator.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751289AbbEYTGu (ORCPT ); Mon, 25 May 2015 15:06:50 -0400 Received: from mx-guillaumet.finsecur.com ([91.217.234.131]:55936 "EHLO guillaumet.finsecur.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbbEYTGt (ORCPT ); Mon, 25 May 2015 15:06:49 -0400 Date: Mon, 25 May 2015 21:06:42 +0200 From: Sylvain Rochet To: Thomas Gleixner Cc: Alexandre Belloni , Daniel Lezcano , Nicolas Ferre , Boris Brezillon , Maxime Ripard , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Message-ID: <20150525190641.GA7542@gradator.net> References: <1421399151-26800-1-git-send-email-alexandre.belloni@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 172.16.8.13 X-SA-Exim-Mail-From: sylvain.rochet@finsecur.com Subject: Re: [PATCH] clockevents: don't suspend/resume if unused X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on guillaumet.finsecur.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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