On 05/01/2012 03:21 PM, Jonathan Cameron wrote: > 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. I just wanted to write that this will get you into trouble in regard to the 'struct device' lifetime expectancies. But then I realized that we do have the same problem already. We free the device in iio_device_free, but this will cause might cause a use after free if something still holds a reference to the device at this point. We should free the struct in iio_dev_release. - Lars -- 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
