Subject: Re: [PATCH] net: mscc: ocelot: support PPS signal generation

From: Richard Cochran <[email-masked]>
Date: Fri, 27 Dec 2019 07:12:30 -0800

On Fri, Dec 27, 2019 at 03:51:08AM +0000, Y.b. Lu wrote:
> I'm a little confused.
> It seems PTP_CLK_REQ_PEROUT method needs req.perout.start and req.perout.period to generate periodical *clock* signal, while PPS is *pulse* signal every second.
> For the two cases (1Hz clock signal and 1 pulse very second), how to configure with PTP_CLK_REQ_PEROUT method?

If your HW can generate other periods, then implement them!

If your HW can only do exactly one pps, then you can check that the
nanoseconds fields are zero, returning -ERANGE when they are non-zero.

> For some hardware, each pin has fixed function. And some hardware, each pin could be programable for function.
> The Ocelot PTP pin is programable, but initially the software author may plan to set fixed function for each pin.
> Do you suggest we make all pins function programable?

Yes.  You should implement the ptp_clock_info.verify method:

 * @verify:   Confirm that a pin can perform a given function. The PTP
 *            Hardware Clock subsystem maintains the 'pin_config'
 *            array on behalf of the drivers, but the PHC subsystem
 *            assumes that every pin can perform every function. This
 *            hook gives drivers a way of telling the core about
 *            limitations on specific pins. This function must return
 *            zero if the function can be assigned to this pin, and
 *            nonzero otherwise.

If the pin cannot be changed on a particular SoC, then the .verify
should simply make sure user space chose the correct setting.

> BTW, current ptp clock code is embedded in ocelot.c.
> More and more functions will be added in the future, and the interrupt implementation in SoC is different between Ocelot and VSC9959.
> Do you think it's proper to separate common code as a single PTP driver?

If you get a lot of code re-use, then sure.

Thanks,
Richard