Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

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

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> 
> 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.

	Arnd

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Wed, Sep 30, 2015 at 04:49:53PM +0200, Arnd Bergmann wrote:
> On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > 
> > 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.

cool, I'll try to have a look at that after this series gets accepted.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Wed, Sep 30, 2015 at 04:49:53PM +0200, Arnd Bergmann wrote:
> On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > 
> > 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.

This was discussed a very long time ago, but I can't remember most of
the context. I found this in my inbox:

	https://lkml.org/lkml/2014/11/7/605

But I don't remember if there was an outcome or if anything came of
that. I'm currently busy with some other work, but thought I'd drop
this reference here in case somebody wants to dig into it before I
get around to it.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Daniel Lezcano]

On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
>>
>> 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


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Tony Lindgren]

* Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [151001 15:16]:
> On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> >>
> >>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?

And we probably should have also has_persistent_clock() or something
that also checks for the CLOCK_SOURCE_SUSPEND_NONSTOP.

Regards,

Tony

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> * Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [151001 15:16]:
> > On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > >>
> > >>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?

How expensive is the function?

	Arnd

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Tony Lindgren]

* Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> [151005 04:08]:
> On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> > * Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [151001 15:16]:
> > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > > >>
> > > >>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.

> 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 :)

Regards,

Tony

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Monday 05 October 2015 04:13:41 Tony Lindgren wrote:
> * Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> [151005 04:08]:
> > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> > > * Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [151001 15:16]:
> > > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> > > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > > > >>
> > > > >>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.

> > 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