On Tue, Nov 07, 2017 at 07:23:27PM -0800, Richard Cochran wrote:
> The application does join that group on the external (slave)
> interface. I'll find out why the delay request mechanism isn't
> working...
Looking back, I now recall that the series lets the HW embed the time
stamps into the
On Tue, Nov 07, 2017 at 07:23:27PM -0800, Richard Cochran wrote:
> The application does join that group on the external (slave)
> interface. I'll find out why the delay request mechanism isn't
> working...
Looking back, I now recall that the series lets the HW embed the time
stamps into the
On Wed, Nov 08, 2017 at 04:02:26AM +0100, Andrew Lunn wrote:
> So i did a quick test. If the application joins 224.0.1.129 on the
> slave interface, the switch will pass the packets to the host and to
> the application.
The application does join that group on the external (slave)
interface. I'll
On Wed, Nov 08, 2017 at 04:02:26AM +0100, Andrew Lunn wrote:
> So i did a quick test. If the application joins 224.0.1.129 on the
> slave interface, the switch will pass the packets to the host and to
> the application.
The application does join that group on the external (slave)
interface. I'll
> One thing that we're not doing (and probably should be) is
> configuring multicast frames to 01:1B:19:00:00:00 to be destined to
> the CPU port.
So i did a quick test. If the application joins 224.0.1.129 on the
slave interface, the switch will pass the packets to the host and to
the
> One thing that we're not doing (and probably should be) is
> configuring multicast frames to 01:1B:19:00:00:00 to be destined to
> the CPU port.
So i did a quick test. If the application joins 224.0.1.129 on the
slave interface, the switch will pass the packets to the host and to
the
On Tue, Nov 07, 2017 at 08:56:05PM +, Brandon Streiff wrote:
> > Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
> > to work as expected.
> >
> > Have you tested UDPv4? It doesn't work.
>
> I have not. Our usage has been focused on 802.1AS; the ptp4l settings we
> use
On Tue, Nov 07, 2017 at 08:56:05PM +, Brandon Streiff wrote:
> > Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
> > to work as expected.
> >
> > Have you tested UDPv4? It doesn't work.
>
> I have not. Our usage has been focused on 802.1AS; the ptp4l settings we
> use
> Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
> to work as expected.
>
> Have you tested UDPv4? It doesn't work.
I have not. Our usage has been focused on 802.1AS; the ptp4l settings we
use are the following:
transportSpecific0x1
ptp_dst_mac
> Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
> to work as expected.
>
> Have you tested UDPv4? It doesn't work.
I have not. Our usage has been focused on 802.1AS; the ptp4l settings we
use are the following:
transportSpecific0x1
ptp_dst_mac
On Mon, Nov 06, 2017 at 04:04:22PM +0100, Andrew Lunn wrote:
> I assume you have tested basic networking? You can ping the other
> machines in the network?
Yes, I ssh into the device via the external switch port interface.
Thanks,
Richard
On Mon, Nov 06, 2017 at 04:04:22PM +0100, Andrew Lunn wrote:
> I assume you have tested basic networking? You can ping the other
> machines in the network?
Yes, I ssh into the device via the external switch port interface.
Thanks,
Richard
On Mon, Nov 06, 2017 at 06:55:46AM -0800, Richard Cochran wrote:
> When I run with Layer2 transport and the switch as master, it seems to
> work. Any other combination of role + transport fails.
Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
to work as expected.
Have you
On Mon, Nov 06, 2017 at 06:55:46AM -0800, Richard Cochran wrote:
> When I run with Layer2 transport and the switch as master, it seems to
> work. Any other combination of role + transport fails.
Oops, I had "slaveOnly" set in my PC's configuration. So layer2 seems
to work as expected.
Have you
On Mon, Nov 06, 2017 at 06:55:46AM -0800, Richard Cochran wrote:
> On Sun, Oct 08, 2017 at 11:38:21AM -0400, Richard Cochran wrote:
> > I will try to get my hands on some HW, perhaps by the end of October,
> > in order to test and complete your driver...
>
> I now have a 88E6352 to test your
On Mon, Nov 06, 2017 at 06:55:46AM -0800, Richard Cochran wrote:
> On Sun, Oct 08, 2017 at 11:38:21AM -0400, Richard Cochran wrote:
> > I will try to get my hands on some HW, perhaps by the end of October,
> > in order to test and complete your driver...
>
> I now have a 88E6352 to test your
On Sun, Oct 08, 2017 at 11:38:21AM -0400, Richard Cochran wrote:
> I will try to get my hands on some HW, perhaps by the end of October,
> in order to test and complete your driver...
I now have a 88E6352 to test your series on. Unfortunately, it
doesn't really work. Here is what I did.
1. Gave
On Sun, Oct 08, 2017 at 11:38:21AM -0400, Richard Cochran wrote:
> I will try to get my hands on some HW, perhaps by the end of October,
> in order to test and complete your driver...
I now have a 88E6352 to test your series on. Unfortunately, it
doesn't really work. Here is what I did.
1. Gave
On Fri, Sep 29, 2017 at 05:43:23AM -0400, Richard Cochran wrote:
> I happy to see this series. I just finished porting an out-of-tree
> PHC driver for the Marvell mv88e635x, and I want to mainline it, but I
> also have a few uglies.
This series looks really good. I won't even post my mine, as
On Fri, Sep 29, 2017 at 05:43:23AM -0400, Richard Cochran wrote:
> I happy to see this series. I just finished porting an out-of-tree
> PHC driver for the Marvell mv88e635x, and I want to mainline it, but I
> also have a few uglies.
This series looks really good. I won't even post my mine, as
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, September 28, 2017 12:36 PM
>
> I assume ptp already has the core code to use pinctrl and Linux
> standard GPIOs? What does the device tree binding look like? How do
> you specify the GPIOs to use?
>
> What we want to avoid is defining
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, September 28, 2017 12:36 PM
>
> I assume ptp already has the core code to use pinctrl and Linux
> standard GPIOs? What does the device tree binding look like? How do
> you specify the GPIOs to use?
>
> What we want to avoid is defining
Brandon,
On Thu, Sep 28, 2017 at 10:25:32AM -0500, Brandon Streiff wrote:
> - Patch #2: We expose the switch time as a PTP clock but don't support
> adjustment (max_adj=0).
The driver should implement a cyclecounter/timecounter.
> Our platform adjusted a systemwide oscillator
> from
Brandon,
On Thu, Sep 28, 2017 at 10:25:32AM -0500, Brandon Streiff wrote:
> - Patch #2: We expose the switch time as a PTP clock but don't support
> adjustment (max_adj=0).
The driver should implement a cyclecounter/timecounter.
> Our platform adjusted a systemwide oscillator
> from
On 09/28/2017 10:36 AM, Andrew Lunn wrote:
>> - Patch #3: The GPIO config support is handled in a very simple manner.
>> I suspect a longer term goal would be to use pinctrl here.
>
> I assume ptp already has the core code to use pinctrl and Linux
> standard GPIOs? What does the device tree
On 09/28/2017 10:36 AM, Andrew Lunn wrote:
>> - Patch #3: The GPIO config support is handled in a very simple manner.
>> I suspect a longer term goal would be to use pinctrl here.
>
> I assume ptp already has the core code to use pinctrl and Linux
> standard GPIOs? What does the device tree
> - Patch #3: The GPIO config support is handled in a very simple manner.
> I suspect a longer term goal would be to use pinctrl here.
I assume ptp already has the core code to use pinctrl and Linux
standard GPIOs? What does the device tree binding look like? How do
you specify the GPIOs to
> - Patch #3: The GPIO config support is handled in a very simple manner.
> I suspect a longer term goal would be to use pinctrl here.
I assume ptp already has the core code to use pinctrl and Linux
standard GPIOs? What does the device tree binding look like? How do
you specify the GPIOs to
This patch series adds support for PTP timestamping through the DSA
framework, as well as an implementation for mv8e6xxx switches.
This implementation was targeted at a National Instruments platform
that uses the Marvell 88E6341 (Topaz). I've tried to enable support on
other Marvell switches
This patch series adds support for PTP timestamping through the DSA
framework, as well as an implementation for mv8e6xxx switches.
This implementation was targeted at a National Instruments platform
that uses the Marvell 88E6341 (Topaz). I've tried to enable support on
other Marvell switches
30 matches
Mail list logo
