Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2550799pxu; Fri, 9 Oct 2020 22:42:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGeFxZJ4CQWFOOmMUL2E1e07jJfCd8ylLnimvQ+cvin9wv2e31IQmXMp3Oaaxid/uobLJn X-Received: by 2002:a50:d483:: with SMTP id s3mr2932852edi.173.1602308573259; Fri, 09 Oct 2020 22:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602308573; cv=none; d=google.com; s=arc-20160816; b=XzhPnfvcJ8gbqW6STFenAdGn5RiVwB2CzMH2jky+5TUW29soCIe8IjvJn3Av9Gopk3 8JndJG59ce5EvynfirMP2SnVwEGEVVHWjA41HIcY4ju2D7B+QDMfJJhBK/tdrXsnTsC0 cboT2+gWMGvz2RRi6kXiIrU8fsDTod97MhL92IuZYUPw6shjoFWpm15iWlGxZtTbHAqY c4eWQREeZgQw53xAmrIoIOxW7Ccd0q+gCIrnf93suKPlQGeR9Utp05RMkomZ2rURRcmA c2HqsuRHBrexvW10Et8gJqsiaj4SsyB6O8jUTBPiq1/oukekqW8019CvyEdi1XJzb4SJ Omvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=CTSDABzEyMRuXoi8E20JAUOVasLFAomhBii6+iO3EKA=; b=jAJNfDrEXt8zqyE05sE4y14C2cdDfZfOhOyzw0Skr9I9uNT4HXPVmd2nzK0J9uFTxo /p+9R1pU6u5wNa0CA3Wyv05p0KCBuYZpDQfS54BXZ1cjRXpQH0T9tKAoKUtkjWVMJlmD GXuo1FqWar3SCSakpH9TD+b5fcmhFaGgmgL/hU/IN1EMe4uQi1sO4AFIdAKEZOI+OyHz TlGK7xsmCfIaqsTnCluRmEoupSjLYgkR2AAZZo2EMISnMDJgayE2JxtDHEFkOBoLJR5U aB+7yRs7IipI6hZJP+RvctXVxcZV44ECiO7pZP/b2LDqx1om6zxSucXK/urEChBPpDDb q9Uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j17si1854311edt.72.2020.10.09.22.42.29; Fri, 09 Oct 2020 22:42:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391084AbgJIWVm (ORCPT + 99 others); Fri, 9 Oct 2020 18:21:42 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:39342 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732320AbgJIWVk (ORCPT ); Fri, 9 Oct 2020 18:21:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 522E829EC7; Fri, 9 Oct 2020 18:21:36 -0400 (EDT) Date: Sat, 10 Oct 2020 09:21:38 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann cc: linux-kernel@vger.kernel.org, Russell King , Tony Luck , Fenghua Yu , Greg Ungerer , Geert Uytterhoeven , Philip Blundell , Joshua Thompson , Sam Creasey , "James E.J. Bottomley" , Helge Deller , Thomas Gleixner , Daniel Lezcano , John Stultz , Stephen Boyd , Linus Walleij , linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent In-Reply-To: <20201008154651.1901126-14-arnd@arndb.de> Message-ID: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, Perhaps patch 13 does not belong in this series (?). All m68k platforms will need conversion before the TODO can be removed from Documentation/features/time/clockevents/arch-support.txt. On m68k, HZ is fixed at 100. Without addressing that, would there be any benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch? On Thu, 8 Oct 2020, Arnd Bergmann wrote: > Now that the infrastructure allows kernels to have both legacy timer > ticks and clockevent drivers in the same image, start by moving one > platform to generic clockevents. > > As qemu only supports the q800 platform among the classic m68k, use that > as an example. > Correct VIA emulation is suprisingly difficult, so this kind of work should be tested on real hardware. I say that because when I did the clocksource conversion for m68k I ran into a bug in QEMU (since fixed) and also because I once worked on some of the bugs in the emulated VIA device used in MAME/MESS. > I also tried adding oneshot mode, which was successful but broke the > clocksource. It's probably not hard to make it work properly, but this > is where I've stopped. > I'm not so sure that one timer is able to support both a clocksource driver and a clockevent driver. In some cases we may have to drop the clocksource driver (i.e. fall back on the jiffies clocksource). Anyway, even on Macs with only one VIA chip we still have two timers. So I think we should try to use Timer 1 as a freerunning clocksource and Timer 2 as a oneshot clock event. This may result in better accuracy and simpler code. This may require some experimentation though. > Signed-off-by: Arnd Bergmann > --- > I have never tried implementing a clockevent or clocksource > driver in the past, so this is really just an experiment and > I expect I got something wrong. > Writing clockevent drivers is new to me too. I'm still trying to discover what the implications might be if the only available clockevent device offers oneshot mode or periodic mode but not both.