Stefan Richter wrote:
I wrote:
+++ linux/drivers/ieee1394/raw1394.h 2007-02-03 13:47:34.000000000 +0100
@@ -178,4 +178,14 @@ struct raw1394_iso_status {
__s16 xmit_cycle;
};
+/* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
+struct raw1394_cycle_timer {
+ /* contents of Isochronous Cycle Timer register,
+ as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
+ __u32 cycle_timer;
+
+ /* local time in microseconds since Epoch,
+ simultaneously read with cycle timer */
+ __u64 local_time;
+};
#endif /* IEEE1394_RAW1394_H */
Pieter,
one more thing. Do you want to hand out the cycle_timer bitfield to
userspace as-is, or would it make sense to postprocess it in some way?
I like it as is. most of the time I convert it into ticks, but sometimes
I just need the cycles.
Another reason not to postprocess is that it gives userspace more
freedom in how accurate they want to use the cycle time. I'm probably
going to throw away the seconds field altogether, because one second is
a huge timeframe in my application. Throwing away the seconds field
saves me quite some calculations.
Pieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
