On Monday 05 October 2015 04:13:41 Tony Lindgren wrote:

* Arnd Bergmann [off-list ref] [151005 04:08]:

quoted

On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:

quoted

* Daniel Lezcano [off-list ref] [151001 15:16]:

quoted

On 09/30/2015 04:49 PM, Arnd Bergmann wrote:

quoted

On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:

quoted

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?

I found the 'sleeptime_injected' variable now, which takes care of
forwarding the clock by the correct amount.

I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which
should let us use the counter32k driver to provide the correct
time during suspend without the omap_read_persistent_clock() function.
We should be able to just delete that code.

If we decide to also delete the tegra_read_persistent_clock()
function, we can remove the registration too.

+1

We could maybe have read_persistent_clock() just check for the
CLOCK_SOURCE_SUSPEND_NONSTOP flag?

timekeeping_resume() already ignores the persistent clock values if
the clocksource has this set. Do you mean we should additionally
not call the read_persistent_clock() function at all to safe a
few cycles reading that value?

Hmm no I mean if we have CLOCK_SOURCE_SUSPEND_NONSTOP we can
automatically make read_persistent_clock() use that if nothing
else got registered.

Ok, so we don't need to change anything here then.

quoted

How expensive is the function?

Usually the persistent clock is on some interconnect, so it is
way slower compared to a local timer. It doubt it makes a
difference in timekeeping_resume() though 

Right.

	Arnd