Messages in this thread | | | Subject | Re: re-adding clocksource_get_next ? | From | john stultz <> | Date | Mon, 12 Apr 2010 11:50:18 -0700 |
| |
On Mon, 2010-04-12 at 08:02 +0200, Giuseppe CAVALLARO wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello John, > > john stultz wrote: > > On Thu, Apr 8, 2010 at 11:53 PM, Giuseppe CAVALLARO > > <peppe.cavallaro@st.com> wrote: > >> Hello! > >> this function was removed in the past but I've not clear all the details. > >> While testing LLTng, I wrote the patch, in attachment, that re-adds it > >> again. > >> The clocksource_get_next returns the first clock source available > >> (without looking at the rating). > >> In my environment, a clock source is a TMU channel (e.g. TMU1) and, > >> indeed, clocksource_get_next works fine. > > > > Could you provide some more details as to why you need raw access to > > the clocksource, instead of using something like ktime_get(), > > getrawmonotonic() or sched_clock()? > > I wanted to directly read the value of the TCNT register of a TMU > channel registered as clocksource in an SH platform. > My idea was to get the first clocksource available and than use the read > hook to get its raw value. > Indeed, on SH4, the clocksource_get_next returns the TMU channel 1 > (usually registered as clocksource); the clk->reads points to > sh_tmu_clocksource_read (drivers/clocksource/sh_tmu.c). This returns the > value of the timer count register (TCNT).
If you specifically want the function sh_tmu_clocksource_read(), why not call it directly instead of indirecting through the clocksource infrastructure?
Additionally, since the clocksource code is dynamic, you might get a different clocksource then you expect (such as jiffies) depending on user config or user actions.
So I'd advise against using the clocksource code here.
thanks -john
| |