Re: [PATCH net-next v5 1/2] qed: Add infrastructure for PTP support

2017-02-13 Thread Richard Cochran
On Mon, Feb 13, 2017 at 03:46:25PM +0200, Yuval Mintz wrote:
> +static int qed_ptp_hw_adjfreq(struct qed_dev *cdev, s32 ppb)
> +{
> + struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> + struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> + int drift_dir, best_val, best_period;
> + s64 period, dif, dif2;
> + u32 drift_ctr_cfg = 0;
> + s64 best_dif, val;
> + u32 drift_state;
> +
> + best_dif = ppb;
> + best_period = 2;
> + best_val = 0;
> + drift_dir = 1;
> +
> + if (ppb < 0) {
> + ppb = -ppb;
> + drift_dir = 0;
> + }
> +
> + if (ppb == 0) {
> + /* No clock adjustment required */
> + best_val = 0;
> + best_period = 0xFFF;
> + } else {
> + /* Adjustment value is up to +/-7ns, find an optimal value in
> +  * this range.
> +  */
> + for (val = 7; val > 0; val++) {

This is an endless loop. - ^

Besides that, this code returns some very strange values.  For
example, for ppb = 100106, 100107, and 100108.  Also ppb = 1...8
all return 0/40.

Trouble with the -= 8?

I can only recommend plotting all of the raw errors and also average
(RMS) error over the nominal interval ppb = 1...50.


Thanks,
Richard

> + period = div_s64(val * 10, ppb);
> + period -= 8;
> + period >>= 4;
> + if (period < 1)
> + period = 1;
> + if (period > 0xFFE)
> + period = 0xFFE;
> +
> + /* Check both rounding ends for approximate error */
> + dif = ppb * (period * 16 + 8) - val * 10;
> + dif2 = dif + 16 * ppb;
> +
> + if (dif < 0)
> + dif = -dif;
> + if (dif2 < 0)
> + dif2 = -dif2;
> + if (dif2 < dif) {
> + period++;
> + dif = dif2;
> + }
> +
> + /* Track best approximation found so far */
> + if (dif < best_dif) {
> + best_dif = dif;
> + best_val = (int)val;
> + best_period = (int)period;
> + }
> + }
> + }
> +
> + drift_ctr_cfg = (best_period << QED_DRIFT_CNTR_TIME_QUANTA_SHIFT) |
> + (best_val << QED_DRIFT_CNTR_ADJUSTMENT_SHIFT) |
> + (drift_dir << QED_DRIFT_CNTR_DIRECTION_SHIFT);
> +
> + qed_wr(p_hwfn, p_ptt, NIG_REG_TSGEN_RST_DRIFT_CNTR, 0x1);
> +
> + drift_state = qed_rd(p_hwfn, p_ptt, NIG_REG_TSGEN_RST_DRIFT_CNTR);
> + if (drift_state & 1) {
> + qed_wr(p_hwfn, p_ptt, NIG_REG_TSGEN_DRIFT_CNTR_CONF,
> +drift_ctr_cfg);
> + } else {
> + DP_INFO(p_hwfn, "Drift counter is not reset\n");
> + return -EINVAL;
> + }
> +
> + qed_wr(p_hwfn, p_ptt, NIG_REG_TSGEN_RST_DRIFT_CNTR, 0x0);
> +
> + return 0;
> +}


RE: [PATCH net-next v5 1/2] qed: Add infrastructure for PTP support

2017-02-13 Thread Mintz, Yuval
> > +static int qed_ptp_hw_adjfreq(struct qed_dev *cdev, s32 ppb) {
> > +   struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
> > +   struct qed_ptt *p_ptt = p_hwfn->p_ptp_ptt;
> > +   int drift_dir, best_val, best_period;
> > +   s64 period, dif, dif2;
> > +   u32 drift_ctr_cfg = 0;
> > +   s64 best_dif, val;
> > +   u32 drift_state;
> > +
> > +   best_dif = ppb;

Crap. Apparently I've sent my early draft.

'best_dif' is the culprit for the odd results [not the -8].
In the previous calculation it was the theoretical upper-bound,
now it should be an unreachable number instead [70].

> > +   best_period = 2;
> > +   best_val = 0;
> > +   drift_dir = 1;
> > +
> > +   if (ppb < 0) {
> > +   ppb = -ppb;
> > +   drift_dir = 0;
> > +   }
> > +
> > +   if (ppb == 0) {
> > +   /* No clock adjustment required */
> > +   best_val = 0;
> > +   best_period = 0xFFF;
> > +   } else {
> > +   /* Adjustment value is up to +/-7ns, find an optimal value in
> > +* this range.
> > +*/
> > +   for (val = 7; val > 0; val++) {
> 
> This is an endless loop. - ^

And this, obviously...

> 
> Besides that, this code returns some very strange values.  For example, for
> ppb = 100106, 100107, and 100108.  Also ppb = 1...8 all return 0/40.
> 
> Trouble with the -= 8?
> 
> I can only recommend plotting all of the raw errors and also average
> (RMS) error over the nominal interval ppb = 1...50.
> 

I'll send the corrected v6 tomorrow. Sorry about this one.