Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On 09/03/18 11:22, Michael Brown wrote: Also, will you be able to mainline your driver? It helps new kernel API acceptance when there is an actual, realistic use case and users. > I'm aiming to get the code up on GitHub as an out-of-tree driver today or early next week, and we'll be mainlining it as soon as possible. After some hours of hacking with git filter-branch, I have a repository up on GitHub for our DecaWave DW1000-based board: https://github.com/mcb30/dw1000 This includes the out-of-tree kernel driver plus the PCB layout and EEPROM generator. A README will follow shortly. Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On 09/03/18 01:40, Richard Cochran wrote:
For the kernel, I (and others) would like to get away from the clunky
timespec altogether. Dividing a time value into two fields might have
made sense 30 years ago when operations on eight byte words were
expensive, but today it makes no sense. It only causes pointless
extra computation, first in user space and again the kernel,
converting to and from the timespec.
How about this?
SOF_TIMESTAMPING_HIGH_RES requests time stamps in a new format:
struct {
uint64_t nanoseconds;
uint32_t fractional_nanoseconds;
uint32_t reserved;
};
Would that be enough resolution for you?
Yes, that's plenty of resolution for us. The clock in question is a
nominal 64GHz.
I'll put together a patch based on your suggested format.
Also, will you be able to mainline your driver? It helps new kernel
API acceptance when there is an actual, realistic use case and users.
I'm aiming to get the code up on GitHub as an out-of-tree driver today
or early next week, and we'll be mainlining it as soon as possible.
We can also send you a pair of sample devices, if that would be of interest.
Michael
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On Thu, Mar 08, 2018 at 07:18:04PM +, Michael Brown wrote:
> Can you give me some idea of what names will be acceptable? I was trying to
> fit within the current naming scheme as closely as possible, but I'm very
> happy to redo it with whatever names you prefer.
Let me think about this. Part of the problem is the hwts.sw field,
which is an ugly hack to being with. That probably should be changed.
> One idea is to extend struct scm_timestamping to append a fractional
> nanosecond field for the hardware timestamp only. This would produce a
> layout that is backwards compatible with older userspace, which would simply
> ignore the fractional part (assuming that it does a minimum-length rather
> than exact-length check on cmsg_len).
>
> Does this sound sensible?
For the kernel, I (and others) would like to get away from the clunky
timespec altogether. Dividing a time value into two fields might have
made sense 30 years ago when operations on eight byte words were
expensive, but today it makes no sense. It only causes pointless
extra computation, first in user space and again the kernel,
converting to and from the timespec.
How about this?
SOF_TIMESTAMPING_HIGH_RES requests time stamps in a new format:
struct {
uint64_t nanoseconds;
uint32_t fractional_nanoseconds;
uint32_t reserved;
};
Would that be enough resolution for you?
Also, will you be able to mainline your driver? It helps new kernel
API acceptance when there is an actual, realistic use case and users.
Thanks,
Richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On 08/03/18 04:46, Richard Cochran wrote: On Thu, Mar 01, 2018 at 06:12:27PM +, Michael Brown wrote: Add converters between hardware timestamps and the internal representation, and remove code that directly manipulates the timespec within a hardware timestamp. Although I can see the point of this, still I really dislike this patch. The method names are icky: hwts_sw_to_tmv? Also, it changes too much at once for my taste. I'm happy to rework to more granular patches. Can you give me some idea of what names will be acceptable? I was trying to fit within the current naming scheme as closely as possible, but I'm very happy to redo it with whatever names you prefer. If new, high resolution time stamps will be coming from the kernel, then we definitely will need a better abstraction. But we should talk about what that new form will look like first. I was hoping to get your input on that anyway. :) One idea is to extend struct scm_timestamping to append a fractional nanosecond field for the hardware timestamp only. This would produce a layout that is backwards compatible with older userspace, which would simply ignore the fractional part (assuming that it does a minimum-length rather than exact-length check on cmsg_len). Does this sound sensible? Thanks, Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On Thu, Mar 01, 2018 at 06:12:27PM +, Michael Brown wrote: > Add converters between hardware timestamps and the internal > representation, and remove code that directly manipulates the timespec > within a hardware timestamp. Although I can see the point of this, still I really dislike this patch. The method names are icky: hwts_sw_to_tmv? Also, it changes too much at once for my taste. If new, high resolution time stamps will be coming from the kernel, then we definitely will need a better abstraction. But we should talk about what that new form will look like first. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
