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