From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752975AbbI3Omf (ORCPT ); Wed, 30 Sep 2015 10:42:35 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:59318 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbbI3Om3 (ORCPT ); Wed, 30 Sep 2015 10:42:29 -0400 From: Arnd Bergmann To: balbi@ti.com Cc: linux-arm-kernel@lists.infradead.org, Tony Lindgren , daniel.lezcano@linaro.org, Linux Kernel Mailing List , tglx@linutronix.de, Linux OMAP Mailing List , linux-tegra@vger.kernel.org, Stephen Warren , Thierry Reding , Alexandre Courbot Subject: Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Date: Wed, 30 Sep 2015 16:42:21 +0200 Message-ID: <3705422.OMk7ysE7Jn@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150930141338.GC31865@saruman.tx.rr.com> References: <1443559446-26969-1-git-send-email-balbi@ti.com> <1986790.syN3WBv9AR@wuerfel> <20150930141338.GC31865@saruman.tx.rr.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:eE+/abiIWHUQQfqSNc0tNLhBCXqaR+CBC74APz4idfhoLZFkyt6 i5BXOsQ3POHqN4C8n/OxBhjsfi3IxdMxG5AZaIsiEY+wxTxFssEZxQE52AOk3OMBokJybw7 f8HDtVnSgEjNQPEyp+Z78Zz53TXvL64tE1x1oc9hxz7jlIkG9CYAF898XJl/4sBo+gk5IwT TU+6aB5UtC+TX+ws12d1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:EwTpX6OBb5I=:1o0P2oYlwO8i2ymOiVFV+M Xxe5J97VUGERxuqNw9F7oH5dHam6faGeNKzfcIpzWo4h5sazdvf3Yu/xNn//mNJR8Pbz3nvCM AECXaHKSzTjLOHiYkbP8TD+jzyRyo/I9XRLYyJQgZDd6HzkCgnyMNHBRJ5oRM3Tk6eSahfAZQ cWyfgCORgl4dXOuaz3w7EfhO69K8UxRz6ZzhE6CU2uFZByiVgKYvefB09GxL644WiDBPjXqCz pfWlBIRLFDMgydJf6Lb+TshiDbgCDTakV3+RIBMjqy/+JBaoV0A3msXzbNU9osAw0y9vYldKj rtsU+18pysPBvMpU/3Tbrwq9eHLk2pFEovwCGLxZmP3h6HG5ZKWCkAvAZogg5qYuF9eJcmcxQ RJL6I8lRvjhev8gdXOct7wnizcO/QH1ceBN4157UijO95k6A6p3S3vOVAVP+RTDZa9SvC64Te SU8208eBEiVhqwQNu/v69spv7WXchHr9KmXcrUVNGyStB8i/uhGAP7YIdAm+DcZLkp0MJszYX BElBsegmIit/ZwHPGI8yt/cdz+1Oy7S1iynMRDzjmLCAkh5Iz5tfyEMSD/11TwHY4iDb63Eck PSWlDobXRBjy/dDuY4KdmTN4Dda3VdBaNP/3IJB3GFoyTCrm7PRVUF4qtFbLYgGxwKg3SEHyM qwdV31eXj4JFk2DLofQ4CaVYp0MNLkhO/aF+NQQ3OggLj4TpYmRSX5REX+Qyb8UpY4pHmJXjh 2lbaGn/djzBKRlPE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 30 September 2015 09:13:38 Felipe Balbi wrote: > On Wed, Sep 30, 2015 at 10:22:46AM +0200, Arnd Bergmann wrote: > > On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote: > > > > > > the following patches de-obfuscate arch/arm/mach-omap2/timer.c > > > and start moving code to drivers/clocksource. So far only counter32k > > > has been moved over. > > > > > > Note that we can't get rid of all the code (yet) because there are > > > still platforms relying to legacy boot and because of the strong > > > coupling with OMAP's hwmod layer. > > > > > > This is, for now, an RFC and has be written on top of [1]. Boot tested > > > with AM335x and AM437x. > > > > > > [1] http://marc.info/?l=linux-omap&m=144354336924308&w=2 > > > > Looks very nice! > > > > > ps: if anybody has a good idea on how to get rid of > > > register_persistent_clock(), please let me know > > > > I don't think we want to get rid of that, because it is the more > > accurate interface. IIRC systems that have an RTC will use > > timekeeping_inject_sleeptime64() in rtc_resume(). I don't know however > > how the two methods are coordinated, i.e. how the kernel ensures that > > exactly one of the two is used, but never both. > > however register_persistent_clock() is an ARM-only thing, the question > was more towards that. Do we want to continue using the ARM-only > register_persistent_clock() or is there a more generic version of it ? Ah, got it. I wouldn't worry about it at the moment, the read_persistent_clock64 interface is very rarely used: only arm, ia64, mips/lasat and s390 define it at all, only arm has more than one implementation (omap and tegra) and the tegra, ia64 and mips implementations should really use timekeeping_inject_sleeptime64() instead. read_boot_clock64() is even rarer: only s390 defines it, apparently because it is the only architecture that uses a single register for wall-clock time and high-resolution time (it has a 96-bit quarternanosecond register that is synchronized before booting Linux). TEGRA folks: the tegra_read_persistent_clock() implementation apparently predates the Tegra RTC driver and I wonder if they actually do the right thing in combination. Could it be that the wall time forwards twice as fast as it should during resume when the RTC driver is loaded? Could it be that we can simply remove tegra_read_persistent_clock() and the register_persistent_clock() infrastructure? Arnd