lkml.org 
[lkml]   [2018]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 00/10] Add persistent clock support
On 16 May 2018 at 10:20, Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Daniel,
>
> On 15 May 2018 at 18:27, Daniel Lezcano <daniel.lezcano@linaro.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.

Sorry, I made a mistake here. Our high resolution timer is on one
always-on power domain, but it's clock will be shut down when the
system goes into suspend.

--
Baolin.wang
Best Regards

\
 
 \ /
  Last update: 2018-05-16 09:12    [W:0.030 / U:5.772 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site