On 5/1/2012 10:19 AM, Lars-Peter Clausen wrote:
On 04/30/2012 10:03 PM, Ge Gao wrote:
Dear all,
I am currently developing a driver for a chip that has gyro,
accelerometer and compass sensor together and these sensor data could come
at different rate. There could be more data coming from this chip because
this chip has on-chip CPU to do some data processing. The IIO subsystem is
in some sense "fixed" once "enable" is 1. "Fixed" means the element and
sequence inside ring buffer is fixed. For example, if MPU9150,
which is a 9-axis chip, containing gyro, accelerometer and compass, is
developed, the
ring buffer would have byte_per_datum of 32 bytes(6 + 6 + 6 = 18; 18
rounding up to 24; and 24 plus timestamp) if all sensors and all axis are
enabled . So every data packet should contain this amount of data no
matter what. If I have gyro running at 200 HZ, accelerometer running at
100Hz and compass running at 50 Hz, this will have problems. Because I
can't provide accelerometer data and compass data for each packet. Some
packets could miss data. I have to fake data for these packets, either by
repeating or other non-standard ways. Is this supposed to be? Because we
could have other data item which is even slower(10HZ quaternion data, for
example). This way, it will be more trouble. Because each data element has
different rate, while IIO needs them at the same rate.
The best way is to have a header for each packet to
indicate what packet it is. But this way seems to violate the design goal
of IIO. That would be more like input subsystem because input subsystem
uses different code type to distinguish different type of data thus
allowing different data type mixed together. If such driver is written,
all files under "scan_element" would be meaningless and useless.
I got some suggestions about using multiple IIO devices in one
driver because one IIO device can only has one ring buffer. It could be OK
to handle this. However, since IIO device allocation is to allocate the
private data directly along with IIO device, it seems one IIO driver can
only have one IIO device. Could IIO kernel accept such practice that one
IIO
driver has more than one IIO device? Or could there be some changes in
the IIO code such that such scenario is taken care of in the future?
The multiple IIO devices approach was the first that came to my mind while
reading your message. For the private data for these IIO devices you could just
allocate the space for one pointer and let it point to your real driver data.
Either that or don't use iio_priv at all. Embed the iio_dev structures
in a containing structure.
To do this would need the addition of some in place setup functions in
the core that do
the non allocation bits of iio_device_alloc and iio_device_free.
Perhaps Lars-Peter's
suggestion is easier.
What bothers me about a header equiped buffer is that a) it is much less
efficient, and
b) it'll not play well with the demux stuff that breaks the buffer
stream up for
multiple users (perhaps we don't care here though).
--
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
