From mboxrd@z Thu Jan 1 00:00:00 1970 From: sylvain.rochet@finsecur.com (Sylvain Rochet) Date: Mon, 25 May 2015 22:53:59 +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> <20150525190641.GA7542@gradator.net> Message-ID: <20150525205359.GA9302@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 10:11:15PM +0200, Thomas Gleixner wrote: > > That's a reasonable explanation. > > While timer IPs seem to be designed by janitors in general, this one > has an extraordinary level of stupidity. Yes, that's quite a stupid design, however I wasn't totally right from looking at the datasheet again, the timer does not restart when asked to stop while it is already stopped, my bad. But it doesn't change anything, the issue is still that this timer cannot be stopped right now, you have to ask for it to stop then wait the overflow. 1. suspend PIT[1] -> ask to stop 2. suspended, timer is still counting and will eventually reaches the overflow condition then stop, that's probably not going to happen if system switched to slow clock 3. resume PIT[2] -> wait for PIT to stop counting (up to 126ms) because we need it to be synched back if we want to use it at some point in the future, that's also the only way to clear pending interrupts. Sylvain [1] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L122 [2] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L130 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751467AbbEYUyI (ORCPT ); Mon, 25 May 2015 16:54:08 -0400 Received: from mx-guillaumet.finsecur.com ([91.217.234.131]:58311 "EHLO guillaumet.finsecur.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207AbbEYUyF (ORCPT ); Mon, 25 May 2015 16:54:05 -0400 Date: Mon, 25 May 2015 22:53:59 +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: <20150525205359.GA9302@gradator.net> References: <1421399151-26800-1-git-send-email-alexandre.belloni@free-electrons.com> <20150525190641.GA7542@gradator.net> 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 10:11:15PM +0200, Thomas Gleixner wrote: > > That's a reasonable explanation. > > While timer IPs seem to be designed by janitors in general, this one > has an extraordinary level of stupidity. Yes, that's quite a stupid design, however I wasn't totally right from looking at the datasheet again, the timer does not restart when asked to stop while it is already stopped, my bad. But it doesn't change anything, the issue is still that this timer cannot be stopped right now, you have to ask for it to stop then wait the overflow. 1. suspend PIT[1] -> ask to stop 2. suspended, timer is still counting and will eventually reaches the overflow condition then stop, that's probably not going to happen if system switched to slow clock 3. resume PIT[2] -> wait for PIT to stop counting (up to 126ms) because we need it to be synched back if we want to use it at some point in the future, that's also the only way to clear pending interrupts. Sylvain [1] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L122 [2] http://lxr.free-electrons.com/source/drivers/clocksource/timer-atmel-pit.c#L130