On Wed, Mar 11, 2015 at 11:20:59AM +, Stathis Voukelatos wrote:
> Our feeling is that we will have to test and verify that a move to gPTP
> will fit with the use cases that we have to support and that will
> require a fair amount of effort and rewrite of application software.
> If the driver is
Hi Richard,
On 06/03/15 15:22, Richard Cochran wrote:
I don't really know what the problem here is. Yes, there is some
networking configuration that you need to do when administering a
network using PTP protocols. But these protocols (1588 aka PTP, and
802.1AS aka gPTP) do offer means for deal
BTW I am getting doubles of your messages, both addressed to the
mailings lists, but only one also addressed to me. You should just
send one copy, with everyone on CC.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On Fri, Mar 06, 2015 at 10:50:08AM +, Stathis Voukelatos wrote:
> Although the PTP way appears to be the best from an architectural point
> of view, we have some questions as whether it is suitable for the audio
> use cases that this module is mainly intended for.
> To use the PTP terminology i
Hi Richard,
On 27/02/15 18:14, Richard Cochran wrote:
>> The H/W does have the capability to do that. However, in order to
>> implement it there will be some architectural changes needed
>> in the kernel. This module cannot really pretend to be a PHY.
>> In the real world it sits between the MAC
On Fri, Feb 27, 2015 at 05:09:24PM +, Stathis Voukelatos wrote:
> To summarize (and confirm my understanding) your suggestion is for the
> sniffer to be configured to match PTP packets and (similarly to the
> dp83640) return the Message Type and Sequence Id fields that will allow
> them to be m
Hi Richard,
On 25/02/15 17:30, Richard Cochran wrote:
I need some more time to study your other suggestions regarding the
PHY timestamping framework.
From my (limited) understanding of your HW device, I should think that
it will work. The PHY time stamping subsystem is not the most obvious
c
On Wed, Feb 25, 2015 at 05:12:08PM +, Stathis Voukelatos wrote:
> Regarding this last point, the actual counter that generates the
> timestamps is not part of the sniffer H/W module. Timestamps are
> provided to the sniffer externally in H/W by a different module.
> Apart of that there is not e
Hi Richard,
On 25/02/15 17:01, Richard Cochran wrote:
On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote:
Let me suggest another approach that stays in line with the existing
frame work. Based on the device's limitations and your own example,
it seems clear that the intended use c
On Wed, Feb 25, 2015 at 04:19:45PM +0100, Richard Cochran wrote:
> Let me suggest another approach that stays in line with the existing
> frame work. Based on the device's limitations and your own example,
> it seems clear that the intended use case is synchronization for AVB
> applications using
On Tue, Feb 24, 2015 at 04:48:08PM +, Stathis Voukelatos wrote:
> This patch adds support for the Ethernet Packet Sniffer H/W module
> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
> The module allows Ethernet packets to be parsed, matched against
> a user-defined pattern a
This patch adds support for the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is completel
12 matches
Mail list logo
