From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754497AbdJSPLu (ORCPT ); Thu, 19 Oct 2017 11:11:50 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:34003 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754414AbdJSPLs (ORCPT ); Thu, 19 Oct 2017 11:11:48 -0400 Date: Thu, 19 Oct 2017 17:11:28 +0200 (CEST) From: Thomas Gleixner To: Martin Schwidefsky cc: Matt Redfearn , Daniel Lezcano , James Hogan , linux-mips@linux-mips.org, James Hogan , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] clockevents: Retry programming min delta up to 10 times In-Reply-To: <20171019170448.4637f480@mschwideX1> Message-ID: References: <1508414135-29123-1-git-send-email-matt.redfearn@mips.com> <5b782526-b130-77f2-6d9a-15839e12e065@mips.com> <20171019170448.4637f480@mschwideX1> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Oct 2017, Martin Schwidefsky wrote: > On Thu, 19 Oct 2017 15:29:28 +0200 (CEST) > Thomas Gleixner wrote: > > > On Thu, 19 Oct 2017, Matt Redfearn wrote: > > > On 19/10/17 13:43, Thomas Gleixner wrote: > > > > delta = 0; > > > > for (i = 0; i < 10; i++) { > > > > delta += dev->min_delta_ns; > > > > dev->next_event = ktime_add_ns(ktime_get(), delta); > > > > clc = ..... > > > > ..... > > > > > > > > That makes it more likely to succeed fast. Hmm? > > > > > > That will set the target time to increasing multiples of min_delta_ns in the > > > future, right? > > > > Yes, but without fiddling with min_delta_ns itself. > > Grumpf, more extra code for yet another piece of broken hardware > I guess. and virtualization. Oh wait.. the virt is the ultimate reference for broken hardware... > > > Sure, it should make it succeed faster - I'll make it like > > > that. Are you OK with the arbitrarily chosen 10 retries? > > > > I lost my crystalball so I have to trust yours :) > > The alternative implementation would be to do the retries in > the clockevent driver itself. Then that particular driver can > choose the correct number of retries, no? There is no correct number ever. All you can do is set an upper limit. Thanks, tglx