On Sat, Nov 15, 2014 at 02:38:00AM +0100, Thomas Gleixner wrote: > 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. As I understand it the architected timer will be turned off along with the rest of the CPU complex on Tegra. I'm not sure if that's specific to Tegra or something that other SoCs may do as well. Cc'ing Paul who's more familiar with the details. Thierry
Attachment:
pgpxWMlIEHTVc.pgp
Description: PGP signature
