netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: "Christopher S. Hall" <christopher.s.hall@intel.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com,
	x86@kernel.org, jacob.e.keller@intel.com, davem@davemloft.net,
	sean.v.kelley@intel.com
Subject: Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features
Date: Tue, 25 Feb 2020 18:47:07 -0800	[thread overview]
Message-ID: <20200226024707.GA10271@localhost> (raw)
In-Reply-To: <20200225233707.GA32079@skl-build>

On Tue, Feb 25, 2020 at 03:37:07PM -0800, Christopher S. Hall wrote:
> On Sun, Feb 02, 2020 at 08:08:38PM -0800, Richard Cochran wrote:
> > The TGPIO input clock, the ART, is a free running counter, but you
> > want to support frequency adjustments.  Use a timecounter cyclecounter
> > pair.
> 
> I'm concerned about the complexity that the timecounter adds to
> the driver. Specifically, the complexity of dealing with any rate mismatches
> between the timecounter and the periodic output signal. The phase
> error between the output and timecounter needs to be zero.

If I understood correctly, the device's outputs are generated from a
non-adjustable counter.  So, no matter what, you will have the problem
of changing the pulse period in concert with the user changing the
desired frequency.

> My counter-proposal would be to use the real-time clock as the basis of the
> device clock. This is fairly simple because the relation between ART and the
> realtime clock is known. When output is enabled any phase error between
> the realtime clock and the periodic output signal is accumulated in the
> SYS_OFFSET result.

I don't understand how you intend to do this...
 
> This leaves the PHC API behavior as it is currently and uses the frequency
> adjust API to adjust the output rate.
> 
> > Let the user dial a periodic output signal in the normal way.
> > 
> > Let the user change the frequency in the normal way, and during this
> > call, adjust the counter values accordingly.
> 
> Yes to both of the above.

So, why then do you need this?

+#define PTP_EVENT_COUNT_TSTAMP2 \
+       _IOWR(PTP_CLK_MAGIC, 19, struct ptp_event_count_tstamp)

If you can make the device work with the existing user space API,

	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
	while (1) {
		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
	}

that would be ideal.  But I will push back on anything like the
following.

	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
	while (1) {
		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
		ioctl(fd, PTP_EVENT_COUNT_TSTAMP, ...);
	}

But maybe I misunderstood?

Thanks,
Richard

  reply	other threads:[~2020-02-26  2:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 21:48 [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features christopher.s.hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 1/5] drivers/ptp: Add Enhanced handling of reserve fields christopher.s.hall
2020-01-31 16:54   ` Jacob Keller
2020-02-03  1:45     ` Richard Cochran
2020-02-24 23:29       ` Christopher S. Hall
2020-01-31 17:02   ` Jacob Keller
2020-02-03  1:27   ` Richard Cochran
2020-02-24 23:23     ` Christopher S. Hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 2/5] drivers/ptp: Add PEROUT2 ioctl frequency adjustment interface christopher.s.hall
2020-02-03  2:14   ` Richard Cochran
2020-02-26  0:20     ` Christopher S. Hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 3/5] drivers/ptp: Add user-space input polling interface christopher.s.hall
2020-02-03  2:28   ` Richard Cochran
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 4/5] x86/tsc: Add TSC support functions to support ART driven Time-Aware GPIO christopher.s.hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 5/5] drivers/ptp: Add PMC Time-Aware GPIO Driver christopher.s.hall
2020-02-03  2:31   ` Richard Cochran
2020-02-07 17:10   ` Linus Walleij
2020-02-07 17:28     ` Andrew Lunn
2020-02-07 19:49       ` Andy Shevchenko
2020-02-07 19:52         ` Andy Shevchenko
2020-02-24 23:17     ` Christopher S. Hall
2020-01-31 15:08 ` [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features Jakub Kicinski
2020-01-31 18:14 ` Thomas Gleixner
2020-02-24 22:40   ` Christopher S. Hall
2020-02-26 23:06     ` Thomas Gleixner
2020-03-03  1:56       ` Christopher S. Hall
2020-03-03 13:00       ` Linus Walleij
2020-03-03 15:23         ` Richard Cochran
2020-03-03 15:24         ` Thomas Gleixner
2020-03-08 19:14           ` Jonathan Cameron
2020-02-03  4:08 ` Richard Cochran
2020-02-03 18:27   ` Jacob Keller
2020-02-25 23:37   ` Christopher S. Hall
2020-02-26  2:47     ` Richard Cochran [this message]
2020-03-03  2:01       ` Christopher S. Hall
2020-02-07 17:17 ` Linus Walleij

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=20200226024707.GA10271@localhost \
    --to=richardcochran@gmail.com \
    --cc=christopher.s.hall@intel.com \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=jacob.e.keller@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sean.v.kelley@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).