• Christopher S. Hall's avatar
    time: Add history to cross timestamp interface supporting slower devices · 2c756feb
    Christopher S. Hall authored
    Another representative use case of time sync and the correlated
    clocksource (in addition to PTP noted above) is PTP synchronized
    audio.
    
    In a streaming application, as an example, samples will be sent and/or
    received by multiple devices with a presentation time that is in terms
    of the PTP master clock. Synchronizing the audio output on these
    devices requires correlating the audio clock with the PTP master
    clock. The more precise this correlation is, the better the audio
    quality (i.e. out of sync audio sounds bad).
    
    From an application standpoint, to correlate the PTP master clock with
    the audio device clock, the system clock is used as a intermediate
    timebase. The transforms such an application would perform are:
    
        System Clock <-> Audio clock
        System Clock <-> Network Device Clock [<-> PTP Master Clock]
    
    Modern Intel platforms can perform a more accurate cross timestamp in
    hardware (ART,audio device clock).  The audio driver requires
    ART->system time transforms -- the same as required for the network
    driver. These platforms offload audio processing (including
    cross-timestamps) to a DSP which to ensure uninterrupted audio
    processing, communicates and response to the host only once every
    millsecond. As a result is takes up to a millisecond for the DSP to
    receive a request, the request is processed by the DSP, the audio
    output hardware is polled for completion, the result is copied into
    shared memory, and the host is notified. All of these operation occur
    on a millisecond cadence.  This transaction requires about 2 ms, but
    under heavier workloads it may take up to 4 ms.
    
    Adding a history allows these slow devices the option of providing an
    ART value outside of the current interval. In this case, the callback
    provided is an accessor function for the previously obtained counter
    value. If get_system_device_crosststamp() receives a counter value
    previous to cycle_last, it consults the history provided as an
    argument in history_ref and interpolates the realtime and monotonic
    raw system time using the provided counter value. If there are any
    clock discontinuities, e.g. from calling settimeofday(), the monotonic
    raw time is interpolated in the usual way, but the realtime clock time
    is adjusted by scaling the monotonic raw adjustment.
    
    When an accessor function is used a history argument *must* be
    provided. The history is initialized using ktime_get_snapshot() and
    must be called before the counter values are read.
    
    Cc: Prarit Bhargava <prarit@redhat.com>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: kevin.b.stanton@intel.com
    Cc: kevin.j.clarke@intel.com
    Cc: hpa@zytor.com
    Cc: jeffrey.t.kirsher@intel.com
    Cc: netdev@vger.kernel.org
    Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarChristopher S. Hall <christopher.s.hall@intel.com>
    [jstultz: Fixed up cycles_t/cycle_t type confusion]
    Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
    2c756feb
timekeeper_internal.h 5.12 KB