Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1235545 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [RFC/PATCH 00/11] arm: omap: counter32k rework Felipe Balbi <balbi@ti.com> - 2015-09-29 22:50 +0200
    Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Arnd Bergmann <arnd@arndb.de> - 2015-09-30 10:30 +0200
      Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Felipe Balbi <balbi@ti.com> - 2015-09-30 16:20 +0200
        Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Arnd Bergmann <arnd@arndb.de> - 2015-09-30 16:50 +0200
          Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Felipe Balbi <balbi@ti.com> - 2015-09-30 17:00 +0200
          Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Arnd Bergmann <arnd@arndb.de> - 2015-09-30 17:00 +0200
            Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Thierry Reding <thierry.reding@gmail.com> - 2015-09-30 17:10 +0200
            Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Daniel Lezcano <daniel.lezcano@linaro.org> - 2015-10-02 00:20 +0200
              Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Tony Lindgren <tony@atomide.com> - 2015-10-05 13:00 +0200
                Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Arnd Bergmann <arnd@arndb.de> - 2015-10-05 13:10 +0200
                  Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Tony Lindgren <tony@atomide.com> - 2015-10-05 13:20 +0200
                    Re: [RFC/PATCH 00/11] arm: omap: counter32k rework Arnd Bergmann <arnd@arndb.de> - 2015-10-05 14:30 +0200

#1235545 — [RFC/PATCH 00/11] arm: omap: counter32k rework

Hi,

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

ps: if anybody has a good idea on how to get rid of
register_persistent_clock(), please let me know

Felipe Balbi (11):
  arm: omap2: timer: get rid of obfuscating macros
  arm: omap2: timer: add a gptimer argument to sync32k_timer_init()
  arm: omap2: timer: remove __omap_gptimer_init()
  arm: omap2: timer: provide generic sync32k_timer_init function
  arm: omap2: timer: move realtime_counter_init() around
  arm: omap2: timer: always call clocksource_of_init() when DT
  arm: omap2: timer: remove omap4_local_timer_init
  arm: omap2: timer: rename omap_sync32k_timer_init()
  clocksource: add TI 32.768 Hz counter driver
  arm: omap2: timer: limit hwmod usage to non-DT boots
  arm: boot: dts: omap: add missing default status for 32k counter

 arch/arm/boot/dts/am4372.dtsi         |   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts   |   4 +
 arch/arm/boot/dts/am437x-idk-evm.dts  |   4 +
 arch/arm/boot/dts/am437x-sk-evm.dts   |   4 +
 arch/arm/boot/dts/am43x-epos-evm.dts  |   4 +
 arch/arm/boot/dts/dra7.dtsi           |   1 +
 arch/arm/boot/dts/omap2420-h4.dts     |   4 +
 arch/arm/boot/dts/omap2420.dtsi       |   1 +
 arch/arm/boot/dts/omap2430.dtsi       |   1 +
 arch/arm/boot/dts/omap3-beagle-xm.dts |   4 +
 arch/arm/boot/dts/omap3-beagle.dts    |   4 +
 arch/arm/boot/dts/omap3-ldp.dts       |   4 +
 arch/arm/boot/dts/omap3-n900.dts      |   4 +
 arch/arm/boot/dts/omap3.dtsi          |   1 +
 arch/arm/boot/dts/omap3430-sdp.dts    |   4 +
 arch/arm/boot/dts/omap4-sdp.dts       |   4 +
 arch/arm/boot/dts/omap4.dtsi          |   1 +
 arch/arm/boot/dts/omap5-cm-t54.dts    |   4 +
 arch/arm/boot/dts/omap5-uevm.dts      |   4 +
 arch/arm/boot/dts/omap5.dtsi          |   1 +
 arch/arm/mach-omap2/board-generic.c   |  14 ++--
 arch/arm/mach-omap2/board-ldp.c       |   2 +-
 arch/arm/mach-omap2/board-rx51.c      |   2 +-
 arch/arm/mach-omap2/common.h          |   4 +-
 arch/arm/mach-omap2/timer.c           | 138 ++++++++++++++--------------------
 drivers/clocksource/Kconfig           |   8 ++
 drivers/clocksource/Makefile          |   1 +
 drivers/clocksource/timer-ti-32k.c    | 121 +++++++++++++++++++++++++++++
 28 files changed, 255 insertions(+), 94 deletions(-)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1235884

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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236369

[Multipart message — attachments visible in raw view] — view raw

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 ?

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1236412

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236417

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1236424

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236428

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1237779

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239449

* Daniel Lezcano <daniel.lezcano@linaro.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239462

On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> * Daniel Lezcano <daniel.lezcano@linaro.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239472

* Arnd Bergmann <arnd@arndb.de> [151005 04:08]:
> On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> > * Daniel Lezcano <daniel.lezcano@linaro.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1239504

On Monday 05 October 2015 04:13:41 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [151005 04:08]:
> > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> > > * Daniel Lezcano <daniel.lezcano@linaro.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web