Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

Mark Rutland [off-list ref] writes:

quoted

quoted

quoted

+- clocks: phandle to the source clock

Is the frequency expected to be exactly the source clock frequency? I
imagine it's possible for there to be a divisor.

There could of course be, though there isn't in the hardware I'm dealing
with.  Is specifying it here preferable using a fixed-factor-clock?

I'm not actually sure; I guess it would be ok to do so.

For now we should just explicitly state that the clocksource is assumed
to tick at the rate of the clock.

OK, I'll come up with a clearer wording.

quoted

quoted

We can add properties for that later, but we should be explcit as to
what we currently expect the relationship between the clock and the
clocksource to be.

quoted

+- clocksource-bits: number of valid bits
+- clocksource-rating: rating of the clocksource

NAK. This has no meaning w.r.t. the hardware. This should not be in the
DT. If there are criteria that bias this (e.g. frequency, latency), they
should either be described in the DT or determined dynamically.

I had a bad feeling about this.  How would you suggest determining a
suitable value from actual hardware parameters?

I don't have a good answer to that given the rating is semi-arbitrary,
but that's also the reason I don't want to see it in the DT.

Can we not just choose a fixed number in the driver for now? Likely
something lower than the architected timers (400 currently).

Fine with me.

quoted

quoted

quoted

+- linux,sched-clock: boolean, register clocksource as sched_clock

Likewise, this property doesn't belong in the DT for the same reasons as
clocksource-rating.

What would be a proper way to select a sched_clock source?  I realise
it's a Linux-specific thing and DT is supposed to be generic, but the
information must be provided somehow.

I think that any source above a certain rate and below a certain
latency, which does not lose state, should be registered (and the best
gets chosen dynamically).

Come to think of it, what's the expected behaviour of this source w.r.t.
power management? I expect that the kernel needs to leave the clock
enabled at all times for this to possibly work.

The platform I'm dealing with has a 32-bit register counting cycles of
the external clock input which never stops.  It also has a few counters
with a configurable clock source, and those might indeed stop so should
probably not be used for this.

-- 
Måns Rullgård
mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html