Your help, and debug print statements, led me to understand that the macb
driver was trying to get the clock freq. from a "tsu-clk" property in the
device tree node. Since this was not defined, the device tree framework
was giving it a zero.
This was a clue that the MAC didn't have a clock.
So, I've since had the hardware definition files modified (in Xilinx's
vivado tool) to provide a "tsu" clock to the GEM MAC module. Rebuilding
the petalinux kernel now gives me a different error. Maybe there's
something we missed. Can you give me clues to help me figure out what I
should look at next?
ptp4l[1594.590]: driver changed our HWTSTAMP options
ptp4l[1594.590]: tx_type 1 not 1
ptp4l[1594.590]: rx_filter 1 not 12
ptp4l[1594.590]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[1595.142]: port 1: received SYNC without timestamp
ptp4l[1596.142]: port 1: received SYNC without timestamp
ptp4l[1596.577]: port 1: new foreign master 003064.fffe.1982cd-1
ptp4l[1597.143]: port 1: received SYNC without timestamp
ptp4l[1598.143]: port 1: received SYNC without timestamp
ptp4l[1599.143]: port 1: received SYNC without timestamp
ptp4l[1600.143]: port 1: received SYNC without timestamp
ptp4l[1600.577]: selected best master clock 003064.fffe.1982cd
ptp4l[1600.577]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1601.120]: missing timestamp on transmitted delay request
On Mon, Mar 19, 2018 at 3:30 PM, A <aaron.bi...@gmail.com> wrote:
>
> I am digging through linux kernel code to figure things out because I am
> still befuddled. Since I happened to find your name in the dp83640 driver,
> maybe you can tell me a little about how things work. I would appreciate a
> bit of a tutorial along the lines of your earlier statement that PHY and
> MAC timestamping can't coexist, or which should be doing the timestamping.
> Here is what I understand so far:
>
> The board I'm using has a TI DP83867IR, so I am looking in dp83867.c and
> comparing it to the perhaps more robust dp83640.c.
>
> => Your dp83640.c has a txtstamp and rxtstamp entries in the phy_driver
> structure, but my system's dp83867.c does NOT have these time stamping
> methods
>
> => To take the transmit case, and to demonstrate that things might be
> messed up: I see macb.c's macb_handle_txtstamp()
> calls timestamping.c's skb_clone_tx_timestamp(), but I'm afraid the
> latter is going to do nothing when it looks for the txtstamp() function:
>
> skb_clone_tx_timestamp() {
> ...
> if (likely(phydev->drv->txtstamp)) {
> clone = skb_clone_sk(skb);
> if (!clone)
> return;
> phydev->drv->txtstamp(phydev, clone, type);
> }
> ^^^ txtstamp should be null, I suppose, unless there is a default
> somewhere I can't see ^^^
>
> So it looks like the timestamping in MAC and PHY layers are supposed to
> cooperate, and they are not cooperating correctly.
>
> But then again, I'm not really sure which of these routines are doing what
> I think they are... I still haven't found the place where time is actually
> stamped, so I might be looking at a duck and thinking it is a pig...
>
> Sigh
>
> Thanks for sticking with me so far.
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
