On Fri, 23 Aug 2019 at 08:22, Richard Cochran wrote:
>
> On Thu, Aug 22, 2019 at 07:13:12PM +0300, Vladimir Oltean wrote:
> > You do think that I understand the problem? But I don't!
>
> ;^)
>
> > > And who generates Local_sync_resp?
> > >
> >
> > Local_sync_resp is the same as Local_sync_req exce
On Thu, Aug 22, 2019 at 07:13:12PM +0300, Vladimir Oltean wrote:
> You do think that I understand the problem? But I don't!
;^)
> > And who generates Local_sync_resp?
> >
>
> Local_sync_resp is the same as Local_sync_req except maybe with a
> custom tag added by the switch. Irrelevant as long as
On Thu, 22 Aug 2019 at 19:05, Richard Cochran wrote:
>
> On Thu, Aug 22, 2019 at 05:58:49PM +0300, Vladimir Oltean wrote:
> > I don't think I understand the problem here.
>
> On the contrary, I do.
>
You do think that I understand the problem? But I don't!
> > You'd have something like this:
> >
On Thu, Aug 22, 2019 at 05:58:49PM +0300, Vladimir Oltean wrote:
> If you mean the latter, then yes, having HWTSTAMP_FILTER_ALL in the
> rx_filter of the DSA master is a hard requirement.
And to clear, the marvell only recognizes PTP frames. That means that
DSA frames cannot be time stamped.
Tha
On Thu, Aug 22, 2019 at 05:58:49PM +0300, Vladimir Oltean wrote:
> I don't think I understand the problem here.
On the contrary, I do.
> You'd have something like this:
>
> Master (DSA master port) Slave (switch CPU port)
>
> || Tstamps known
>
On Thu, 22 Aug 2019 at 17:16, Richard Cochran wrote:
>
> On Wed, Aug 21, 2019 at 11:17:23PM +0300, Vladimir Oltean wrote:
> > Of course PPS with a dedicated hardware receiver that can take input
> > compare timestamps is always preferable. However non-Ethernet
> > synchronization in the field look
> Thinking back...
>
> One problem is this. PTP requires a delay measurement. You can send
> a delay request from the host, but there will never be a reply.
>
> Another problem is this. A Sync message arriving on an external port
> is time stamped there, but then it is encapsulated as a tagged
On Wed, Aug 21, 2019 at 11:17:23PM +0300, Vladimir Oltean wrote:
> Of course PPS with a dedicated hardware receiver that can take input
> compare timestamps is always preferable. However non-Ethernet
> synchronization in the field looks to me like "make do with whatever
> you can". I'm not sure a p
Hi Richard,
On Wed, 21 Aug 2019 at 17:08, Richard Cochran wrote:
>
> On Tue, Aug 20, 2019 at 09:38:45PM -0700, Richard Cochran wrote:
> > 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
On Tue, Aug 20, 2019 at 09:38:45PM -0700, Richard Cochran wrote:
> 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
On Tue, Aug 20, 2019 at 06:57:10PM +0300, Vladimir Oltean wrote:
> I believe something similar should be possible on other hardware as well.
Not for the marvell link street devices, AFAICT.
Thanks,
Richard
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
> - Ethernet has support for hardware timestamping
True, but not all drivers support it.
Marvell switches are often combined with Marvell MACs. None of the
Marvell MAC drivers, mv643xx, mvneta, mvpp2 or octeontx2 support
hardware timestamping. My guess is, the hardware probably supports it,
but n
On Sun, 18 Aug 2019 at 21:26, Vladimir Oltean wrote:
>
> This patchset proposes an interface from the SPI subsystem for
> software timestamping SPI transfers. There is a default implementation
> provided in the core, as well as a mechanism for SPI slave drivers to
> check which byte was in fact ti
This patchset proposes an interface from the SPI subsystem for
software timestamping SPI transfers. There is a default implementation
provided in the core, as well as a mechanism for SPI slave drivers to
check which byte was in fact timestamped post-facto. The patchset also
adds the first user of t
15 matches
Mail list logo
