On 26/06/16 18:56, Jonathan Cameron wrote: > On 24/06/16 12:15, Vlad Dogaru wrote: >> Hi everyone, >> >> This is a minimal implementation of a driver for the Bosch Sensortec >> BNO055, a very interesting accel-gyro-magneto combo. The datasheet is >> available at https://www.bosch-sensortec.com/bst/products/all_products/bno055 > 'interesting' device indeed. >> >> The driver in its present state works, but this is a RFC for a few >> reasons detailed below: >> >> (1) The device has a few possible operating modes. The most simple >> ones employ a single sensor and power down the other two; the most >> complex use all 3 for sensor fusion. Changing the mode at runtime would >> require changing the channels and I'm not sure IIO allows that. > It allows a much greater set of channels than can run at one time though.. > Would that work here? Lots of fun with available_scan_masks and > friends, but from your description here sounds fine (will look at > the code in a minute). >> So I've >> opted to choose the mode at probe time, based on a DeviceTree property. >> Hope that's ok. > Would rather it was runtime controllable I think... Hmm. I can see this is complex because obviously the fusion has to start at some point and if we flipped to reading a single axis it would get turned off. Hideous though it is, perhaps an 'enable_fusion_engine' attribute would be the way to do it with channels returning EBUSY if they are not available in a given mode. There are some precedents for this as there are parts that cannot do both events and raw data reading at the same time. e.g. the Max1363 (well technically that part can, but it was so nasty to implement I never did it an no one has ever cared since). We could only enable the fusion engine once the buffer is enabled, but that seems a bit clunky given the fused data is in someways the most useful stuff to get via polled reads. 'What orientation am I at now?' I'm definitely looking for other opinions on this one! Jonathan >> >> (2) Fusion modes provide orientation data. This is either relative to >> the initial position of the sensor, or to magnetic North. > Something new :) >> There is a >> modifier, IIO_MOD_NORTH_MAGN, > I'm trying to remember why we have that... Ah, just checked docs, it > was for devices that offered planar rotation angles from north. >> but it occupies the same field as >> IIO_MOD_QUATERNION > With hindsight we should probably have made that a new channel type > rather than trying to mash it into the rotation type. Perhaps doing > that now is the way to go and adding the interface to the hid sensor > device driver that is the only user (keeping the old option as well > for compatibility reasons). > >> and IIO_MOD_{X,Y,Z}, so we can't use both. > This is kind of related to mounting matrix, be it a 'world mounting matrix'. > I wonder if we want to support it in a vaguely similar way... > > Therefore >> there is currently no means of telling from user space whether the >> orientation is relative to North or to the initial position; one could >> look at the DeviceTree description to deduce the operating mode, but >> that's hardly ideal. > Absolutely, this one needs to be exposed in userspace. > > Is there a means of resetting the initial position at runtime? > Providing an attribute to do that might be the cleanest option if > so. Not sure if there are any benefits to picking the initial value > against the north one otherwise... >> >> (3) In fusion modes, the device also exposes linear and gravitational >> accelerations, but IIO doesn't seem to support this. I can add these >> channel types if you believe they are useful. > > They will indeed have to be new channel types as you suggest, though > 'linear' is a rather unclear name to my mind. > >> >> >> Vlad Dogaru (1): >> iio: imu: add driver for Bosch Sensortec BNO055 >> >> drivers/iio/imu/Kconfig | 11 + >> drivers/iio/imu/Makefile | 1 + >> drivers/iio/imu/bno055.c | 569 +++++++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 581 insertions(+) >> create mode 100644 drivers/iio/imu/bno055.c >> > > -- > 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
