From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CF6AC388F7 for ; Fri, 6 Nov 2020 03:12:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 260BB2083B for ; Fri, 6 Nov 2020 03:12:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725966AbgKFDMV (ORCPT ); Thu, 5 Nov 2020 22:12:21 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:47340 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725972AbgKFDMV (ORCPT ); Thu, 5 Nov 2020 22:12:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id D3BE7232E6; Thu, 5 Nov 2020 22:12:18 -0500 (EST) Date: Fri, 6 Nov 2020 14:12:08 +1100 (AEDT) From: Finn Thain To: Greg Ungerer cc: Arnd Bergmann , "linux-kernel@vger.kernel.org" , Russell King , Tony Luck , Fenghua Yu , 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, Parisc List , linux-m68k , Linux ARM Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent In-Reply-To: <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> Message-ID: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Fri, 30 Oct 2020, Greg Ungerer wrote: > > > > > ... > > > > The other 11 platforms in that category also have 'synthetic' > > > > clocksources derived from a timer reload interrupt. In 3 cases, > > > > the clocksource read method does not (or can not) check for a > > > > pending counter reload interrupt. For these also, I see no > > > > practical alternative to the approach you've taken in your RFC > > > > patch: > > > > > > > > arch/m68k/68000/timers.c > > > > arch/m68k/atari/time.c > > > > arch/m68k/coldfire/timers.c > > > > > > Agreed. It's possible there is a way, but I don't see one either. > > > > > > > For arch/m68k/68000/timers.c, I suppose we may be able to check for > > the TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the > > COMP bit in the Timer Status Register at 0xFFFFF60A. But testing that > > patch could be difficult. > > > > I expect that equivalent flags are available in Coldfire registers, > > making it possible to improve upon mcftmr_read_clk() and > > m68328_read_clk() if need be -- that is, if it turns out that the > > clocksource interrupt was subject to higher priority IRQs that would > > slow down the clocksource or defeat its monotonicity. > > > > The other difficulty is a lack of hardware timers. There's only one > > timer on MC68EZ328. On Atari, for now only Timer C is available though > > Michael has said that it would be possible to free up Timer D. Some > > Coldfire chips have only 2 timers and the second timer seems to be > > allocated to profiling. > > FWIW, I would have no problem with ditching the profiling clock, and > using both on ColdFire platforms that have this. I doubt anyone has used > that profiling setup in a _very_ long time. > If we ditched the Coldfire profiling clock, it would be possible to dedicate one hardware timer to the clocksource device and the other to the (oneshot) clockevent device. That's a win if it means that the clocksource can use the full counter width (making timer interrupts less frequent and timer interrupt latency less problematic) and run at higher frequency (making the clocksource more precise). Also, note that hrtimers won't work with a periodic clockevent device (as in Arnd's RFC patch). If you want hrtimers, I think you'll need both hardware timers or else re-implement the existing synthetic clocksource using the same oneshot timer driving a new oneshot clockevent device. Please note that the lack of a spare hardware timer is a separate issue to the failure of mcftmr_read_clk() and m68328_read_clk() to check the timer reload interrupt flag (which may make those clocksources needlessly susceptible to issues caused by timer interrupt latency...). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5181C388F7 for ; Fri, 6 Nov 2020 03:12:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6AADF20782 for ; Fri, 6 Nov 2020 03:12:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0tONERVj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6AADF20782 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LqOTW4cXr64B1bGL93uZ1nl9O9YqzG+y6WwgWfikcSM=; b=0tONERVjai5NuyuOupY5wYddp POLR7w1cOBVF7Jx4I/FeZ2jKPqWZ/1zqUHHCMJKUQItmLYJ4egyVtAHTYIDw+sFUHbTs9OzwQE3Gm 3KeRS4uuwP38pefwl+kZaoukm7/XzGYU0t6cboKJmfgpAaqh9fCRtTRxn0Jg+M5MQfmCGbEeN7Lp+ dwBb2PDIjCGdSV04vOJTc8paxgiaWp3+Ai9PtStGvOJvrrsmYk4uHYtFdMzkqTA+iUei05K8j/FMq h+3rTZ0rs1lEtvZ0Wuc1XXt0kqrOukmDhoxxSBjKy8ZnnxWUdIozaTzPc1gYOjkSb9rWdGdexiHP5 z+Gias5kA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kasAp-0005rv-C9; Fri, 06 Nov 2020 03:12:23 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kasAn-0005rE-46 for linux-arm-kernel@lists.infradead.org; Fri, 06 Nov 2020 03:12:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id D3BE7232E6; Thu, 5 Nov 2020 22:12:18 -0500 (EST) Date: Fri, 6 Nov 2020 14:12:08 +1100 (AEDT) From: Finn Thain To: Greg Ungerer Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent In-Reply-To: <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> Message-ID: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201105_221221_194578_575F6D18 X-CRM114-Status: GOOD ( 25.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sam Creasey , Arnd Bergmann , Linus Walleij , Tony Luck , linux-ia64@vger.kernel.org, Parisc List , Fenghua Yu , Stephen Boyd , Helge Deller , Daniel Lezcano , "linux-kernel@vger.kernel.org" , Russell King , "James E.J. Bottomley" , linux-m68k , Geert Uytterhoeven , Linux ARM , John Stultz , Philip Blundell , Thomas Gleixner , Joshua Thompson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 30 Oct 2020, Greg Ungerer wrote: > > > > > ... > > > > The other 11 platforms in that category also have 'synthetic' > > > > clocksources derived from a timer reload interrupt. In 3 cases, > > > > the clocksource read method does not (or can not) check for a > > > > pending counter reload interrupt. For these also, I see no > > > > practical alternative to the approach you've taken in your RFC > > > > patch: > > > > > > > > arch/m68k/68000/timers.c > > > > arch/m68k/atari/time.c > > > > arch/m68k/coldfire/timers.c > > > > > > Agreed. It's possible there is a way, but I don't see one either. > > > > > > > For arch/m68k/68000/timers.c, I suppose we may be able to check for > > the TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the > > COMP bit in the Timer Status Register at 0xFFFFF60A. But testing that > > patch could be difficult. > > > > I expect that equivalent flags are available in Coldfire registers, > > making it possible to improve upon mcftmr_read_clk() and > > m68328_read_clk() if need be -- that is, if it turns out that the > > clocksource interrupt was subject to higher priority IRQs that would > > slow down the clocksource or defeat its monotonicity. > > > > The other difficulty is a lack of hardware timers. There's only one > > timer on MC68EZ328. On Atari, for now only Timer C is available though > > Michael has said that it would be possible to free up Timer D. Some > > Coldfire chips have only 2 timers and the second timer seems to be > > allocated to profiling. > > FWIW, I would have no problem with ditching the profiling clock, and > using both on ColdFire platforms that have this. I doubt anyone has used > that profiling setup in a _very_ long time. > If we ditched the Coldfire profiling clock, it would be possible to dedicate one hardware timer to the clocksource device and the other to the (oneshot) clockevent device. That's a win if it means that the clocksource can use the full counter width (making timer interrupts less frequent and timer interrupt latency less problematic) and run at higher frequency (making the clocksource more precise). Also, note that hrtimers won't work with a periodic clockevent device (as in Arnd's RFC patch). If you want hrtimers, I think you'll need both hardware timers or else re-implement the existing synthetic clocksource using the same oneshot timer driving a new oneshot clockevent device. Please note that the lack of a spare hardware timer is a separate issue to the failure of mcftmr_read_clk() and m68328_read_clk() to check the timer reload interrupt flag (which may make those clocksources needlessly susceptible to issues caused by timer interrupt latency...). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Fri, 06 Nov 2020 03:12:08 +0000 Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent Message-Id: List-Id: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> In-Reply-To: <580c3542-92cc-7e33-a43d-bf6a68134a46@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Ungerer Cc: Arnd Bergmann , "linux-kernel@vger.kernel.org" , Russell King , Tony Luck , Fenghua Yu , 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, Parisc List , linux-m68k , Linux ARM On Fri, 30 Oct 2020, Greg Ungerer wrote: > > > > > ... > > > > The other 11 platforms in that category also have 'synthetic' > > > > clocksources derived from a timer reload interrupt. In 3 cases, > > > > the clocksource read method does not (or can not) check for a > > > > pending counter reload interrupt. For these also, I see no > > > > practical alternative to the approach you've taken in your RFC > > > > patch: > > > > > > > > arch/m68k/68000/timers.c > > > > arch/m68k/atari/time.c > > > > arch/m68k/coldfire/timers.c > > > > > > Agreed. It's possible there is a way, but I don't see one either. > > > > > > > For arch/m68k/68000/timers.c, I suppose we may be able to check for > > the TMR1 bit in the Interrupt Status Register at 0xFFFFF30C or the > > COMP bit in the Timer Status Register at 0xFFFFF60A. But testing that > > patch could be difficult. > > > > I expect that equivalent flags are available in Coldfire registers, > > making it possible to improve upon mcftmr_read_clk() and > > m68328_read_clk() if need be -- that is, if it turns out that the > > clocksource interrupt was subject to higher priority IRQs that would > > slow down the clocksource or defeat its monotonicity. > > > > The other difficulty is a lack of hardware timers. There's only one > > timer on MC68EZ328. On Atari, for now only Timer C is available though > > Michael has said that it would be possible to free up Timer D. Some > > Coldfire chips have only 2 timers and the second timer seems to be > > allocated to profiling. > > FWIW, I would have no problem with ditching the profiling clock, and > using both on ColdFire platforms that have this. I doubt anyone has used > that profiling setup in a _very_ long time. > If we ditched the Coldfire profiling clock, it would be possible to dedicate one hardware timer to the clocksource device and the other to the (oneshot) clockevent device. That's a win if it means that the clocksource can use the full counter width (making timer interrupts less frequent and timer interrupt latency less problematic) and run at higher frequency (making the clocksource more precise). Also, note that hrtimers won't work with a periodic clockevent device (as in Arnd's RFC patch). If you want hrtimers, I think you'll need both hardware timers or else re-implement the existing synthetic clocksource using the same oneshot timer driving a new oneshot clockevent device. Please note that the lack of a spare hardware timer is a separate issue to the failure of mcftmr_read_clk() and m68328_read_clk() to check the timer reload interrupt flag (which may make those clocksources needlessly susceptible to issues caused by timer interrupt latency...).