From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbbDBQEo (ORCPT ); Thu, 2 Apr 2015 12:04:44 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:33148 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751260AbbDBQEk (ORCPT ); Thu, 2 Apr 2015 12:04:40 -0400 Date: Thu, 2 Apr 2015 18:04:35 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: Viresh Kumar , Ingo Molnar , Thomas Gleixner , Linaro Kernel Mailman List , Linux Kernel Mailing List , Kevin Hilman , Daniel Lezcano , Preeti U Murthy , Frederic Weisbecker Subject: Re: [PATCH 2/3] clockevents: Restart clockevent device before using it again Message-ID: <20150402160435.GA8045@gmail.com> References: <20150402133403.GY23123@twins.programming.kicks-ass.net> <20150402150649.GD23123@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150402150649.GD23123@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Thu, Apr 02, 2015 at 07:20:50PM +0530, Viresh Kumar wrote: > > > Or am I completely missing something? > > > > So yes, if we would have done that in tick_program_event(), it would have > > been a single place for doing this change.. > > > > But, when Thomas ranted [1] at me on this earlier, he said: > > > > " > > No, we are not doing a state change behind the scene and a magic > > restore. > > > > 2B) Implement the ONESHOT_STOPPED logic and make sure all of the core > > code is aware of it. > > " > > > > lkml.org didn't work for me, alternative link: > > http://marc.info/?l=linux-kernel&m=139966616803683&w=2 > > So I've read that (several times) and I thing Thomas meant something > else. > > So I think he disliked what you did to the clockevent layer, not so much > you touching tick_program_event(). But the last_state thing (which was > broken), and you imposing the SHUTDOWN policy for everybody. > > But with the optional ONESHOT_STOPPED state both those are gone, and > we'd end up with the much simpler patch below. > > Further note that tick-oneshot is the natural place to do this, that is > the glue layer between the (oneshot) clockevents stuff and the timer > stuff. Pulling clockevents into hrtimers feels wrong. > > Ingo, do you agree with that after reading Thomas' email? Yeah, I suppose ... Thanks, Ingo