* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 2:38 ` Jason Gunthorpe
@ 2012-12-14 3:13 ` Feng Tang
2012-12-14 4:10 ` Jason Gunthorpe
2012-12-14 21:36 ` John Stultz
2012-12-20 7:02 ` Feng Tang
2 siblings, 1 reply; 18+ messages in thread
From: Feng Tang @ 2012-12-14 3:13 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
> On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
>
> > So per Jason's related patch, he's made the point that the
> > persistent_clock and RTC class functionality are basically exclusive
> > (well, in his case, he said this with respect to updating the RTC,
> > not reading it - I don't mean to put words in his mouth - Please do
> > correct me here Jason. :). In other words, we probably should avoid
> > configurations where both the rtc hctosys and persistent_clock
> > interfaces are both active.
>
> I only studied update_persistent_clock, read_persistent_clock is
> very much different.
>
> Looking at it, I don't think that update_persistent_clock is in any
> way related to read_persistent_clock.. update_persistent_clock is
> *only* called by NTP, and its *only* purpose is to update the RTC with
> NTP synchronized time. In many configurations it will never even be
> called.
>
> I think update_persistent_clock is badly named, it should be called
> platform_save_ntp_time_to_rtc(), keep it divorced from
> read_presistent_clock :)
>
> > make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This
> > way we avoid having configs where there are conflicting paths that
> > we chose from.
>
> On ARM the read_presistent_clock is used to access a true monotonic
> counter that is divorced from the system RTC - look at
> arch/arm/plat-omap/counter_32k.c for instance.
>
> This seems like a great use of that hardware resource, and no doubt
> those mach's also have a class RTC driver available talking to
> different hardware.
Interesting to know this, thanks for the info. For the x86 desktop
and mobile processors I've used, the read_persistent_clock and rtc
are the same on-board device (always power on), so I see many time
related code are execuated twice, like init/suspend/resume if
HCTOSYS config is enabled, that's why I came up with the patches.
>
> For mach's without that functionality ARM returns a fixed 0 value
> from read_persistent_clock, persumably the kernel detects this and
> falls back to using class rtc functions?
>
> Maybe Feng would be better off adjusting read_persistent_clock to
> return ENODEV in such cases??
For mach's without read_persistent_clock capability, there is already
a weakly defined
void __attribute__((weak)) read_persistent_clock(struct timespec *ts)
{
ts->tv_sec = 0;
ts->tv_nsec = 0;
}
so those machs can simply do nothing, and let time core code to judge it.
>
> So, I think you have to keep your test as a run time test. To support
> the single image ARM boot you can't make the distinction with kconfig.
Good point. Figuring out the kconfig for all arm platforms is very
challenging.
Thanks,
Feng
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 3:13 ` Feng Tang
@ 2012-12-14 4:10 ` Jason Gunthorpe
2012-12-14 21:22 ` John Stultz
0 siblings, 1 reply; 18+ messages in thread
From: Jason Gunthorpe @ 2012-12-14 4:10 UTC (permalink / raw)
To: Feng Tang
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Fri, Dec 14, 2012 at 11:13:30AM +0800, Feng Tang wrote:
> > This seems like a great use of that hardware resource, and no doubt
> > those mach's also have a class RTC driver available talking to
> > different hardware.
>
> Interesting to know this, thanks for the info. For the x86 desktop
> and mobile processors I've used, the read_persistent_clock and rtc
> are the same on-board device (always power on), so I see many time
> related code are execuated twice, like init/suspend/resume if
> HCTOSYS config is enabled, that's why I came up with the patches.
Ah, I see, there is some duplication here, my earlier comments about
update_persistent_clock are not quite right, some places like PCs
stick a RTC driver and then continue to access the same hardware
directly outside the rtc driver context! That seems ugly :|
I see the PC CMOS rtc driver does not implement the set_mmss
operation, instead running that code through update_persistent_clock..
That seems like a cleanup waiting to happen.
Regarding your problem - IMHO, it would be fantastic if the class RTC
driver could be used instead of read_persistent_clock on PC.
John mentioned that read_persistent_clock had a requirement to work
with IRQs off - that seems like it would be easy to incorporate into
class rtc - for hardware that supports it (and PC is not the only RTC
HW that can do this) Is that the only reason it still exists on pc?
I have to feel the long term direction should be to remove
*_persistent_clock in favor of class RTC?
> > Maybe Feng would be better off adjusting read_persistent_clock to
> > return ENODEV in such cases??
>
> For mach's without read_persistent_clock capability, there is already
> a weakly defined
This is used for arch's without the functionality, mach's are arch
specific things. ARM provides a function pointer indirection for it's
read_persistent_clock implementation.
Jason
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 4:10 ` Jason Gunthorpe
@ 2012-12-14 21:22 ` John Stultz
2012-12-14 21:56 ` Jason Gunthorpe
0 siblings, 1 reply; 18+ messages in thread
From: John Stultz @ 2012-12-14 21:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Feng Tang, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On 12/13/2012 08:10 PM, Jason Gunthorpe wrote:
>
> Ah, I see, there is some duplication here, my earlier comments about
> update_persistent_clock are not quite right, some places like PCs
> stick a RTC driver and then continue to access the same hardware
> directly outside the rtc driver context! That seems ugly :|
>
> I see the PC CMOS rtc driver does not implement the set_mmss
> operation, instead running that code through update_persistent_clock..
> That seems like a cleanup waiting to happen.
>
> Regarding your problem - IMHO, it would be fantastic if the class RTC
> driver could be used instead of read_persistent_clock on PC.
>
> John mentioned that read_persistent_clock had a requirement to work
> with IRQs off - that seems like it would be easy to incorporate into
> class rtc - for hardware that supports it (and PC is not the only RTC
> HW that can do this) Is that the only reason it still exists on pc?
>
> I have to feel the long term direction should be to remove
> *_persistent_clock in favor of class RTC?
So yes, I'd love to see a cleanup here.
Although from a timekeeping perspective, the read_persistent_clock()
interface is actually *much* preferred over the rtc HCTOSYS device.
Since read_persistent_clock() has the requirement that its safe to call
with IRQs disabled, we can use it in the timekeeping suspend/resume
code, which allows for better time accuracy.
That said, many systems don't have a persistent clock that they can
access with irqs off, and so the timekeeping_inject_sleeptime code was
added to work with the rtc class drivers, but it is more prone to problems.
That's why I've been suggesting we add a HAS_PERSISTENT_CLOCK and make
the HCTOSYS_DEVICE depend on !HAS_PERSISTENT_CLOCK. As it avoids these
weird cases we're we have possibly duplicated code paths.
But there is the risk that some architectures may require both for some
system configs (ie: read_persistent_clock works on all but one SoC,
which has an rtc over a usb bus or something). Although its not clear
yet that this is a situation that actually exists. (And we could work
around it with something like HAS_EXCLUSIVE_PERSISTENT_CLOCK or something).
While we're suggesting cleanups, the RTC Kconfig choices probably need a
cleanup too, as the list of all possible drivers can be confusing, when
usually each architecture has only a few that they exclusively support
(I know there are exceptions to this). It makes it hard to even figure
out for a specific rtc driver what architecture one should look for in
order to test with (I usually have to look at the commit log, and then
try to associate email address with arch maintainers). A good number of
drivers are fine, and already depend on the SoC platform support being
there, but I suspect we could narrow a number of the drivers down to one
or two arches or even platforms that acutally make use of it.
thanks
-john
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 21:22 ` John Stultz
@ 2012-12-14 21:56 ` Jason Gunthorpe
2012-12-14 23:23 ` John Stultz
2012-12-17 16:14 ` Feng Tang
0 siblings, 2 replies; 18+ messages in thread
From: Jason Gunthorpe @ 2012-12-14 21:56 UTC (permalink / raw)
To: John Stultz
Cc: Feng Tang, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
> Although from a timekeeping perspective, the read_persistent_clock()
> interface is actually *much* preferred over the rtc HCTOSYS device.
>
> Since read_persistent_clock() has the requirement that its safe to
> call with IRQs disabled, we can use it in the timekeeping
> suspend/resume code, which allows for better time accuracy.
Sure, but my view on this is that it has nothing to do with
read_persistent_clock. If the RTC driver can run with IRQs off is a
property of the RTC driver and RTC hardware - it has nothing to do
with the platform. ARM platforms will vary on a machine by machine
basis. The rtc-mv driver used on my ARM system is perfectly
re-entrant, lots of rtc on SOC drivers will be the same.
If this is the only thing keeping you on read_persistent_clock, for
real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
rtc_device.flags?
Reserve read_persistent_clock for things like that very specialized
non-RTC ARM counter.
>
> While we're suggesting cleanups, the RTC Kconfig choices probably
> need a cleanup too, as the list of all possible drivers can be
> confusing, when usually each architecture has only a few that they
That is a general pain with the new 'everything is a driver'..
However device tree enabled stuff is much nicer, just grep the tree
for the compatible string and you'll find a big clue about what
physical boards are using that driver.
For instance:
rtc@10300 {
compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <53>;
};
is matched to:
drivers/rtc/rtc-mv.c:
static struct of_device_id rtc_mv_of_match_table[] = {
{ .compatible = "marvell,orion-rtc", },
> exclusively support (I know there are exceptions to this). It makes
> it hard to even figure out for a specific rtc driver what
> architecture one should look for in order to test with (I usually
With anything embedded the answer is 'anything and everything'
unfortunately. For example, our board has two bits of RTC capable
hardware - one inside the CPU SOC and one outside. We went through a
big analysis to pick the best one, based on battery selection and
battery life time. Even the presence of a RTC block in a SOC is not a
guarentee it will be used universally.
Regards,
Jason
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 21:56 ` Jason Gunthorpe
@ 2012-12-14 23:23 ` John Stultz
2012-12-17 16:14 ` Feng Tang
1 sibling, 0 replies; 18+ messages in thread
From: John Stultz @ 2012-12-14 23:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Feng Tang, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On 12/14/2012 01:56 PM, Jason Gunthorpe wrote:
> On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
>
>> Although from a timekeeping perspective, the read_persistent_clock()
>> interface is actually *much* preferred over the rtc HCTOSYS device.
>>
>> Since read_persistent_clock() has the requirement that its safe to
>> call with IRQs disabled, we can use it in the timekeeping
>> suspend/resume code, which allows for better time accuracy.
> Sure, but my view on this is that it has nothing to do with
> read_persistent_clock. If the RTC driver can run with IRQs off is a
> property of the RTC driver and RTC hardware - it has nothing to do
> with the platform. ARM platforms will vary on a machine by machine
> basis. The rtc-mv driver used on my ARM system is perfectly
> re-entrant, lots of rtc on SOC drivers will be the same.
>
> If this is the only thing keeping you on read_persistent_clock, for
> real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> rtc_device.flags?
>
> Reserve read_persistent_clock for things like that very specialized
> non-RTC ARM counter.
Something like this could work, although I worry it only causes even
more code paths:
1) read_persistent_clock for non-RTC counters, called from
timekeeping_suspend/resume
2) IRQ safe RTC called from timekeeping_suspend/resume
3) Non-IRQ safe RTC suspend/resume logic
>> While we're suggesting cleanups, the RTC Kconfig choices probably
>> need a cleanup too, as the list of all possible drivers can be
>> confusing, when usually each architecture has only a few that they
> That is a general pain with the new 'everything is a driver'..
True, and maybe something I just have to live with. But I can still
make holiday wish lists :)
thanks
-john
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 21:56 ` Jason Gunthorpe
2012-12-14 23:23 ` John Stultz
@ 2012-12-17 16:14 ` Feng Tang
2012-12-17 18:22 ` Jason Gunthorpe
1 sibling, 1 reply; 18+ messages in thread
From: Feng Tang @ 2012-12-17 16:14 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Fri, Dec 14, 2012 at 02:56:51PM -0700, Jason Gunthorpe wrote:
> On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
>
> > Although from a timekeeping perspective, the read_persistent_clock()
> > interface is actually *much* preferred over the rtc HCTOSYS device.
> >
> > Since read_persistent_clock() has the requirement that its safe to
> > call with IRQs disabled, we can use it in the timekeeping
> > suspend/resume code, which allows for better time accuracy.
>
> Sure, but my view on this is that it has nothing to do with
> read_persistent_clock. If the RTC driver can run with IRQs off is a
> property of the RTC driver and RTC hardware - it has nothing to do
> with the platform. ARM platforms will vary on a machine by machine
> basis. The rtc-mv driver used on my ARM system is perfectly
> re-entrant, lots of rtc on SOC drivers will be the same.
>
> If this is the only thing keeping you on read_persistent_clock, for
> real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> rtc_device.flags?
>
> Reserve read_persistent_clock for things like that very specialized
> non-RTC ARM counter.
Yes, these non-RTC device is one reason for keeping read_persistent_clock,
one other reason I can think of is the CONFIG_RTC_LIB is not always on by
default for all Archs, and some platforms may chose to disable it on purpose.
When CONFIG_RTC_LIB is not set, we need the read_persistent_clock for
time init/suspend/resume.
Thanks,
Feng
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-17 16:14 ` Feng Tang
@ 2012-12-17 18:22 ` Jason Gunthorpe
2012-12-18 2:44 ` Feng Tang
0 siblings, 1 reply; 18+ messages in thread
From: Jason Gunthorpe @ 2012-12-17 18:22 UTC (permalink / raw)
To: Feng Tang
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
> > Sure, but my view on this is that it has nothing to do with
> > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > property of the RTC driver and RTC hardware - it has nothing to do
> > with the platform. ARM platforms will vary on a machine by machine
> > basis. The rtc-mv driver used on my ARM system is perfectly
> > re-entrant, lots of rtc on SOC drivers will be the same.
> >
> > If this is the only thing keeping you on read_persistent_clock, for
> > real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> > rtc_device.flags?
> >
> > Reserve read_persistent_clock for things like that very specialized
> > non-RTC ARM counter.
>
> Yes, these non-RTC device is one reason for keeping read_persistent_clock,
> one other reason I can think of is the CONFIG_RTC_LIB is not always on by
> default for all Archs, and some platforms may chose to disable it on purpose.
> When CONFIG_RTC_LIB is not set, we need the read_persistent_clock for
> time init/suspend/resume.
I thought your concern was the case where the RTC was turned on and
read_persistent_clock was also turned on. Having a flag in the RTC and
disabling read_persistent_clock for that situation would help you
avoid the double code path to the same hardware.
What is motivating having a RTC but not using RTC lib? Embedded
doesn't seem to the be the case, nearly all the interesting rtcs are
under class rtc....
Jason
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-17 18:22 ` Jason Gunthorpe
@ 2012-12-18 2:44 ` Feng Tang
0 siblings, 0 replies; 18+ messages in thread
From: Feng Tang @ 2012-12-18 2:44 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On Mon, Dec 17, 2012 at 11:22:02AM -0700, Jason Gunthorpe wrote:
> On Tue, Dec 18, 2012 at 12:14:33AM +0800, Feng Tang wrote:
>
> > > Sure, but my view on this is that it has nothing to do with
> > > read_persistent_clock. If the RTC driver can run with IRQs off is a
> > > property of the RTC driver and RTC hardware - it has nothing to do
> > > with the platform. ARM platforms will vary on a machine by machine
> > > basis. The rtc-mv driver used on my ARM system is perfectly
> > > re-entrant, lots of rtc on SOC drivers will be the same.
> > >
> > > If this is the only thing keeping you on read_persistent_clock, for
> > > real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> > > rtc_device.flags?
> > >
> > > Reserve read_persistent_clock for things like that very specialized
> > > non-RTC ARM counter.
> >
> > Yes, these non-RTC device is one reason for keeping read_persistent_clock,
> > one other reason I can think of is the CONFIG_RTC_LIB is not always on by
> > default for all Archs, and some platforms may chose to disable it on purpose.
> > When CONFIG_RTC_LIB is not set, we need the read_persistent_clock for
> > time init/suspend/resume.
>
> I thought your concern was the case where the RTC was turned on and
> read_persistent_clock was also turned on. Having a flag in the RTC and
> disabling read_persistent_clock for that situation would help you
> avoid the double code path to the same hardware.
No, it's not about my concern (actually I don't have concerns :), my 3
patches are just some optimization).
My point is the "driver/rtc" or "drivers/rtc/class.c" can't be ganrateeded
to be built for all kernels, myself saw several cases, under which
the read_persistent_clock is still needed.
If you want drivers/rtc code to take the priority, first thing you have
to do is to make those codes always "obj-y=xxx.o"
Thanks,
Feng
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 2:38 ` Jason Gunthorpe
2012-12-14 3:13 ` Feng Tang
@ 2012-12-14 21:36 ` John Stultz
2012-12-20 7:02 ` Feng Tang
2 siblings, 0 replies; 18+ messages in thread
From: John Stultz @ 2012-12-14 21:36 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Feng Tang, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
On 12/13/2012 06:38 PM, Jason Gunthorpe wrote:
> On Thu, Dec 13, 2012 at 06:00:23PM -0800, John Stultz wrote:
>
>> So per Jason's related patch, he's made the point that the
>> persistent_clock and RTC class functionality are basically exclusive
>> (well, in his case, he said this with respect to updating the RTC,
>> not reading it - I don't mean to put words in his mouth - Please do
>> correct me here Jason. :). In other words, we probably should avoid
>> configurations where both the rtc hctosys and persistent_clock
>> interfaces are both active.
> I only studied update_persistent_clock, read_persistent_clock is
> very much different.
>
> Looking at it, I don't think that update_persistent_clock is in any
> way related to read_persistent_clock.. update_persistent_clock is
> *only* called by NTP, and its *only* purpose is to update the RTC with
> NTP synchronized time. In many configurations it will never even be
> called.
>
> I think update_persistent_clock is badly named, it should be called
> platform_save_ntp_time_to_rtc(), keep it divorced from
> read_presistent_clock :)
Fair enough. I think you've done a decent job convincing me that for
the update path converting everything to using the RTC class exclusively
is the better approach. That way we avoid the duplication on the write
at least.
The read side, I suspect we can't eliminate the duplication, but we can
likely configure it out for most cases.
>> make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This
>> way we avoid having configs where there are conflicting paths that
>> we chose from.
> On ARM the read_presistent_clock is used to access a true monotonic
> counter that is divorced from the system RTC - look at
> arch/arm/plat-omap/counter_32k.c for instance.
Yea, the 32k counter in that case is an interesting one (and a good
example of wanting both a read_persistent_clock and a rtc). It doesn't
exactly implement what read_persistent_clock() intends, but gets away
with it, since on the suspend/resume we only take a delta from the
read_persistent_clock(), we don't actually care if its accurate time
wise. It works well enough for suspend/resume and is nicely more
accurate then the RTC.
Although this does cause duplication on the initialization side, where
we probably set the time initially to the wrong time using the 32k
counter, and then follow up with the HCTOSYS_DEVICE to get the correct
time (and there's the extra overhead of the RTC suspend/resume path
calculating and calling timekeeping_inject_sleeptime, but since
read_persistent_clock is there, we throw that less accurate data out).
> This seems like a great use of that hardware resource, and no doubt
> those mach's also have a class RTC driver available talking to
> different hardware.
>
> For mach's without that functionality ARM returns a fixed 0 value
> from read_persistent_clock, persumably the kernel detects this and
> falls back to using class rtc functions?
>
> Maybe Feng would be better off adjusting read_persistent_clock to
> return ENODEV in such cases??
Although he wants to avoid even doing any read/calculation in the RTC
suspend/resume path if read_persistent_clock is there. So probably some
sort of a flag interface will be needed in that case.
> So, I think you have to keep your test as a run time test. To support
> the single image ARM boot you can't make the distinction with kconfig.
So yea, I agree there are some cases where both are necessary, but I
also think that in *most* cases we can optimize out the choice at
compile time, which is even better then having even the improved runtime
conditional checking.
thanks
-john
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag
2012-12-14 2:38 ` Jason Gunthorpe
2012-12-14 3:13 ` Feng Tang
2012-12-14 21:36 ` John Stultz
@ 2012-12-20 7:02 ` Feng Tang
2 siblings, 0 replies; 18+ messages in thread
From: Feng Tang @ 2012-12-20 7:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John Stultz, Thomas Gleixner, Alessandro Zummo, linux-kernel, alek.du
Hi Jason,
On Thu, Dec 13, 2012 at 07:38:26PM -0700, Jason Gunthorpe wrote:
>
> > make the HCTOSYS option be dependent on !HAS_PERSISTENT_CLOCK. This
> > way we avoid having configs where there are conflicting paths that
> > we chose from.
>
> On ARM the read_presistent_clock is used to access a true monotonic
> counter that is divorced from the system RTC - look at
> arch/arm/plat-omap/counter_32k.c for instance.
>
> This seems like a great use of that hardware resource, and no doubt
> those mach's also have a class RTC driver available talking to
> different hardware.
>
> For mach's without that functionality ARM returns a fixed 0 value
> from read_persistent_clock, persumably the kernel detects this and
> falls back to using class rtc functions?
I read the counter_32k.c and the read_persistent_clock() magic for
ARM, and got a question: for the omap platforms using the
counter_32k.c's read_persistent_clock, why will they also calles
the time service from RTC device like the rtc_suspend/resume? I
thought usually we just need to use the time source with the better
accuracy.
Thanks,
Feng
>
> Maybe Feng would be better off adjusting read_persistent_clock to
> return ENODEV in such cases??
>
> So, I think you have to keep your test as a run time test. To support
> the single image ARM boot you can't make the distinction with kconfig.
>
> Regards,
> Jason
^ permalink raw reply [flat|nested] 18+ messages in thread