RFC iio sensor mounting matrix support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 patches 7 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | iio:core: mounting matrix supportDocumentation/ drivers/ include/ | +157 | 0 replies | |
| 2/3 | iio:ak8975: add mounting matrix supportDocumentation/ drivers/ include/ | +64 | 1 reply | |
| 3/3 | iio:imu:mpu6050: enhance mounting matrix supportDocumentation/ drivers/ drivers/ +1 more | +72 | 5 replies |
Reviews trailers per patch
1 of 3 patches has a Reviewed-by or Acked-by.
| Patch | Rob Herring |
|---|---|
| 1/3 | |
| 2/3 | A-b |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC PATCH v1 0/3] iio sensor mounting matrix support
This RFC patch series follows up on Rob Herring and Jonathan Cameron comments about ak8975 magnetometer mounting matrix support. Thread starts here:
http://www.spinics.net/lists/linux-iio/msg23505.html
As a recall, we want to expose a rotation matrix to indicate userspace the chip placement with respect to the overall hardware system. This allows an application to adjust coordinates sampled from a sensor chip when its position deviates from the main hardware system.
Rob mentionned that the interface could be appropriate for other sensors such as gyro, accelero, etc... This would prevent from "ending up with a bunch of similar yet different interfaces".
Requirements:
1. delegate computation to userspace ;
2. floating point arithmetics support ;
3. per sample type matrix ;
4. remain compliant with legacy interface (mpu6050).
Point 1. above allows application to perform arbitrary transformations in addition to sensor alignment handling.
Point 2. is required for flexible chip positioning.
Point 3. comes from the fact that chips, such as ADIS16407, may implement different axis direction references for each measurement space.
See http://www.analog.com/media/en/technical-documentation/data-sheets/ADIS16407.pdf
Firs patch attached raise several questions for which I'd like to hear your suggestions.
Quoted 1 line
From point 3. above, we should end up with something like the following for a
a magneto + gyro + accelero chip :
iio:deviceX/in_anglvel_mount_matrix, applicable to all 3 gyro channels iio:deviceX/in_accel_mount_matrix, applicable to all 3 accelero channels iio:deviceX/in_magn_mount_matrix, applicable to all 3 magneto channels
Do we need to ensure proper naming consistency for sysfs attributes ? How ? Reuse iio_chan_type_name_spec array ?
Should we limit matrix sysfs attribute instantiation to a subset of sensor types ? Which ones ? Or should we leave this to driver writers choice ?
Last patch relates to mpu6050 mounting matrix evolutions : legacy attribute was extracted from platform_data. For sake of simplicity and as platform data mechanism is becoming more and more "obsolete", I implemented new mounting matrix API support for device-tree nodes only. Good enought ?
Best regards,
gregor.
Gregor Boirie (3):
iio:core: mounting matrix support iio:ak8975: add mounting matrix support iio:imu:mpu6050: enhance mounting matrix support
Documentation/ABI/testing/sysfs-bus-iio | 51 ++++++++++++++ .../devicetree/bindings/iio/imu/inv_mpu6050.txt | 13 ++++ .../bindings/iio/magnetometer/ak8975.txt | 10 +++ drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 56 +++++++++++++-- drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 4 +- drivers/iio/industrialio-core.c | 81 ++++++++++++++++++++++ drivers/iio/magnetometer/ak8975.c | 40 ++++++++++- include/linux/iio/magnetometer/ak8975.h | 16 +++++ include/linux/iio/sysfs.h | 25 +++++++ include/linux/platform_data/invensense_mpu6050.h | 5 +- 10 files changed, 293 insertions(+), 8 deletions(-) create mode 100644 include/linux/iio/magnetometer/ak8975.h
Signature · 1 line
2.1.4