[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45C4EDF9.7050804@joow.be>
Date: Sat, 03 Feb 2007 21:18:01 +0100
From: Pieter Palmers <pieterp@...w.be>
To: Stefan Richter <stefanr@...6.in-berlin.de>
CC: Dan Dennedy <dan@...nedy.org>,
linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH update] ieee1394: cycle timer read extension for raw1394/libraw1394
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists