netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
	richardcochran@gmail.com, yangbo.lu@nxp.com,
	xiaoliang.yang_1@nxp.com, po.liu@nxp.com,
	UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for periodic output
Date: Fri, 17 Jul 2020 01:09:23 +0300	[thread overview]
Message-ID: <20200716220923.k6vwsjdk2os4rlrp@skbuf> (raw)
In-Reply-To: <20200716214927.s4uu36twwegarznm@skbuf>

On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
> > 
> > 
> > On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
> > > There are external event timestampers (PHCs with support for
> > > PTP_EXTTS_REQUEST) that timestamp both event edges.
> > > 
> > > When those edges are very close (such as in the case of a short pulse),
> > > there is a chance that the collected timestamp might be of the rising,
> > > or of the falling edge, we never know.
> > > 
> > > There are also PHCs capable of generating periodic output with a
> > > configurable duty cycle. This is good news, because we can space the
> > > rising and falling edge out enough in time, that the risks to overrun
> > > the 1-entry timestamp FIFO of the extts PHC are lower (example: the
> > > perout PHC can be configured for a period of 1 second, and an "on" time
> > > of 0.5 seconds, resulting in a duty cycle of 50%).
> > > 
> > > A flag is introduced for signaling that an on time is present in the
> > > perout request structure, for preserving compatibility. Logically
> > > speaking, the duty cycle cannot exceed 100% and the PTP core checks for
> > > this.
> > 
> > I was thinking whether it made sense to support over 50% since in theory
> > you could change start time and the duty cycle to specify the shifted
> > wave over? but I guess it doesn't really make much of a difference to
> > support all the way up to 100%.
> > 
> 
> Only if you also support polarity, and we don't support polarity. It's
> always high first, then low.
> 

Sorry for the imprecise statement.
If you look at things from the perspective of the signal itself, the
statement is correct.
If you look at them from the perspective of the imaginary grid drawn by
the integer multiples of the period, in the PHC's time (a digital
counter), the correct statement would be that "it's always rising edge
first, then falling edge".  And then the phase is just the delta between
these 2 points of reference.

Let me annotate this:

     t_on
     <------>
     t_period
     <--------->
phase
   <->
>    +------+  +------+  +------+  +------+  +------+  +------+  +------+
>    |      |  |      |  |      |  |      |  |      |  |      |  |      |
>  --+      +--+      +--+      +--+      +--+      +--+      +--+      +
> 
>  +---------+---------+---------+---------+---------+---------+--------->
   t=1000    t=1010    t=1020    t=1030    t=1040    t=1050    t=1060
>  period=10                                                          time
>  phase=2
>  on = 7
> 
> There's no other way to obtain this signal which has a duty cycle > 50%
> by specifying a duty cycle < 50%.
> 

Thanks,
-Vladimir

  reply	other threads:[~2020-07-16 22:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 21:20 [PATCH net-next 0/3] Fully describe the waveform for PTP periodic output Vladimir Oltean
2020-07-16 21:20 ` [PATCH net-next 1/3] ptp: add ability to configure duty cycle for " Vladimir Oltean
2020-07-16 21:36   ` Jacob Keller
2020-07-16 21:49     ` Vladimir Oltean
2020-07-16 22:09       ` Vladimir Oltean [this message]
2020-07-16 23:56         ` Jacob Keller
2020-07-16 21:20 ` [PATCH net-next 2/3] ptp: introduce a phase offset in the periodic output request Vladimir Oltean
2020-07-16 21:40   ` Jacob Keller
2020-07-16 21:20 ` [PATCH net-next 3/3] net: mscc: ocelot: add support for PTP waveform configuration Vladimir Oltean
2020-07-16 21:36   ` Vladimir Oltean
2020-07-16 22:29     ` Jakub Kicinski
2020-07-16 21:31 ` [PATCH net-next 0/3] Fully describe the waveform for PTP periodic output Jacob Keller
2020-07-16 22:28 ` Jakub Kicinski

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=20200716220923.k6vwsjdk2os4rlrp@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=davem@davemloft.net \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=po.liu@nxp.com \
    --cc=richardcochran@gmail.com \
    --cc=xiaoliang.yang_1@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 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).