lkml.org 
[lkml]   [2015]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource
    Date
    Mark Rutland <mark.rutland@arm.com> writes:

    >> >> +- 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.

    >> > 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.
    >> >
    >> >> +- 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.

    >> >> +- 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@mansr.com


    \
     
     \ /
      Last update: 2015-10-08 11:21    [W:3.086 / U:0.660 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site