netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	Hubert Feurstein <h.feurstein@gmail.com>,
	mlichvar@redhat.com, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-spi@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver
Date: Tue, 20 Aug 2019 21:38:45 -0700	[thread overview]
Message-ID: <20190821043845.GB1332@localhost> (raw)
In-Reply-To: <CA+h21hr4UcoJK7upNJjG0ibtX7CkF=akxVdrb--1AJn6-z=sUQ@mail.gmail.com>

On Tue, Aug 20, 2019 at 06:57:10PM +0300, Vladimir Oltean wrote:
> What if all we need is just a mini-"phc2sys-over-Ethernet" that runs
> on a kernel thread internally to DSA? We say that DSA switches are
> "slave" to the "master" netdevice - their PTP clock can be the same.
> I am fairly confident that the sja1105 at least can be configured in
> hardware to work in this mode. One just needs to enable the CPU port
> in its own reachability matrix. None of the switch ports is really a
> "CPU port" hardware speaking.

I did consider this method when working on an early version of the
marvell driver.  At least for that chip, there was no way to get the
time stamps on the port attached to the CPU port.

The DSA system (as I understand it) does not allow using the Linux
interface acting as the CPU port in a way that would allow taking time
stamps with the existing code base.  You might find a way, but I guess
it won't be easy.

Overall, the PTP switch use case is well supported by Linux.  The
synchronization of the management CPU to the PTP, while nice to have,
is not required to implement a Transparent Clock.  Your specific
application might require it, but honestly, if the management CPU
needs good synchronization, then you really aught to feed a PPS from
the switch into a gpio (for example) on the CPU.

Using SPI or MDIO or I2C or UART as a synchronization bus is not a
wise solution.

Having said that, I don't oppose improving the situation for these
slow, non-deterministic serial buses, but you will have to sell your
solution to the maintainers of said buses.

Thanks,
Richard

  parent reply	other threads:[~2019-08-21  4:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-18 18:25 [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-18 18:25 ` [PATCH spi for-5.4 1/5] spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messages Vladimir Oltean
2019-08-20 18:21   ` Mark Brown
2019-08-20 19:36     ` Vladimir Oltean
2019-08-21 11:01       ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 2/5] spi: Add a PTP system timestamp to the transfer structure Vladimir Oltean
2019-08-22 17:11   ` Mark Brown
2019-08-24 12:38     ` Vladimir Oltean
2019-08-27 19:01       ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 3/5] spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing Vladimir Oltean
2019-08-22 17:38   ` Mark Brown
2019-08-18 18:25 ` [PATCH spi for-5.4 4/5] spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode Vladimir Oltean
2019-08-18 18:26 ` [PATCH spi for-5.4 5/5] spi: spi-fsl-dspi: Disable interrupts and preemption during poll mode transfer Vladimir Oltean
2019-08-20 15:57 ` [PATCH spi for-5.4 0/5] Deterministic SPI latency with NXP DSPI driver Vladimir Oltean
2019-08-20 16:57   ` Andrew Lunn
2019-08-21  4:38   ` Richard Cochran [this message]
2019-08-21 14:08     ` Richard Cochran
2019-08-21 20:17       ` Vladimir Oltean
2019-08-22 14:16         ` Richard Cochran
2019-08-22 14:56           ` Andrew Lunn
2019-08-22 14:58           ` Vladimir Oltean
2019-08-22 16:05             ` Richard Cochran
2019-08-22 16:13               ` Vladimir Oltean
2019-08-23  5:22                 ` Richard Cochran
2019-08-24 12:13                   ` Vladimir Oltean
2019-08-22 16:10             ` Richard Cochran
2019-08-21  4:42   ` 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=20190821043845.GB1332@localhost \
    --to=richardcochran@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=h.feurstein@gmail.com \
    --cc=linux-spi@vger.kernel.org \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.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).