On 5/1/2012 3:15 PM, Lars-Peter Clausen wrote:
On 05/01/2012 04:05 PM, Lars-Peter Clausen wrote:
On 05/01/2012 03:50 PM, Jonathan Cameron wrote:
On 5/1/2012 2:33 PM, Lars-Peter Clausen wrote:
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.
Hmm.. this is a pain. Could delay the device_unregister until the
iio_device_free. I think that's
what will typically trigger the release? The snag there is that leaves
the interfaces all
registered as we tear down the device. Alternative is to make damned
sure nothing holds
a reference long before we get to the free. The problem is we often
make plenty of
use of the iio_dev after the iio_device_unregister call but before the
iio_device_free.#
Gah. I hate trying to plough through lifetimes of data...
Always seems to bite you however careful you are.
That's not so much of a problem we can always grab a extra reference to the
device and release it in iio_device_free. But another issue is that the device
release function will never be called if the device hasn't be registered yet.
Which causes problems where we want to free the structure - for example - in
probe because some other function returned an error and we can't continue
registering the device.
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?
--
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
