All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: "Y.b. Lu" <yangbo.lu@nxp.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	netdev <netdev@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH] net: mscc: ocelot: support PPS signal generation
Date: Fri, 27 Dec 2019 07:12:30 -0800	[thread overview]
Message-ID: <20191227151230.GB1435@localhost> (raw)
In-Reply-To: <AM7PR04MB68858E4814EB85A8860FA48FF82A0@AM7PR04MB6885.eurprd04.prod.outlook.com>

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

  reply	other threads:[~2019-12-27 15:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-26  9:58 [PATCH] net: mscc: ocelot: support PPS signal generation Yangbo Lu
2019-12-26 10:49 ` Vladimir Oltean
2019-12-26 10:50   ` Vladimir Oltean
2019-12-26 11:21     ` Y.b. Lu
2019-12-26 11:17   ` Y.b. Lu
2019-12-26 11:44     ` Vladimir Oltean
2019-12-27  2:08     ` Richard Cochran
2019-12-27  3:51       ` Y.b. Lu
2019-12-27 15:12         ` Richard Cochran [this message]
2019-12-26 10:58 ` Andrew Lunn
2019-12-26 11:22   ` Y.b. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191227151230.GB1435@localhost \
    --to=richardcochran@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=yangbo.lu@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.