On Sat, 15 Nov 2014, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Anatol Pomozov wrote:
> > On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > >> So what I suppose to do with my patch? If it does not work could
> > >> anyone provide patch that removes ARM arch dependency from
> > >> tegra20_timer.c?
> > >
> > > Huch? You want other people to solve your problems?
> >
> > This is not the point. I provided patch that fixes the issue. Other
> > people said that they have ideas how to do it different (and better)
> > way. So I am asking to share these ideas represented as a patch.
>
> That's not the way it works.
>
> You sent a patch to solve an problem which you are facing.
>
> Now the people who review the patch think that there is a better
> approach than moving code from arm/ to the timekeeping core code.
>
> So it's up to you to come up with a patch which solves the problem in
> the right way.
And just for the record this whole thing is just hilarious.
ARM64 selects ARM_ARCH_TIMER which registers the architected timer as
the primary clocksource.
Now that timer has the following flag set:
CLOCK_SOURCE_SUSPEND_NONSTOP
And that flag causes the core timekeeping code to use the clocksource
to figure out the time which the machine spent in suspend.
So registering that tegra RTC as persistent clock does not have any
value at all. Simply because it is completely irrelevant at boot time
whether the RTC can be accessed right at timekeeping init or
not. Nothing in early boot needs wall clock time. It's good enough to
set wall clock time late in the boot process as the first use case is
when the root file system gets mounted. And the RTC driver which
obviously deals with the same hardware is initialized before that.
So you are trying to move something which is outright pointless to the
core code just because you carry that patch in your ChromeOS support
hackery.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
