On Tue, 2014-02-11 at 21:09 +0100, Richard Cochran wrote:
> > -#define EXT_EVENT 1
>
> Regarding this EXT_EVENT thing ...
>
> > @@ -430,12 +419,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info
> > *ptp,
> > switch (rq->type) {
> > case PTP_CLK_REQ_EXTTS:
> > index = rq->extts.index;
> > - if (index < 0 || index >= N_EXT_TS)
> > + if (index < 0 || index >= n_ext_ts)
> > return -EINVAL;
> > - event_num = EXT_EVENT + index;
> > + event_num = index;
>
> there was a mapping between the "event numbers" and the external time
> stamp channels. I don't remember off the top of my head why this these
> two differ by one, but there was a good reason.
I haven't seen anything in the documentation regarding this, output
triggers 0 and 1 are special, but the events should all behave the same.
Could be be a mixup between events and pins? Pin0 means disable the
event.
> Are you sure this is still working with this change?
It has been running with event 0 in one of our products for at least the
last 3 months....
> I am especially wondering about the event decoding here:
>
> > @@ -642,7 +631,7 @@ static void recalibrate(struct dp83640_clock *clock)
> >
> > static inline u16 exts_chan_to_edata(int ch)
> > {
> > - return 1 << ((ch + EXT_EVENT) * 2);
> > + return 1 << ((ch) * 2);
> > }
>
> Maybe I am just paranoid, but can you remind me how these event
> numbers are supposed to work, before and after the change?
The mapping was hardcoded to map events 0-5 to event channels 1-6, the
periodic output trigger at channel 6 and the calibration event+trigger
both at channel 7.
The patch will (at least in v3 that I will post shortly) change both the
event and trigger mapping to a direct mapping and keep the calibration
at channel 7.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
