On Wed, 29 May 2019 at 05:14, John Stultz wrote:
>
> On Tue, May 28, 2019 at 4:58 PM Vladimir Oltean wrote:
> >
> > Some PTP hardware offers a 64-bit free-running counter whose snapshots
> > are used for timestamping, but only makes part of that snapshot
> > available as timestamps (low-order bit
On Tue, May 28, 2019 at 07:14:22PM -0700, John Stultz wrote:
> Hrm. Is this actually generic? Would it make more sense to have the
> specific implementations with this quirk implement this in their
> read() handler? If not, why?
Strongly agree that this workaround should stay in the driver. After
On Tue, May 28, 2019 at 4:58 PM Vladimir Oltean wrote:
>
> Some PTP hardware offers a 64-bit free-running counter whose snapshots
> are used for timestamping, but only makes part of that snapshot
> available as timestamps (low-order bits).
>
> In that case, timecounter/cyclecounter users must brin
Some PTP hardware offers a 64-bit free-running counter whose snapshots
are used for timestamping, but only makes part of that snapshot
available as timestamps (low-order bits).
In that case, timecounter/cyclecounter users must bring the cyclecounter
and timestamps to the same bit width, and they c
4 matches
Mail list logo
