On Wed, 5 Nov 2014 17:34:23 +0100, Richard Cochran wrote:
I like the idea of automatic phc2sys, if it would only work right.
It's definitely not complete yet and I'm not surprised there are bugs
(although I did my best to support also future cases, it's hard to get
it right without the actual
On Wed, Nov 05, 2014 at 05:56:28PM +0100, Jiri Benc wrote:
My plan for the next steps has been allowing ptp4l to work with multiple
independent PHCs that would form a PTP clock (and rely on phc2sys to
sync those PHCs).
Doesn't my patch #2 do this?
This needs separation of struct clock into
On Wed, 5 Nov 2014 19:58:32 +0100, Richard Cochran wrote:
On Wed, Nov 05, 2014 at 05:56:28PM +0100, Jiri Benc wrote:
My plan for the next steps has been allowing ptp4l to work with
multiple independent PHCs that would form a PTP clock (and rely on
phc2sys to sync those PHCs).
Doesn't my
On Wed, Nov 05, 2014 at 08:28:04PM +0100, Jiri Benc wrote:
I'm not sure whether this patch was enough to support the boundary
clock or more was needed but I remember I had the boundary clock stuff
done (though untested) and I cannot find anything on top of this, so
this was probably enough.
On Sat, 2014-11-01 at 20:00 +0100, Richard Cochran wrote:
Before releasing v1.5, I wanted to test phc2sys's new automatic mode
in order to run a BC using a bunch of PCIe cards, but I found it did
not quite work. First of all, the port logic bails out when the PHC
device don't match, and
Before releasing v1.5, I wanted to test phc2sys's new automatic mode
in order to run a BC using a bunch of PCIe cards, but I found it did
not quite work. First of all, the port logic bails out when the PHC
device don't match, and secondly phc2sys has one line bug.
After hacking those two problems
