All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Vladimir Oltean <olteanv@gmail.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: Thu, 16 Jul 2020 16:56:35 -0700	[thread overview]
Message-ID: <3f8f4f4b-b5f3-11b6-2dfe-3bce5e1b79f3@intel.com> (raw)
In-Reply-To: <20200716220923.k6vwsjdk2os4rlrp@skbuf>



On 7/16/2020 3:09 PM, Vladimir Oltean wrote:
> 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
> 

Right this makes sense now, thanks for the detailed explanation!

Regards,
Jake

  reply	other threads:[~2020-07-16 23:56 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
2020-07-16 23:56         ` Jacob Keller [this message]
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=3f8f4f4b-b5f3-11b6-2dfe-3bce5e1b79f3@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --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 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.