From patchwork Mon May 14 08:55:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "\(Exiting\) Baolin Wang" X-Patchwork-Id: 135688 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp1483604lji; Mon, 14 May 2018 01:56:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZohN2dx08/xO3BfKiHhU8eS6htDctbxDB25lqbeGuGLg+ENVz9YoUQEfPbWbSXkWwIL9US/ X-Received: by 2002:a17:902:584:: with SMTP id f4-v6mr8859049plf.290.1526288171380; Mon, 14 May 2018 01:56:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526288171; cv=none; d=google.com; s=arc-20160816; b=GCxZuTRVOLoy0jKbvfI76o1uJzFk9GGefPgREvOC7wB8YhnQS0fIiRRbknnjbSZ6Uq K0J0J9J5LaY5JCTSDZuNBZhBOdEEGiquu/C1Vuyp2n0RPWgRmJpO8Rb/WjHzbCWBuU0l IgGk3HfDNk9siLvLP9vk9GWR4b2NajlBK+4TRJH4gWEQ59+YteoCTtXPmRADaiN07ir/ gDmLjVIq8TocF0SP20vr8+X6BsremuZYpO7xu7s6pphuPzL+ICOM4uqe8isvZT30dsH+ r24bekEiOcxUDJS8TDqDKwSXEuOUB0fJpIps5GKP+ndX8sb+GS7ExShYJ8PCgVy+BABX vTmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=XeYb53FFJwgdX56IP49bU6xgfvqHalY8spcheRakF1Q=; b=acdvhTlNyci1GB1qC4iCKg1svE/MG3nEm51GNrLa3g9vOHDpl/U/14nzW1MJqhkNLv 61EVwy+fuC3dWzQnMLCtnnFwQdZBV96iUy1SuGoMKyl1KmJ0r85ghxdyI+bLq1y3G9hM ujFeW0u0zfVc+5snSNKxVwVCKijot+6CfFNSBE57LsCAv0MKhHtQLnQcRseZchjO+ue2 gZChI9ge/LsK8eLQ7f+290OgrOOCBtbozvd8lKMjWqBPTvu4eCYtrnqZqtMvlk8JNg2l wt9f+ej75Rki3jogH1CZWWACz+jDs8RP7ddpHFuqkGxfQ50HosjXTnggc+mlim876bpt /vTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=AfdjUSlB; spf=pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-omap-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t189-v6si1558912pgc.163.2018.05.14.01.56.11; Mon, 14 May 2018 01:56:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=AfdjUSlB; spf=pass (google.com: best guess record for domain of linux-omap-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-omap-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751596AbeENI4J (ORCPT + 5 others); Mon, 14 May 2018 04:56:09 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:35465 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbeENI4H (ORCPT ); Mon, 14 May 2018 04:56:07 -0400 Received: by mail-pg0-f67.google.com with SMTP id n1-v6so5200903pgs.2 for ; Mon, 14 May 2018 01:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=YUFJIUoY3B3ZtQsKdHonvy3g7YnxVyJWIrER/dt+G5E=; b=AfdjUSlBjaxbKGlXLes3DMkO7B+f/pG+SV/rS/6TVB5M/ok8wG2eLGuLqDsXfavL31 UK/EHJnynWFLdU7Qe0DcdB/gREr8wlUpg/XjgQ8evKRuU0ZB2tl4kS5ucSPD1ePDXB/0 uGqH0V56mNfMs8JZz4S+i+vSK/2ReCUm46j20= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=YUFJIUoY3B3ZtQsKdHonvy3g7YnxVyJWIrER/dt+G5E=; b=eFmzqD1tnBdBNv0QsNTM97sy40Lhc9pbjTC+mkGpW5j7WPox5i/0tbJt/J/ZYcVieg TCnZbsDTwkrEWrf1K0XfA9yNsiCsvcCdY2uS7buxkXtqXdhcxFO+TSgAWOagniPOtvCL U8W5a/mfQNzySgzKwNfkEkseYsSw/Vjm9J1dxlKM+nivDVQLiafYxCMK0/nEeC52k7k7 Cl6bKA2NdZs0Hi+J03CpxjSMwLaYIxRrtiwOnoVOtp2L4CYGzw9ai8PkZEE0ebnxyl/B 4ck5zHcJfuQLVJnM3zng/YJdALTKHCujT3h0zSFaKSbfMuKM0u+UVdKTwydS/7pfy5PV 8q5A== X-Gm-Message-State: ALKqPwePsHqYlOOpJD8f+Tht0G3gX7muoEze8PDeqpklHAl67rbHxHSk mEH6HOzQCehB5Xp98cHyDf/c2Q== X-Received: by 2002:a62:b204:: with SMTP id x4-v6mr9514659pfe.21.1526288167247; Mon, 14 May 2018 01:56:07 -0700 (PDT) Received: from baolinwangubtpc.spreadtrum.com ([117.18.48.102]) by smtp.gmail.com with ESMTPSA id x71-v6sm23308158pfe.47.2018.05.14.01.55.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 May 2018 01:56:06 -0700 (PDT) From: Baolin Wang To: tglx@linutronix.de, john.stultz@linaro.org, daniel.lezcano@linaro.org, arnd@arndb.de, tony@atomide.com, aaro.koskinen@iki.fi, linux@armlinux.org.uk, mark.rutland@arm.com, marc.zyngier@arm.com Cc: baolin.wang@linaro.org, broonie@kernel.org, paulmck@linux.vnet.ibm.com, mlichvar@redhat.com, rdunlap@infradead.org, kstewart@linuxfoundation.org, gregkh@linuxfoundation.org, pombredanne@nexb.com, thierry.reding@gmail.com, jonathanh@nvidia.com, heiko@sntech.de, linus.walleij@linaro.org, viresh.kumar@linaro.org, mingo@kernel.org, hpa@zytor.com, peterz@infradead.org, douly.fnst@cn.fujitsu.com, len.brown@intel.com, rajvi.jingar@intel.com, alexandre.belloni@bootlin.com, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org Subject: [RFC PATCH 00/10] Add persistent clock support Date: Mon, 14 May 2018 16:55:26 +0800 Message-Id: X-Mailer: git-send-email 1.7.9.5 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Hi, We will meet below issues when compensating the suspend time for the timekeeping. 1. We have too many different ways of dealing with persistent timekeeping across architectures, so it is hard for one driver to compatable with different architectures. 2. On some platforms (such as Spreadtrum platform), we registered the high resolution timer as one clocksource to update the OS time, but the high resolution timer will be stopped in suspend state. So we use another one always-on timer (but low resolution) to calculate the suspend time to compensate the OS time. Though we can register the always-on timer as one clocksource, we need re-calculate the mult/shift with one larger conversion range to calculate the suspend time and need update the clock in case of running over the always-on timer. More duplicate code will be added if other platforms meet this case. 3. Now we have 3 sources that could be used to compensate the OS time: Nonstop clocksource during suspend, persistent clock and rtc device, which is complicated. Another hand is that the nonstop clocksource can risk wrapping if the suspend time is too long, so we need one mechanism to wake up the system before the nonstop clocksource wrapping. According to above issues, we can introduce one common persistent clock framework to compatable with different architectures, in future we will remove the persistent clock implementation for each architecture. Also this framework will implement common code to help drivers to register easily. Moreover if we converted all SUSPEND_NONSTOP clocksource to register to be one persistent clock, we can remove the SUSPEND_NONSTOP clocksource accounting in timekeeping, which means we can only compensate the OS time from persistent clock and RTC. Will be appreciated for any comments. Thank you all. Arnd posted some comments as below last time, but we did not get a general consensus, so I post them again. Arnd said: "I was planning to discuss this with Daniel and John during Linaro Connect, but that didn't happen, so I'd like to bring up the bigger picture here again. Today, we have a number of subsystem-type interfaces that deal with time keeping in the wider sense (I might be missing some): - clock source - clock event - sched clock - real time clock - ptp clock - persistent clock The first five have separate registration interfaces and may all refer to different hardware blocks, or (more commonly) have some overlap in the hardware. The fifth one is generalized by your series, without it it's really architecture specific (as the other ones were one one point). Are we happy with that structure in the long run? One of my earlier comments on this series was that I thought it should be combined with the clocksource registration, but upon talking to Baolin about it more, I realized that this just follows the same structure that we have for the others. In theory, we could have a more abstract way of registering a clock hardware that interfaces with any combination of the six subsystems I mentioned above, with a superset of the subsystem specific structures and a set of flags that indicate what a particular device is usable for. Combining all six might be a bit too much (in particular rtc, though it clearly overlaps the persistent-clk case), but what your general ideas on where we should be heading? Is it worth reworking the core kernel portion of the subsystems to simplify the individual drivers?" Baolin Wang (10): time: Add persistent clock support clocksource: sprd: Add one persistent timer for Spreadtrum platform arm: omap: Convert 32K counter to use persistent clock clocksource: tegra20_timer: Remove register_persistent_clock() API arm: time: Remove the persistent clock support for ARM clocksource: arm_arch_timer: Register the persistent clock clocksource: timer-ti-32k: Register the persistent clock clocksource: time-pistachio: Register the persistent clock x86: tsc: Register the persistent clock time: timekeeping: Remove time compensating from nonstop clocksources arch/arm/include/asm/mach/time.h | 4 - arch/arm/kernel/time.c | 36 ------- arch/arm/plat-omap/Kconfig | 1 + arch/arm/plat-omap/counter_32k.c | 44 ++------- arch/x86/Kconfig | 1 + arch/x86/kernel/tsc.c | 16 +++ drivers/clocksource/Kconfig | 4 + drivers/clocksource/arm_arch_timer.c | 10 ++ drivers/clocksource/tegra20_timer.c | 12 ++- drivers/clocksource/time-pistachio.c | 3 + drivers/clocksource/timer-sprd.c | 80 +++++++++++++++ drivers/clocksource/timer-ti-32k.c | 4 + include/linux/persistent_clock.h | 21 ++++ kernel/time/Kconfig | 4 + kernel/time/Makefile | 1 + kernel/time/persistent_clock.c | 180 ++++++++++++++++++++++++++++++++++ kernel/time/timekeeping.c | 19 +--- 17 files changed, 345 insertions(+), 95 deletions(-) create mode 100644 include/linux/persistent_clock.h create mode 100644 kernel/time/persistent_clock.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html