Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "new" PTP cross-timestamp mechanism added in kernel version 4.6 #450

Closed

Conversation

christopher-s-hall
Copy link
Contributor

@christopher-s-hall christopher-s-hall commented Aug 8, 2016

Add support for HW timestamping & fix issue where link delay adjustments from .ini file are not applied correctly

christopher-s-hall and others added 4 commits August 8, 2016 10:15
Linux kernel version 4.6+ adds an additional cross timestamp ioctl for
hardware that supports it. The cross-timestamp is exposed through the PTP
driver interface. Intel PCH hardware reliably provides sub microsecond
accuracy.
The Github automated builds are based on a very old Linux distribution.
The precise timestamp ioctl is not available for these builds and the
patch will not build. Add ifdef's to prevent compile errors.
Fixes issue Avnu#456
The port parameter link delay is now set *after* the initialization file
is parsed
@andrew-elder
Copy link

How is PTP_SYS_OFFSET_PRECISE ever set? Should there be any comments anywhere describing how to set and use it?
Otherwise, changes look ok to me.

@christopher-s-hall
Copy link
Contributor Author

It will be defined in the kernel include file (include/uapi/linux) for kernel 4.6+ and not defined in previous versions. I’m fine with commenting it, but where?

Alternatively I could put something in the Makefile to test for this – probably a little messy – and add a wrapper. Now if someone were to grep for said wrapper it would be clear from the Makefile, in the form of a comment there, how it’s set.

All of this is somewhat academic because eventually these changes will be included as part of the standard headers and the need to wrap them in an ifdef will go away.

From: andrew-elder [mailto:notifications@github.com]
Sent: Thursday, August 18, 2016 12:37 PM
To: AVnu/Open-AVB
Cc: Hall, Christopher S; Author
Subject: Re: [AVnu/Open-AVB] Add support for "new" PTP cross-timestamp mechanism added in kernel version 4.6 (#450)

How is PTP_SYS_OFFSET_PRECISE ever set? Should there be any comments anywhere describing how to set and use it?
Otherwise, changes look ok to me.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//pull/450#issuecomment-240832683, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD0lxoVvmErFKkXo0b5FEOrK9bkMEZmDks5qhLRrgaJpZM4JfkzY.

@christopher-s-hall
Copy link
Contributor Author

Absent feedback I opted for the second. The Makefile explicitly checks for support and sets an internal variable.

@christopher-s-hall
Copy link
Contributor Author

Added fix for issue #456

\#ifdef PTP_SYS_OFFSET_PRECISE\\nint main(){return 0;}\\n\#endif"
HAS_PRECISE_TIME = $(shell echo $(PRECISE_TIME_TEST) | gcc -xc - \
-I$(ALTERNATE_LINUX_INCPATH) -o /dev/null > /dev/null 2>&1 ; echo $$?)

CFLAGS_G = -Wall -std=c++0x -g -I. -I../../common -I../src \

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, this is very clever. I personally think it is overkill in response to my "where does PTP_SYS_OFFSET" come from. I would have been 100% ok with a comment block in the .cpp module before the first usage of PTP_SYS_OFFSET_PRECISE explaining that kernels with precise time support have PTP_SYS_OFFSET_PRECISE defined in the linux/ptp_clock.h header file. My 2c. Others may have different opinions.

Sorry I was slow responding to the followup post on this topic.

@christopher-s-hall
Copy link
Contributor Author

The code is correct and in my opinion pretty clear. I would rather not spend more time on this. I don't think "overkill" should be a reason for code rejection.

@andrew-elder
Copy link

@christopher-s-hall - acknowledged. Can anyone else sign off on this?

@pinealservo
Copy link
Contributor

How come this got closed? I think there was a merge conflict indicated last time I saw it, but I didn't have time at the moment to see why. Aside from that, it looked fine as far as I can tell.

@christopher-s-hall
Copy link
Contributor Author

Now pull #462. That has fewer commits (on second look, it didn't make a lot of sense to have so many commits), but is the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants