On Wed, 25 Nov 2020 02:28:27 +0000 Po Liu wrote:
> > The tc-taprio base time indicates the beginning of the tc-taprio schedule,
> > which is cyclic by definition (where the length of the cycle in nanoseconds
> > is called the cycle time). The base time is a 64-bit PTP time in the TAI
> > domain.
> >
> > Logically, the base-time should be a future time. But that imposes some
> > restrictions to user space, which has to retrieve the current PTP time from
> > the NIC first, then calculate a base time that will still be larger than the
> > base time by the time the kernel driver programs this value into the
> > hardware. Actually ensuring that the programmed base time is in the
> > future is still a problem even if the kernel alone deals with this.
> >
> > Luckily, the enetc hardware already advances a base-time that is in the
> > past into a congruent time in the immediate future, according to the same
> > formula that can be found in the software implementation of taprio (in
> > taprio_get_start_time):
> >
> > /* Schedule the start time for the beginning of the next
> > * cycle.
> > */
> > n = div64_s64(ktime_sub_ns(now, base), cycle);
> > *start = ktime_add_ns(base, (n + 1) * cycle);
> >
> > There's only one problem: the driver doesn't let the hardware do that.
> > It interferes with the base-time passed from user space, by special-casing
> > the situation when the base-time is zero, and replaces that with the
> > current PTP time. This changes the intended effective base-time of the
> > schedule, which will in the end have a different phase offset than if the
> > base-time of 0.000000000 was to be advanced by an integer multiple of
> > the cycle-time.
> >
> > Fixes: 34c6adf1977b ("enetc: Configure the Time-Aware Scheduler via tc-
> > taprio offload")
> > Signed-off-by: Vladimir Oltean <vladimir.olt...@nxp.com>
>
> It makes sense to me for this patch. Thanks!
Applied, thanks!
