* Giuseppe CAVALLARO ([email protected]) wrote: > Hi Mathieu, > Mathieu Desnoyers wrote: > >> static inline u32 trace_clock_read32(void) > >> { > >> - return get_cycles(); > >> + if (likely(clock)) > >> + return (u32) clock->read(clock); > > > > Can you walk us through the code that is executed when clock->read() is > > called ? Is it possible that the clock source read() takes a xtime seq > > read lock in some SH configurations ? > > On SH, the trace_clock_read_synthetic_tsc invokes the > sh_tmu_clocksource_read (clock->read), in drivers/clocksource/sh_tmu.c. > This reads the timer counter register (TCNT). > > What do you think?
This particular implementation seems ok, but I'd like stronger guarantees than that: - That the clocksource selection will still work on future kernel releases and other SH boards. - That sh_tmu_clocksource_read will never *ever* take any lock in any future kernel version. Is that guaranteed by the clocksource API ? Thanks, Mathieu > > Regards > Giuseppe > > > If it is the case, then we will run into deadlocks with tracing code > > called from within the xtime seq write lock. Therefore, fixing this > > without calling the clocksource read() would be adequate. > > > > Thanks, > > > > Mathieu > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
