iio sensor mounting matrix support

From point 3. above, we should end up with something like the following for a

Expose a rotation matrix to indicate userspace the chip orientation with respect to the overall hardware system.

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../bindings/iio/magnetometer/ak8975.txt           | 10 ++++++

 drivers/iio/magnetometer/ak8975.c                  | 40 ++++++++++++++++++++--
 include/linux/iio/magnetometer/ak8975.h            | 16 +++++++++
 3 files changed, 64 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/iio/magnetometer/ak8975.h

Add a new rotation matrix sysfs attribute compliant with IIO core mounting matrix API.
Matrix is retrieved from "in_anglvel_mount_matrix" and "in_accel_mount_matrix" sysfs attributes. It is declared into mpu6050 DTS entry as a "mount-matrix" property.

Old interface is kept for backward userspace compatibility and may be retrieved from legacy platform_data mechanism only.

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../devicetree/bindings/iio/imu/inv_mpu6050.txt    | 13 +++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 56 ++++++++++++++++++++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          |  4 +-
 include/linux/platform_data/invensense_mpu6050.h   |  5 +-
 4 files changed, 72 insertions(+), 6 deletions(-)

Quoted 5 lines · Gregor Boirie

Add a new rotation matrix sysfs attribute compliant with IIO core mounting matrix API.
Matrix is retrieved from "in_anglvel_mount_matrix" and "in_accel_mount_matrix" sysfs attributes. It is declared into mpu6050 DTS entry as a "mount-matrix" property.

We have a common DT property, but can't have common sysfs interface?

BTW, sysfs interfaces also have to be documented.

Quoted 12 lines

Old interface is kept for backward userspace compatibility and may be retrieved from legacy platform_data mechanism only.

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../devicetree/bindings/iio/imu/inv_mpu6050.txt    | 13 +++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 56 ++++++++++++++++++++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          |  4 +-
 include/linux/platform_data/invensense_mpu6050.h   |  5 +-
 4 files changed, 72 insertions(+), 6 deletions(-)

Quoted 7 lines · Rob Herring

Quoted 5 lines · Gregor Boirie

Add a new rotation matrix sysfs attribute compliant with IIO core mounting matrix API.
Matrix is retrieved from "in_anglvel_mount_matrix" and "in_accel_mount_matrix" sysfs attributes. It is declared into mpu6050 DTS entry as a "mount-matrix" property.

Quoted 1 line

We have a common DT property, but can't have common sysfs interface?

Agreed. Original driver was structured that way. In fact, a single matrix is enought for this sensor: AFAIK, reference frames are the same for gyro and accelero.
I suppose that having a DTS and sysfs attribute per type of sample / "sub-device" ensure better userspace API consistency across drivers. Jonathan ?

Quoted 3 lines

BTW, sysfs interfaces also have to be documented.

Ok

Quoted 6 lines

Quoted 6 lines

Old interface is kept for backward userspace compatibility and may be retrieved from legacy platform_data mechanism only.

Quoted 7 lines

Quoted 7 lines

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../devicetree/bindings/iio/imu/inv_mpu6050.txt    | 13 +++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 56 ++++++++++++++++++++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          |  4 +-
 include/linux/platform_data/invensense_mpu6050.h   |  5 +-
 4 files changed, 72 insertions(+), 6 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 8 lines · Gregor Boirie

Quoted 7 lines · Rob Herring

Quoted 5 lines · Gregor Boirie

Add a new rotation matrix sysfs attribute compliant with IIO core mounting matrix API.
Matrix is retrieved from "in_anglvel_mount_matrix" and "in_accel_mount_matrix" sysfs attributes. It is declared into mpu6050 DTS entry as a "mount-matrix" property.

Quoted 7 lines

Quoted 1 line

We have a common DT property, but can't have common sysfs interface?

Agreed. Original driver was structured that way. In fact, a single matrix is enought for this sensor: AFAIK, reference frames are the same for gyro and accelero.
I suppose that having a DTS and sysfs attribute per type of sample / "sub-device" ensure better userspace API consistency across drivers. Jonathan ?

If shared by all channels in device, could just be mount_matrix (as per normal info_mask_shared_by_all elements on which we drop all reference to the channel name).

However, we do have to allow for the per channel type version (and at least in theory the per channel entry) There are are weird devices combining multiple parallel accelerometers in a package. Possible for some reason that these could be other than parallel in some future device.
So we end up with a sort of pyramid with any of the following being possible (and needing a sysfs entry if they occur) Taking a few examples...

mount_matrix
in_mount_matrix
out_mount_matrix
in_accel_mount_matrix
in_magn_mount_matrix
in_accel_x_mount_matrix
in_accel_y_mount_matrix
in_accel_x1_mount_matrix
in_accel_x2_mount_matrix
etc where convention is to use the element highest up that covers the device in question.

It gets awkward if you have say an additional general purpose ADC channel on the device as then clearly the mount matrix has nothing to do with it, but convention says we still have to drop down to say in_accel_mount_matrix rather than using the mount_matrix form that implies that it applies to the in_voltage0 channel. Common sense and ABIs never combine that well ;)

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

BTW, sysfs interfaces also have to be documented.

Ok

Yes - update Documentation/sysfs/testing/sysfs-bus-iio with an appropriate entry please. Btw - the above pyramid structure is why that document is huge (and often missing entries that we all assumed were there for particular combinations of the above!)

Quoted 13 lines

Quoted 6 lines

Quoted 6 lines

Old interface is kept for backward userspace compatibility and may be retrieved from legacy platform_data mechanism only.

Quoted 7 lines

Quoted 7 lines

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../devicetree/bindings/iio/imu/inv_mpu6050.txt    | 13 +++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 56 ++++++++++++++++++++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          |  4 +-
 include/linux/platform_data/invensense_mpu6050.h   |  5 +-
 4 files changed, 72 insertions(+), 6 deletions(-)

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 38 lines · Jonathan Cameron

Quoted 8 lines · Gregor Boirie

Quoted 7 lines · Rob Herring

Quoted 5 lines · Gregor Boirie

Add a new rotation matrix sysfs attribute compliant with IIO core mounting matrix API.
Matrix is retrieved from "in_anglvel_mount_matrix" and "in_accel_mount_matrix" sysfs attributes. It is declared into mpu6050 DTS entry as a "mount-matrix" property.

Quoted 7 lines

Quoted 1 line

We have a common DT property, but can't have common sysfs interface?

Agreed. Original driver was structured that way. In fact, a single matrix is enought for this sensor: AFAIK, reference frames are the same for gyro and accelero.
I suppose that having a DTS and sysfs attribute per type of sample / "sub-device" ensure better userspace API consistency across drivers. Jonathan ?

If shared by all channels in device, could just be mount_matrix (as per normal info_mask_shared_by_all elements on which we drop all reference to the channel name).

However, we do have to allow for the per channel type version (and at least in theory the per channel entry) There are are weird devices combining multiple parallel accelerometers in a package. Possible for some reason that these could be other than parallel in some future device.
So we end up with a sort of pyramid with any of the following being possible (and needing a sysfs entry if they occur) Taking a few examples...

mount_matrix
in_mount_matrix
out_mount_matrix
in_accel_mount_matrix
in_magn_mount_matrix
in_accel_x_mount_matrix
in_accel_y_mount_matrix
in_accel_x1_mount_matrix
in_accel_x2_mount_matrix
etc where convention is to use the element highest up that covers the device in question.

Quoted 5 lines

It gets awkward if you have say an additional general purpose ADC channel on the device as then clearly the mount matrix has nothing to do with it, but convention says we still have to drop down to say in_accel_mount_matrix rather than using the mount_matrix form that implies that it applies to the in_voltage0 channel. Common sense and ABIs never combine that well ;)

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

BTW, sysfs interfaces also have to be documented.

Ok

Yes - update Documentation/sysfs/testing/sysfs-bus-iio with an appropriate entry please. Btw - the above pyramid structure is why that document is huge (and often missing entries that we all assumed were there for particular combinations of the above!)

You have documented it in patch 1. I'd forgotten about that. :)

Quoted 19 lines

Quoted 13 lines

Quoted 6 lines

Quoted 6 lines

Old interface is kept for backward userspace compatibility and may be retrieved from legacy platform_data mechanism only.

Quoted 7 lines

Quoted 7 lines

Signed-off-by Gregor Boirie <gregor.boirie-ITF29qwbsa/[email protected]>

---
 .../devicetree/bindings/iio/imu/inv_mpu6050.txt    | 13 +++++
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c         | 56 ++++++++++++++++++++--
 drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h          |  4 +-
 include/linux/platform_data/invensense_mpu6050.h   |  5 +-
 4 files changed, 72 insertions(+), 6 deletions(-)

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

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