Re: [RFC v5 3/6] Add history to cross timestamp interface supporting slower devices

[Christopher Hall]

On Fri, 08 Jan 2016 06:04:28 -0800, Thomas Gleixner <tglx@xxxxxxxxxxxxx>  
wrote:
> On Thu, 7 Jan 2016, Christopher Hall wrote:
> > On Wed, 06 Jan 2016 11:37:23 -0800, John Stultz <john.stultz@xxxxxxxxxx>
> > wrote:
> > > I've not done a super close reading here. But is it very likely the
> > > the history_ref->cs_seq is the same as the captured seq? I thought
> > > this history_ref was to allow old cross stamps to be used to improve
> > > the back-calculation of the time at the given cycle value. So throwing
> > > them out if they are older then the last tick seems strange.
> >
> > Maybe this needs more explanation. The clocksource sequence (cs_seq) is
> > incremented for each change in clocksource. I use this to detect a rare  
> > corner
> > case where the clocksource is changed from (on x86 anyway) TSC and then  
> > back.
> > If the history crosses one of these changes then interpolation  
> > shouldn't be
> > attempted (return error). It's not really enough when using the history  
> > to
> > just check that the current clocksource is equal to the one used at the  
> > start
> > of the history. The clocksource must not have changed at all. To answer  
> > your
> > question, it's not at all likely that this would occur.
>
> You can flush the history when a clocksource change happens. No need to  
> add
> extra data to the core structures.

Hi Thomas,

For slower devices like Intel's audio DSP, it's the responsibility of the  
driver to manage the history which is supplied as an argument to  
get_device_system_crosststamp(). The history is a triple (counter value,  
mono-raw time, real time). The clocksource change sequence number allows  
the timekeeping code to determine whether the supplied history is stale  
(returning an error if it is). I'm calling any history stale that crosses  
a clocksource change boundary.

Logically, the keeping of the history is split between the driver and  
timekeeping code with most of the burden on the driver. This introduces a  
small amount of redundancy in the form of the clocksource change sequence,  
but on balance results in a lot simpler timekeeping code.

Chris