Messages in this thread | | | Date | Fri, 23 Feb 2007 16:34:28 -0800 (PST) | Subject | Re: sparc generic time / clockevents | From | David Miller <> |
| |
From: john stultz <johnstul@us.ibm.com> Date: Fri, 23 Feb 2007 11:51:18 -0800
> Yea. I actually have some in-progress patches from Peter Keilty that > convert ia64 and sparc64 time_interpolators to clocksources, then > removes the time_interpolator code. > > The ia64 conversion is more complicated due to the fsyscall asm, but I > think the sparc64 conversion (below) is pretty straight forward. I've > only built tested this, so I have no clue if it actually works. > > Any thoughts?
Hey John, I had to do this already in order to do the dynticks port to sparc64, but nice to see another attempt :-)
Two things I did on my side:
+ .mask = 0xffffffffffffffffLL,
I used CLOCKSOURCE_MASK(64) here.
+static cycle_t read_sparc64_cpuclock(void) +{ + return (cycle_t)get_cycles(); +} ... + .read = read_sparc64_cpuclock,
You can just directly assign tick_ops->get_tick to .read at run-time to avoid a stack frame and function call/return.
+ .shift = 16,
These shift selections all seem rather arbitrary.
If it's not an arbitrary selection, it would be nice to have some comments about how to go about choosing an appropriate shift. I imagine the selections has to do with the possible range of the frequencies the clocksource supports, and how much accuracy you get for certain shift selections given that range. - 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/
| |