RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Thu, Jan 26, 2012 at 05:23:30, john stultz wrote:
> On Wed, 2012-01-18 at 16:58 +0530, Vaibhav Hiremath wrote:
> > +/**
> > + * read_persistent_clock - Return time from a persistent clock.
> > + *
> > + * Reads the time from a source which isn't disabled during PM, the
> > + * 32k sync timer. Convert the cycles elapsed since last read into
> > + * nsecs and adds to a monotonically increasing timespec.
> > + */
> > +void read_persistent_clock(struct timespec *ts)
> > +{
> > + cycles_t delta;
> > + struct timespec *tsp;
> > + unsigned long long nsecs;
> > + struct omap_counter_32k_device *omap = cs;
> > +
> > + if (!omap) {
> > + ts->tv_sec = 0;
> > + ts->tv_nsec = 0;
> > + return;
> > + }
> > + tsp = &omap->persistent_ts;
> > +
> > + omap->last_cycles = omap->cycles;
> > + omap->cycles = omap->cs.read(&omap->cs);
> > + delta = omap->cycles - omap->last_cycles;
> > +
> > + nsecs = clocksource_cyc2ns(delta,
> > + omap->cs.mult, omap->cs.shift);
> > +
> > + timespec_add_ns(tsp, nsecs);
> > + *ts = *tsp;
> > +}
>
> Hrm. So read_persistent_clock should probably be defined once per arch.
> So I'm not sure if it makes sense to include this implementation into
> the generic drivers/clocksource directory, as if some other arch tried
> to include this clocksource (say if they had the same hardware) they
> might have collisions w/ their read_persistent_clock implementation.
>
>
> I'm all for being able to re-use clocksource drivers. But this is the
> sort of thing that makes me worry we're maybe being too aggressive in
> pushing clocksources that really are fairly arch/platform specific into
> drivers/clocksource/
>
John,
Sorry for delayed response and thanks for your comments.
Just FYI, we had already aligned on the list that, this is not going
to work, and after discussion I have already submitted newer version
of the omap timer cleanup code -
http://marc.info/?l=linux-omap&m=132730863303625&w=2
Thanks,
Vaibhav
> thanks
> -john
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, 2012-01-18 at 16:58 +0530, Vaibhav Hiremath wrote:
> +/**
> + * read_persistent_clock - Return time from a persistent clock.
> + *
> + * Reads the time from a source which isn't disabled during PM, the
> + * 32k sync timer. Convert the cycles elapsed since last read into
> + * nsecs and adds to a monotonically increasing timespec.
> + */
> +void read_persistent_clock(struct timespec *ts)
> +{
> + cycles_t delta;
> + struct timespec *tsp;
> + unsigned long long nsecs;
> + struct omap_counter_32k_device *omap = cs;
> +
> + if (!omap) {
> + ts->tv_sec = 0;
> + ts->tv_nsec = 0;
> + return;
> + }
> + tsp = &omap->persistent_ts;
> +
> + omap->last_cycles = omap->cycles;
> + omap->cycles = omap->cs.read(&omap->cs);
> + delta = omap->cycles - omap->last_cycles;
> +
> + nsecs = clocksource_cyc2ns(delta,
> + omap->cs.mult, omap->cs.shift);
> +
> + timespec_add_ns(tsp, nsecs);
> + *ts = *tsp;
> +}
Hrm. So read_persistent_clock should probably be defined once per arch.
So I'm not sure if it makes sense to include this implementation into
the generic drivers/clocksource directory, as if some other arch tried
to include this clocksource (say if they had the same hardware) they
might have collisions w/ their read_persistent_clock implementation.
I'm all for being able to re-use clocksource drivers. But this is the
sort of thing that makes me worry we're maybe being too aggressive in
pushing clocksources that really are fairly arch/platform specific into
drivers/clocksource/
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Thu, Jan 19, 2012 at 18:39:26, Tony Lindgren wrote:
> * Russell King - ARM Linux [120118 06:18]:
> > On Wed, Jan 18, 2012 at 02:45:36PM +, Marc Zyngier wrote:
> > > Can't you instead use the ARM sched_clock framework?
> >
> > OMAP does, and has done for quite some time. The problem is these
> > patches are against an old kernel.
>
> Additionally we're already handling the 32k timer or not case already
> on omap1 as it does not exist on 1510, so there should only minimal
> patching needed AFAIK.
>
Tony,
All this is handled using cpu_is_omap() checks, something like,
int __init omap_init_clocksource_32k(void) {
...
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
...
...
...
}
}
This will not help for omap2/3+ devices.
I have cleaned up the code and about to submit it, please review
it and provide the comments.
Submitting shortly...
Thanks,
Vaibhav
> Tony
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
* Russell King - ARM Linux [120118 06:18]: > On Wed, Jan 18, 2012 at 02:45:36PM +, Marc Zyngier wrote: > > Can't you instead use the ARM sched_clock framework? > > OMAP does, and has done for quite some time. The problem is these > patches are against an old kernel. Additionally we're already handling the 32k timer or not case already on omap1 as it does not exist on 1510, so there should only minimal patching needed AFAIK. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 02:45:36PM +, Marc Zyngier wrote: > Can't you instead use the ARM sched_clock framework? OMAP does, and has done for quite some time. The problem is these patches are against an old kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:38, Hiremath, Vaibhav wrote:
> On Wed, Jan 18, 2012 at 19:55:51, Marc Zyngier wrote:
>> On 18/01/12 14:11, Russell King - ARM Linux wrote:
>>> On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote:
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote:
>> Convert counter_32k clocksource driver to standard platform_driver
>> and move it drivers/clocksource/ directory.
>>
>> Also, rename it to more generic name "omap-32k.c".
>
> NAK. sched_clock is supposed to be available early. Platform device
> driver initialization is FAR too late.
>
Russell,
Sched_clock is available very early during boot sequence. Initially
gp-timer
(dmtimer) will get registered as a clocksource. Please refer to the file
mach-omap2/timer.c
32k_sync timer (omap-32k.c) will come get registered during arch_init.
Just FYI, the way I tested it is, I used kernel parameter
"clocksourse=counter-32k", the switch from gp-timer to 32k timer
will happen once it gets registered.
>>>
>>> So please delete the sched_clock code from the 32k timer stuff you've
>>> moved to a platform driver. It will cause sched_clock to reset to zero,
>>> and that's bad news.
>>>
>>> Only one sched_clock() should ever be registered, and that should only be
>>> registered very early at boot time.
>>
>> The kernel will WARN if two sched_clock() are registered. I hope this
>> will be enough for people not to persist with such a thing...
>>
> Marc,
>
> This code-snippet is not registering multiple sched_clock() functions,
> Here we have 2 timers
> - gp-timer (available on all devices)
> - 32k-sync timer (may not available on all devices, like AM33xx)
>
> So we are registering both the timers as a clocksource and kernel
> Chooses one based on kernel-parameter or rating.
> From sched_clock perspective, we have only one function exported in
> mach-omap2/timer.c, which in-turn calls omap-32k.c timer api.
>
> Something like this,
>
>
> unsigned long long notrace sched_clock(void)
> {
> U32 cyc;
>
> /* First call 32k-sync timer sched_clock() */
> /* return 0 means, the device doesn't have 32k-sync timer available */
> cyc = sched_clock_32k();
> if (cyc)
> return cyc;
>
> /* Fall back to gp-timer approach */
> }
>
> So there is and will not be any warning from kernel here.
Can't you instead use the ARM sched_clock framework? Please have a look
at what's currently in mainline (we basically register a read() function
with the sched_clock framework).
A per-platform sched_clock() is a step backward for the single zImage
work, and I really want to avoid this.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 19:55:51, Marc Zyngier wrote:
> On 18/01/12 14:11, Russell King - ARM Linux wrote:
> > On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote:
> >> On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote:
> >>> On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote:
> Convert counter_32k clocksource driver to standard platform_driver
> and move it drivers/clocksource/ directory.
>
> Also, rename it to more generic name "omap-32k.c".
> >>>
> >>> NAK. sched_clock is supposed to be available early. Platform device
> >>> driver initialization is FAR too late.
> >>>
> >> Russell,
> >>
> >> Sched_clock is available very early during boot sequence. Initially
> >> gp-timer
> >> (dmtimer) will get registered as a clocksource. Please refer to the file
> >> mach-omap2/timer.c
> >>
> >> 32k_sync timer (omap-32k.c) will come get registered during arch_init.
> >>
> >> Just FYI, the way I tested it is, I used kernel parameter
> >> "clocksourse=counter-32k", the switch from gp-timer to 32k timer
> >> will happen once it gets registered.
> >
> > So please delete the sched_clock code from the 32k timer stuff you've
> > moved to a platform driver. It will cause sched_clock to reset to zero,
> > and that's bad news.
> >
> > Only one sched_clock() should ever be registered, and that should only be
> > registered very early at boot time.
>
> The kernel will WARN if two sched_clock() are registered. I hope this
> will be enough for people not to persist with such a thing...
>
Marc,
This code-snippet is not registering multiple sched_clock() functions,
Here we have 2 timers
- gp-timer (available on all devices)
- 32k-sync timer (may not available on all devices, like AM33xx)
So we are registering both the timers as a clocksource and kernel
Chooses one based on kernel-parameter or rating.
>From sched_clock perspective, we have only one function exported in
mach-omap2/timer.c, which in-turn calls omap-32k.c timer api.
Something like this,
unsigned long long notrace sched_clock(void)
{
U32 cyc;
/* First call 32k-sync timer sched_clock() */
/* return 0 means, the device doesn't have 32k-sync timer available */
cyc = sched_clock_32k();
if (cyc)
return cyc;
/* Fall back to gp-timer approach */
}
So there is and will not be any warning from kernel here.
Thanks,
Vaibhav
> M.
> --
> Jazz is not dead. It just smells funny...
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On 18/01/12 14:11, Russell King - ARM Linux wrote: > On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: >> On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: >>> On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: Convert counter_32k clocksource driver to standard platform_driver and move it drivers/clocksource/ directory. Also, rename it to more generic name "omap-32k.c". >>> >>> NAK. sched_clock is supposed to be available early. Platform device >>> driver initialization is FAR too late. >>> >> Russell, >> >> Sched_clock is available very early during boot sequence. Initially gp-timer >> (dmtimer) will get registered as a clocksource. Please refer to the file >> mach-omap2/timer.c >> >> 32k_sync timer (omap-32k.c) will come get registered during arch_init. >> >> Just FYI, the way I tested it is, I used kernel parameter >> "clocksourse=counter-32k", the switch from gp-timer to 32k timer >> will happen once it gets registered. > > So please delete the sched_clock code from the 32k timer stuff you've > moved to a platform driver. It will cause sched_clock to reset to zero, > and that's bad news. > > Only one sched_clock() should ever be registered, and that should only be > registered very early at boot time. The kernel will WARN if two sched_clock() are registered. I hope this will be enough for people not to persist with such a thing... M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 19:41:47, Russell King - ARM Linux wrote: > On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: > > On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: > > > On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: > > > > Convert counter_32k clocksource driver to standard platform_driver > > > > and move it drivers/clocksource/ directory. > > > > > > > > Also, rename it to more generic name "omap-32k.c". > > > > > > NAK. sched_clock is supposed to be available early. Platform device > > > driver initialization is FAR too late. > > > > > Russell, > > > > Sched_clock is available very early during boot sequence. Initially > > gp-timer > > (dmtimer) will get registered as a clocksource. Please refer to the file > > mach-omap2/timer.c > > > > 32k_sync timer (omap-32k.c) will come get registered during arch_init. > > > > Just FYI, the way I tested it is, I used kernel parameter > > "clocksourse=counter-32k", the switch from gp-timer to 32k timer > > will happen once it gets registered. > > So please delete the sched_clock code from the 32k timer stuff you've > moved to a platform driver. It will cause sched_clock to reset to zero, > and that's bad news. > Oops...you are right, yes it may get reset to zero. Missed this point. > Only one sched_clock() should ever be registered, and that should only be > registered very early at boot time. > I think this whole platform_driver approach will not work here, I have to cleanup existing plat-omap/counter-32k.c code only and add hwmod (eventually DT) support in it. I was also not fully convinced with this approach, just followed legacy code here; and that was the reason I have submitted patch-series as a RFC to initiate discussion and get some community opinion. Thanks Russell... Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 01:34:55PM +, Hiremath, Vaibhav wrote: > On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: > > On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: > > > Convert counter_32k clocksource driver to standard platform_driver > > > and move it drivers/clocksource/ directory. > > > > > > Also, rename it to more generic name "omap-32k.c". > > > > NAK. sched_clock is supposed to be available early. Platform device > > driver initialization is FAR too late. > > > Russell, > > Sched_clock is available very early during boot sequence. Initially gp-timer > (dmtimer) will get registered as a clocksource. Please refer to the file > mach-omap2/timer.c > > 32k_sync timer (omap-32k.c) will come get registered during arch_init. > > Just FYI, the way I tested it is, I used kernel parameter > "clocksourse=counter-32k", the switch from gp-timer to 32k timer > will happen once it gets registered. So please delete the sched_clock code from the 32k timer stuff you've moved to a platform driver. It will cause sched_clock to reset to zero, and that's bad news. Only one sched_clock() should ever be registered, and that should only be registered very early at boot time. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 17:29:52, Russell King - ARM Linux wrote: > On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: > > Convert counter_32k clocksource driver to standard platform_driver > > and move it drivers/clocksource/ directory. > > > > Also, rename it to more generic name "omap-32k.c". > > NAK. sched_clock is supposed to be available early. Platform device > driver initialization is FAR too late. > Russell, Sched_clock is available very early during boot sequence. Initially gp-timer (dmtimer) will get registered as a clocksource. Please refer to the file mach-omap2/timer.c 32k_sync timer (omap-32k.c) will come get registered during arch_init. Just FYI, the way I tested it is, I used kernel parameter "clocksourse=counter-32k", the switch from gp-timer to 32k timer will happen once it gets registered. Thanks, Vaibhav > Note that some of the code you're moving has changed in current kernels. > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, Jan 18, 2012 at 04:58:02PM +0530, Vaibhav Hiremath wrote: > Convert counter_32k clocksource driver to standard platform_driver > and move it drivers/clocksource/ directory. > > Also, rename it to more generic name "omap-32k.c". NAK. sched_clock is supposed to be available early. Platform device driver initialization is FAR too late. Note that some of the code you're moving has changed in current kernels. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
Convert counter_32k clocksource driver to standard platform_driver
and move it drivers/clocksource/ directory.
Also, rename it to more generic name "omap-32k.c".
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Felipe Balbi
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Tarun Kanti DebBarma
Cc: Kevin Hilman
---
arch/arm/mach-omap2/timer.c | 17 ---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/counter_32k.c | 154
drivers/clocksource/Makefile |1 +
drivers/clocksource/omap-32k.c | 210 ++
include/linux/clocksource.h |1 +
6 files changed, 213 insertions(+), 172 deletions(-)
delete mode 100644 arch/arm/plat-omap/counter_32k.c
create mode 100644 drivers/clocksource/omap-32k.c
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index bfae81b..46b81df 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -233,22 +233,6 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
gptimer_id, clkev.rate);
}
-/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -307,7 +291,6 @@ static void __init omap2_gp_clocksource_init(int gptimer_id,
pr_err("Could not register clocksource %s\n",
clocksource_gpt.name);
}
-#endif
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, \
clksrc_nr, clksrc_src) \
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b35bb93 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
deleted file mode 100644
index a6cbb71..000
--- a/arch/arm/plat-omap/counter_32k.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * OMAP 32ksynctimer/counter_32k-related code
- *
- * Copyright (C) 2009 Texas Instruments
- * Copyright (C) 2010 Nokia Corporation
- * Tony Lindgren
- * Added OMAP4 support - Santosh Shilimkar
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * NOTE: This timer is not the same timer as the old OMAP1 MPU timer.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include
-#include
-
-#include
-
-/*
- * 32KHz clocksource ... always available, on pretty most chips except
- * OMAP 730 and 1510. Other timers could be used as clocksources, with
- * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
- * but systems won't necessarily want to spend resources that way.
- */
-static void __iomem *timer_32k_base;
-
-#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-
-/*
- * Returns current time from boot in nsecs. It's OK for this to wrap
- * around for now, as it's just a relative time stamp.
- */
-static DEFINE_CLOCK_DATA(cd);
-
-/*
- * Constants generated by clocks_calc_mult_shift(m, s, 32768, NSEC_PER_SEC,
60).
- * This gives a resolution of about 30us and a wrap period of about 36hrs.
- */
-#define SC_MULT40u
-#define SC_SHIFT 17
-
-static inline unsigned long long notrace _omap_32k_sched_clock(void)
-{
- u32 cyc = timer_32k_base ? __raw_readl(timer_32k_base) : 0;
- return cyc_to_fixed_sched_clock(&cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
-}
-
-#if defined(CONFIG_OMAP_32K_TIMER) && !defined(CONFIG_OMAP_MPU_TIMER)
-unsigned long long notrace sched_clock(void)
-{
- return _omap_32k_sched_clock();
-}
-#else
-unsigned long long notrace omap_32k_sched_clock(void)
-{
- return _omap_32k_sched_clock();
-}
-#endif
-
-static void notrace omap_update_sched_clock(void)
-{
- u32 cyc = timer_32k_base ? __raw_readl(timer_32k_base) : 0;
- update_sched_clock(&cd, cyc, (u32)~0);
-}
-
-/**
- * read_persistent_clock - Return time from a persistent clock.
- *
- * Reads the time from a source which isn't disabled during PM, the
- * 32k sync timer. Convert the cycles elapsed since last read into
- * nsecs and adds to a monotonically increasing timespec.
- */
-static struct timespec persistent_ts;
-static cycles_t cycles, last_cycles;
-static unsigned int persistent_mult, persistent_shift;
-void read_persistent_clock(struct timespec *ts)
-
