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, 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 C2683C433E7 for ; Sat, 10 Oct 2020 23:07:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9ABD42067C for ; Sat, 10 Oct 2020 23:07:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731553AbgJJW5Z (ORCPT ); Sat, 10 Oct 2020 18:57:25 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:51207 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730399AbgJJSwZ (ORCPT ); Sat, 10 Oct 2020 14:52:25 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mq2vU-1k4xW42QHy-00nAAc; Sat, 10 Oct 2020 20:52:18 +0200 Received: by mail-qk1-f171.google.com with SMTP id s4so14062039qkf.7; Sat, 10 Oct 2020 11:52:18 -0700 (PDT) X-Gm-Message-State: AOAM531TjP10XUVHyhHvga/GBzubonVntEPI0GTwOJXYLyiQbofMycph ulv7lPAq83cDPxrll7sgmbLdIEGaicanWLSCG04= X-Google-Smtp-Source: ABdhPJyHb97asLXMVebqtlWTvKZgLrTtP/hgQ4nxOJVaC7ZPWU+ccFfq4hg78Uvv2vpNcQYhAbXFOff6pGfcfHymFNw= X-Received: by 2002:a05:620a:b13:: with SMTP id t19mr3306996qkg.3.1602355937246; Sat, 10 Oct 2020 11:52:17 -0700 (PDT) MIME-Version: 1.0 References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Sat, 10 Oct 2020 20:52:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent To: Finn Thain 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, Parisc List , linux-m68k , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:otRuftNbB3lBySqwtS51xx3yn/t60U7b7y5rmpRvR+Mrfy+Wj+l DRYaNPPxivp2vURRNzBwUZYeyUieC6P6mg4LTACfQQgWXaWn4cKcV4PjyalR0KlYarDEukU SHmocmeKbLalNUv/mWh+nwh+GbX+XXxdhl0LS94xIqNufD4rlg4VFEY+BPwNgtl2znaCjuo Dkh5af7HVd+/VE2bjZGFw== X-UI-Out-Filterresults: notjunk:1;V03:K0:0q4XvGn00f8=:Zejixq+2uSJ3eN+rQC46jy Cr09I9ImfBiqPmSSdKuj0GeUejVHklaeu2HyUiRc4F5nN0jKx21L/Uf/3xVdI/Pa0zXHIKoBt I8U7nEfGrfTU+bW3s3hehX7zxLMbOiB4Niuc36iuaii0YXTw12PjXDLwlQBzaCqs7eqT+nR/D kgZV6SqQq7u0MUVOFyIJbpmAckcckT3d423us+V09bGADbCs+WYsEffSKzM9BmJlqMsGTTowl vsN+cU9kpjJRr8j79tlaM/IWfV+6s09plA0en+JgMa9/UXDi/gjJiteufY6Weuf8GDsktCdLg a04sqbSQqZuR1NZ8seeq8MKjgjmtZi+rXEh2pstr2fHoeb2jXx+v6ZOO3eA80NrkpzuwIS4le /NvSsRuaLD91BEwpeZUQ4y6rTA6U9vOUA6npm4E9ud0fj+/9aLvDYJjdjmdh36i/yXvHDNCSh NRmO5AD5ToaOY4483ZR6Q6J6wyecJKaGA8+3vaxEgK+HDC156DMdxtENC119ViQcXus2Zuh4I EYo2BfCIX8HtB9XIYDmCMxl8HMagrCiLfhnIRMJ45ku3gkOGT4J4Vl+uwSRklKCbTt4+gWDRm SS0ZoNf+BoNvAsnp342Sv2knX5qzw4RuVDzkjUQF4YrFJt+UVWLorYtkoUvwT67ZnORGLxakb zc64zAZao8Jisq1weYALu1rB+wKyFFX14vFz/MDIoO0z6Ys8FC04bA8ciR5Ey2gCj3TK3gwYG mXQ1jGTMw+0vIdJsrcuFIUGkBM8XBhiJWXBxK3rO7lnOK3VLcgxYTzzUb6ShX62XgvUzrMVXW lmKCaiTCCm+crK7wodaXIuswAKEWD0bnQAceO3dz9/l7kD/k044MlADJR7x47TYxaPw625K Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Sat, Oct 10, 2020 at 12:21 AM Finn Thain wrote: > > 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. Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just trying to find out where it should be headed. I would hope the other patches can just get merged. > On m68k, HZ is fixed at 100. Without addressing that, would there be any > benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch? I don't think so, I mainly did it to see if there is a problem with mixing the two modes, and I couldn't find any. The behavior seems unchanged before and after my patch, the main difference being a few extra kilobytes in kernel .text for the generic clockevents code. > 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. Good point, though I would be surprised if anything went wrong with this patch on real hardware but not in emulation, as all the register-level interactions with the timer are the same. Adding oneshot mode is a completely different matter though, that clearly needs to be tested on real hardware. > > 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. Ah, good. This is partly what I had been hoping for, as my patch can be used as a starting point for that if you want to give it a go. Arnd 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 906F2C433DF for ; Sat, 10 Oct 2020 18:54:16 +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 349A1222EC for ; Sat, 10 Oct 2020 18:54:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Gvt8vO+H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 349A1222EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZtmAN7haTBrcSxIdOt7kDkVIUoLwmpfPgKjSDY4b3LA=; b=Gvt8vO+HW6Lao3U+qsVfH6QDc I3qt8tY3XP11Zl8aXwmsCzn63/ahvg5KZUXZRIlrXnYmdBNjD2GClhiPAld5+u8v2Xae/9Gln0SHD +mKHJLLjEu2XJa5xG56AV4DdsWDlfbdonjFRssjCcIcKkGXDeprLoIjHcXxhGBR0CWEkFX/tSrFh2 ZNM2/wEs836BDbBFDXTSWBrX/uZQjtkMVblZ9ZkRIM02m4CNH4J1/TEFHkEiH5Oo2sYlu4z07G0wG mBg83U571qKA+2EehEkDipiSke14IR7lvvfvOxhLb+y3TNGN1ULRr1v1U/1bPFO0arLCKnVBk1omK 0Fn06ZUsA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRJyk-0000vo-3P; Sat, 10 Oct 2020 18:52:26 +0000 Received: from mout.kundenserver.de ([212.227.126.187]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRJyg-0000u5-4U for linux-arm-kernel@lists.infradead.org; Sat, 10 Oct 2020 18:52:23 +0000 Received: from mail-qk1-f178.google.com ([209.85.222.178]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1M4alK-1kRsCy2U2Y-001kkr for ; Sat, 10 Oct 2020 20:52:18 +0200 Received: by mail-qk1-f178.google.com with SMTP id w12so14078700qki.6 for ; Sat, 10 Oct 2020 11:52:18 -0700 (PDT) X-Gm-Message-State: AOAM530+GLQXE5yWbcAd0XPNZKGZ13pLOfsLT3YAlRevQR4m7I4ivCov ZNZmLmxZRM+cWsQm2j0LBTEzZI1Qy5rso5/6nPQ= X-Google-Smtp-Source: ABdhPJyHb97asLXMVebqtlWTvKZgLrTtP/hgQ4nxOJVaC7ZPWU+ccFfq4hg78Uvv2vpNcQYhAbXFOff6pGfcfHymFNw= X-Received: by 2002:a05:620a:b13:: with SMTP id t19mr3306996qkg.3.1602355937246; Sat, 10 Oct 2020 11:52:17 -0700 (PDT) MIME-Version: 1.0 References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-14-arnd@arndb.de> In-Reply-To: From: Arnd Bergmann Date: Sat, 10 Oct 2020 20:52:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent To: Finn Thain X-Provags-ID: V03:K1:49xaVwmH5ect99UnbINncJbGUrTCAKUCwy9tT/Njbapu/01jDZX tW+tWF+0Kb+Cc490JQfE5Deol2ZfyCpQtNJn/RHW/u9tOP4Nfx5p9ezPho6ajyTiUoSWUTD ysNKQdgyj08bxni2wQWb9jmag6l9zCNABswl/TwhHBzvxMYBlBQHMEnHM5Q2Vz9PdwRBMYL CqbUHBlr3JTUdSHo0ffXA== X-UI-Out-Filterresults: notjunk:1;V03:K0:0x0iRGDgoiA=:S3DONZA2VtioO5YmaIAqve MreJn/B7vjDKr8WYmq+dJGf3n3QuICeNj6umCwzbbXEScs05bYovxf2XNauNoszj/j30J5ta3 bl941C+nlTWcz9m3CLYNAJQ+M2tpZFkRVUl7ZBliXAdre5Au5VyYIj1epn8JFNg9woERJe+Oa Lo85CtbcDHrwWNaFRI4K09WTe5If2Nz371lLCULy8HUo3H7yWhZJpHAGSGMo6OcmKm2VoGiFo 4Dj8JKZmj4SAqfhgLTEPUSK61EQQL4gs0oXgFhSp5w9qKeniXs197fPss7jls4bgTUxknDDjn via+DQU6/2WnOOCihx9MRL90TlkTojjskiv0u2Ql1yDfH+C7/wZwnLvhIU5gZKZDgVU5WSo6y i3tulH3DqurNAlc6q58AtEzzdrN0rzoJifXJF+4Us/WeRnwYPg7+HxZmHTO956XPZNupuWKm7 jxYcaDN4xCPjNebJZBpciJn0SyP7IH4/ZLEiWeNHwRj0cJ3+JPauZazkCLrV4D7meed3DG3gn 9Lh2bnoXAG7rXk6V+S7e0jExTgD/No7AUp1W9gSDr7TBlFB8ZvMQsQ0qu5WFczXriMifCTmNq tyQlS1Gq1uZvJbBGLP+4QAJPmVDvU1xI+8xLX7Tj7ct8Hj1o9FYqkisZfsnDNhEXdcLEcLccM O1PVW3F/H8SGF6++XmFH2DvMi3goG08IOau3f36ReOiEr1ZT2tMrt1Z8LeBwOy62KnRGdZneH jhgmn+4AFmVTXZhbBr3s2wi+2cep/lyl80itTfGv40x9zUOjzHapenMGt5Zg8fRMK1VTB6j/x T0ZJiy8PpFkd51otWyKpsrMeIx+KFJf2sea2wojtznozLGm0KS8ETjbd2LalVyUQLDpEJ3z X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201010_145222_439118_03A075E7 X-CRM114-Status: GOOD ( 33.81 ) 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 , Fenghua Yu , Linus Walleij , Tony Luck , Thomas Gleixner , Parisc List , linux-ia64@vger.kernel.org, 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 , Greg Ungerer , 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 Sat, Oct 10, 2020 at 12:21 AM Finn Thain wrote: > > 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. Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just trying to find out where it should be headed. I would hope the other patches can just get merged. > On m68k, HZ is fixed at 100. Without addressing that, would there be any > benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch? I don't think so, I mainly did it to see if there is a problem with mixing the two modes, and I couldn't find any. The behavior seems unchanged before and after my patch, the main difference being a few extra kilobytes in kernel .text for the generic clockevents code. > 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. Good point, though I would be surprised if anything went wrong with this patch on real hardware but not in emulation, as all the register-level interactions with the timer are the same. Adding oneshot mode is a completely different matter though, that clearly needs to be tested on real hardware. > > 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. Ah, good. This is partly what I had been hoping for, as my patch can be used as a starting point for that if you want to give it a go. Arnd _______________________________________________ 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: Arnd Bergmann Date: Sat, 10 Oct 2020 18:52:01 +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> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Finn Thain 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, Parisc List , linux-m68k , Linux ARM On Sat, Oct 10, 2020 at 12:21 AM Finn Thain wrote: > > 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. Yes, correct. I marked this patch as RFC instead of PATCH, as I'm just trying to find out where it should be headed. I would hope the other patches can just get merged. > On m68k, HZ is fixed at 100. Without addressing that, would there be any > benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch? I don't think so, I mainly did it to see if there is a problem with mixing the two modes, and I couldn't find any. The behavior seems unchanged before and after my patch, the main difference being a few extra kilobytes in kernel .text for the generic clockevents code. > 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. Good point, though I would be surprised if anything went wrong with this patch on real hardware but not in emulation, as all the register-level interactions with the timer are the same. Adding oneshot mode is a completely different matter though, that clearly needs to be tested on real hardware. > > 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. Ah, good. This is partly what I had been hoping for, as my patch can be used as a starting point for that if you want to give it a go. Arnd