All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: richardcochran@gmail.com, vinicius.gomes@intel.com,
	yangbo.lu@nxp.com, davem@davemloft.net, mlichvar@redhat.com,
	netdev@vger.kernel.org, Willem de Bruijn <willemb@google.com>,
	Martin KaFai Lau <kafai@fb.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>
Subject: Re: [PATCH net-next v3 0/6] ptp: Support hardware clocks with additional free running cycle counter
Date: Wed, 4 May 2022 08:55:52 -0700	[thread overview]
Message-ID: <20220504085552.3ff84d0c@kernel.org> (raw)
In-Reply-To: <20220501111836.10910-1-gerhard@engleder-embedded.com>

On Sun,  1 May 2022 13:18:30 +0200 Gerhard Engleder wrote:
> ptp vclocks require a clock with free running time for the timecounter.
> Currently only a physical clock forced to free running is supported.
> If vclocks are used, then the physical clock cannot be synchronized
> anymore. The synchronized time is not available in hardware in this
> case. As a result, timed transmission with TAPRIO hardware support
> is not possible anymore.
> 
> If hardware would support a free running time additionally to the
> physical clock, then the physical clock does not need to be forced to
> free running. Thus, the physical clocks can still be synchronized while
> vclocks are in use.
> 
> The physical clock could be used to synchronize the time domain of the
> TSN network and trigger TAPRIO. In parallel vclocks can be used to
> synchronize other time domains.
> 
> One year ago I thought for two time domains within a TSN network also
> two physical clocks are required. This would lead to new kernel
> interfaces for asking for the second clock, ... . But actually for a
> time triggered system like TSN there can be only one time domain that
> controls the system itself. All other time domains belong to other
> layers, but not to the time triggered system itself. So other time
> domains can be based on a free running counter if similar mechanisms
> like 2 step synchroisation are used.
> 
> Synchronisation was tested with two time domains between two directly
> connected hosts. Each host run two ptp4l instances, the first used the
> physical clock and the second used the virtual clock. I used my FPGA
> based network controller as network device. ptp4l was used in
> combination with the virtual clock support patches from Miroslav
> Lichvar.

The netdev parts looks sane, I think.

Richard? Let me also add Willem, Jonathan and Martin.

  parent reply	other threads:[~2022-05-04 15:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01 11:18 [PATCH net-next v3 0/6] ptp: Support hardware clocks with additional free running cycle counter Gerhard Engleder
2022-05-01 11:18 ` [PATCH net-next v3 1/6] ptp: Add cycles support for virtual clocks Gerhard Engleder
2022-05-05 13:51   ` Richard Cochran
2022-05-01 11:18 ` [PATCH net-next v3 2/6] ptp: Request cycles for TX timestamp Gerhard Engleder
2022-05-05 10:52   ` Paolo Abeni
2022-05-05 19:59     ` Gerhard Engleder
2022-05-05 13:54   ` Richard Cochran
2022-05-01 11:18 ` [PATCH net-next v3 3/6] ptp: Pass hwtstamp to ptp_convert_timestamp() Gerhard Engleder
2022-05-01 11:18 ` [PATCH net-next v3 4/6] ptp: Support late timestamp determination Gerhard Engleder
2022-05-04 18:24   ` Jonathan Lemon
2022-05-04 19:33     ` Gerhard Engleder
2022-05-05 14:02   ` Richard Cochran
2022-05-01 11:18 ` [PATCH net-next v3 5/6] ptp: Speed up vclock lookup Gerhard Engleder
2022-05-05 14:07   ` Richard Cochran
2022-05-01 11:18 ` [PATCH net-next v3 6/6] tsnep: Add free running cycle counter support Gerhard Engleder
2022-05-04 15:55 ` Jakub Kicinski [this message]
2022-05-05 14:08   ` [PATCH net-next v3 0/6] ptp: Support hardware clocks with additional free running cycle counter Richard Cochran

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=20220504085552.3ff84d0c@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=gerhard@engleder-embedded.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kafai@fb.com \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=vinicius.gomes@intel.com \
    --cc=willemb@google.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.