> On 12 Sep 2016, at 10:09, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Fri, Sep 09, 2016 at 10:39:09PM +0100, Kieran Tyrrell wrote: >> + int (*timerenable)(struct ptp_clock_info *ptp, bool enable); >> + int (*timersettime)(struct ptp_clock_info *ptp, struct timespec64 *ts); > > These need kerneldoc comments describing the usage above. I find the > name 'timerenable' confusing, because we already have 'enable', and > that method immediately activates the requested feature. The new > timerenable is actually performing a kind of resource reservation, like > the 'verify' method. > > I understood what you were trying to do with 'timerenable', but we > should consider integrating the timers with the other interrupt based > functionality. For the user it makes little sense if the capabilities > advertise timers and periodic signals, for example, only to receive > EBUSY later on at run time. > > In the case of the i210, there is an either/or choice regarding the > TSINTR_TT1/0 interrupts. We need to put the user in charge somehow, > like we do for mapping of auxiliary functions to HW pins.
I am about to rework this, to add an ioctl to allow enabling the timer on a specific channel (TT0/TT1 in the case of igb). As it doesn’t make sense to enable both (hardware) timers at the same time (as the posix timers will only use one), should this be a simple: PTP_ENABLE_ALARM with an int parameter to set the channel/alarm number to use? (and -1 to disable)? Should the ptp capabilities (in the igb case) state the number of alarms as 2? (even though only one can be enabled at a time, and in fact you can create hundreds of posix timers off a single hardware alarm? Just want to get it straight with you before I start coding, thanks! Kieran. ------------------------------------------------------------------------------ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
