Re: different data rate in IIO ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/1/2012 7:28 PM, Ge Gao wrote:
Thanks for the advice. So it seems everyone agrees that multiple IIO device
is the way to go. What about the using a flag to indicate which data will
come like the one below:
Under IIO architecture, can we have another kind of ring buffer in addition
to sw_ring
sw_ring is probably dead. I'm not entirely convinced that we can work everything we want into kfifo, but there is a lot of resistance against another basic buffer implementation in the kernel. Hence if you did a buffer as you suggest it would probably need to be
based on kfifo (which rather tediously will add some significant overhead).
  and kfifo, such as header to indicate data type(gyro_x, gyro_y,
gyro_z, accel_x, accel_y, accel_z, compass_x, compass_y, compass_z,
quaternion_x, quaternion_y, quaternion_z, quaternion_c) followed by actual
data.
Yes. See the discussion in my followup to Kerry's email later in the thread. We can do this, but it comes with a not insignificant cost. Need real world numbers to know
if it is worth paying.
Also can we have some definition for quaternion? It is an important datum
for rotation calculation. It contains 4 elements, x, y, z and a constant.
Well drop the constant (get it from sysfs). How many bits for xyz?

And yes, a definition for a quaternion is definitely needed. Feel free to suggest one ;)

Ge


-----Original Message-----
From: Jonathan Cameron [mailto:jic23@xxxxxxxxx]
Sent: Tuesday, May 01, 2012 11:05 AM
To: Lars-Peter Clausen
Cc: Ge Gao; linux-iio@xxxxxxxxxxxxxxx
Subject: Re: different data rate in IIO ?



Lars-Peter Clausen<lars@xxxxxxxxxx>  wrote:

On 05/01/2012 04:50 PM, Jonathan Cameron wrote:
On 5/1/2012 3:15 PM, Lars-Peter Clausen wrote:
On 05/01/2012 04:05 PM, Lars-Peter Clausen wrote:
[...]
Ah, seems as if the refcounting infrastructure is already ready for
use after we have called device_initialize, so the above plan should
work
quite
well.
Call device_del in iio_device_unregister and device_put in
iio_device_free and free the struct in the release callback.
That makes sense given it just splits the two parts of
device_unregister
apart.
Don't suppose you want to do the patch?
I could write the patch, but I don't have a setup at hand right now
where I could test it, so this would have to wait until next week. I
wouldn't mind if you took care of it though :)
I'll aim to do it Saturday....  nothing to test on till then.
- Lars
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux