[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMz4kuJjhhty7HigPEA6Gm4HtFk_3t1aCwbX3c0mLLQF8SZBLw@mail.gmail.com>
Date: Wed, 16 May 2018 10:20:17 +0800
From: Baolin Wang <baolin.wang@...aro.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Tony Lindgren <tony@...mide.com>, aaro.koskinen@....fi,
linux@...linux.org.uk, Mark Rutland <mark.rutland@....com>,
Marc Zyngier <marc.zyngier@....com>,
Mark Brown <broonie@...nel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
mlichvar@...hat.com, rdunlap@...radead.org,
Kate Stewart <kstewart@...uxfoundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
Philippe Ombredanne <pombredanne@...b.com>,
Thierry Reding <thierry.reding@...il.com>,
Jon Hunter <jonathanh@...dia.com>,
Heiko Stübner <heiko@...ech.de>,
Linus Walleij <linus.walleij@...aro.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, peterz@...radead.org,
douly.fnst@...fujitsu.com, len.brown@...el.com,
rajvi.jingar@...el.com,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
x86@...nel.org, Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-tegra@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH 00/10] Add persistent clock support
Hi Daniel,
On 15 May 2018 at 18:27, Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
> On Mon, May 14, 2018 at 04:55:26PM +0800, Baolin Wang wrote:
>> 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.
>
> First, can you elaborate what you mean by 'suspend state' ? On which power
What I mean is the high resolution timer will be stopped when the
system goes into suspend state.
> domain the clocksource belongs to?
On Spreadtrum platform, It belongs to one power domain named
"APCPU_TOP", that will be power down when the system goes into suspend
state.
--
Baolin.wang
Best Regards
Powered by blists - more mailing lists