On Wed, Jun 05, 2019 at 11:44:21AM +0000, Shalom Toledo wrote:
> On 04/06/2019 17:28, Richard Cochran wrote:
> > Now I see why you did this. Nice try.
>
> I didn't try anything.
>
> The reason is that the hardware units is in ppb and not in scaled_ppm(or ppm),
> so I just converted to ppb in order to set the hardware.
Oh, I thought you were adapting code for the deprecated .adjfreq method.
> But I got your point, I will change my calculation to use scaled_ppm (to get a
> more finer resolution) and not ppb, and convert to ppb just before setting the
> hardware. Is that make sense?
So the HW actually accepts ppb adjustment values? Fine.
But I don't understand this:
> >> + if (ppb < 0) {
> >> + neg_adj = 1;
> >> + ppb = -ppb;
> >> + }
> >> +
> >> + adj = clock->nominal_c_mult;
> >> + adj *= ppb;
> >> + diff = div_u64(adj, NSEC_PER_SEC);
> >> +
> >> + spin_lock(&clock->lock);
> >> + timecounter_read(&clock->tc);
> >> + clock->cycles.mult = neg_adj ? clock->nominal_c_mult - diff :
> >> + clock->nominal_c_mult + diff;
> >> + spin_unlock(&clock->lock);
You have a SW time counter here
> >> + return mlxsw_sp1_ptp_update_phc_adjfreq(clock, neg_adj ? -ppb : ppb);
and a hardware method here?
Why not choose one or the other?
Thanks,
Richard
