[PATCH 1/4] IIO: core: Introduce read_raw_multi

[PATCH 1/4] IIO: core: Introduce read_raw_multi

[Srinivas Pandruvada]

This callback is introduced to overcome some limitations of existing
read_raw callback. The functionality of both existing read_raw and
read_raw_multi is similar, both are used to request values from the
device. The current read_raw callback allows only two return values.
The new read_raw_multi allows returning multiple values. Instead of
passing just address of val and val2, it passes length and pointer
to values. Depending on the type and length of passed buffer, iio
client drivers can return multiple values.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 drivers/iio/iio_core.h           |  2 +-
 drivers/iio/industrialio-core.c  | 51 +++++++++++++++++++++++-----------------
 drivers/iio/industrialio-event.c |  6 +++--
 drivers/iio/inkern.c             | 15 ++++++++++--
 include/linux/iio/iio.h          | 16 +++++++++++++
 5 files changed, 63 insertions(+), 27 deletions(-)

diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
index f6db6af..4172f22 100644
--- a/drivers/iio/iio_core.h
+++ b/drivers/iio/iio_core.h
@@ -35,7 +35,7 @@ int __iio_add_chan_devattr(const char *postfix,
 			   struct list_head *attr_list);
 void iio_free_chan_devattr_list(struct list_head *attr_list);
 
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2);
+ssize_t iio_format_value(char *buf, unsigned int type, int *val);
 
 /* Event interface flags */
 #define IIO_BUSY_BIT_POS 1
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 18f72e3..f8b730a 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -367,41 +367,42 @@ EXPORT_SYMBOL_GPL(iio_enum_write);
  * @buf: The buffer to which the formated value gets written
  * @type: One of the IIO_VAL_... constants. This decides how the val and val2
  *        parameters are formatted.
- * @val: First part of the value, exact meaning depends on the type parameter.
- * @val2: Second part of the value, exact meaning depends on the type parameter.
+ * @vals: pointer to the values, exact meaning depends on the type parameter.
  */
-ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2)
+ssize_t iio_format_value(char *buf, unsigned int type, int *vals)
 {
 	unsigned long long tmp;
 	bool scale_db = false;
 
 	switch (type) {
 	case IIO_VAL_INT:
-		return sprintf(buf, "%d\n", val);
+		return sprintf(buf, "%d\n", vals[0]);
 	case IIO_VAL_INT_PLUS_MICRO_DB:
 		scale_db = true;
 	case IIO_VAL_INT_PLUS_MICRO:
-		if (val2 < 0)
-			return sprintf(buf, "-%ld.%06u%s\n", abs(val), -val2,
+		if (vals[1] < 0)
+			return sprintf(buf, "-%ld.%06u%s\n", abs(vals[0]),
+					-vals[1],
 				scale_db ? " dB" : "");
 		else
-			return sprintf(buf, "%d.%06u%s\n", val, val2,
+			return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
 				scale_db ? " dB" : "");
 	case IIO_VAL_INT_PLUS_NANO:
-		if (val2 < 0)
-			return sprintf(buf, "-%ld.%09u\n", abs(val), -val2);
+		if (vals[1] < 0)
+			return sprintf(buf, "-%ld.%09u\n", abs(vals[0]),
+					-vals[1]);
 		else
-			return sprintf(buf, "%d.%09u\n", val, val2);
+			return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
 	case IIO_VAL_FRACTIONAL:
-		tmp = div_s64((s64)val * 1000000000LL, val2);
-		val2 = do_div(tmp, 1000000000LL);
-		val = tmp;
-		return sprintf(buf, "%d.%09u\n", val, val2);
+		tmp = div_s64((s64)vals[0] * 1000000000LL, vals[1]);
+		vals[1] = do_div(tmp, 1000000000LL);
+		vals[0] = tmp;
+		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
 	case IIO_VAL_FRACTIONAL_LOG2:
-		tmp = (s64)val * 1000000000LL >> val2;
-		val2 = do_div(tmp, 1000000000LL);
-		val = tmp;
-		return sprintf(buf, "%d.%09u\n", val, val2);
+		tmp = (s64)vals[0] * 1000000000LL >> vals[1];
+		vals[1] = do_div(tmp, 1000000000LL);
+		vals[0] = tmp;
+		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
 	default:
 		return 0;
 	}
@@ -413,14 +414,20 @@ static ssize_t iio_read_channel_info(struct device *dev,
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
-	int val, val2;
-	int ret = indio_dev->info->read_raw(indio_dev, this_attr->c,
-					    &val, &val2, this_attr->address);
+	int vals[INDIO_MAX_RAW_ELEMENTS];
+	int ret;
+
+	if (indio_dev->info->read_raw_multi)
+		ret = indio_dev->info->read_raw_multi(indio_dev, this_attr->c,
+			    INDIO_MAX_RAW_ELEMENTS, vals, this_attr->address);
+	else
+		ret = indio_dev->info->read_raw(indio_dev, this_attr->c,
+				    &vals[0], &vals[1], this_attr->address);
 
 	if (ret < 0)
 		return ret;
 
-	return iio_format_value(buf, ret, val, val2);
+	return iio_format_value(buf, ret, vals);
 }
 
 /**
diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
index c10eab6..b249b48 100644
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@ -274,7 +274,7 @@ static ssize_t iio_ev_value_show(struct device *dev,
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
-	int val, val2;
+	int val, val2, val_arr[2];
 	int ret;
 
 	if (indio_dev->info->read_event_value) {
@@ -290,7 +290,9 @@ static ssize_t iio_ev_value_show(struct device *dev,
 			&val, &val2);
 		if (ret < 0)
 			return ret;
-		return iio_format_value(buf, ret, val, val2);
+		val_arr[0] = val;
+		val_arr[1] = val2;
+		return iio_format_value(buf, ret, val_arr);
 	}
 }
 
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..6a93d57 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -417,12 +417,23 @@ static int iio_channel_read(struct iio_channel *chan, int *val, int *val2,
 	enum iio_chan_info_enum info)
 {
 	int unused;
+	int vals[INDIO_MAX_RAW_ELEMENTS];
+	int ret;
 
 	if (val2 == NULL)
 		val2 = &unused;
 
-	return chan->indio_dev->info->read_raw(chan->indio_dev, chan->channel,
-						val, val2, info);
+	if (chan->indio_dev->info->read_raw_multi) {
+		ret = chan->indio_dev->info->read_raw_multi(chan->indio_dev,
+					chan->channel, INDIO_MAX_RAW_ELEMENTS,
+					vals, info);
+		*val = vals[0];
+		*val2 = vals[1];
+	} else
+		ret = chan->indio_dev->info->read_raw(chan->indio_dev,
+					chan->channel, val, val2, info);
+
+	return ret;
 }
 
 int iio_read_channel_raw(struct iio_channel *chan, int *val)
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 256a90a..7f76a45 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -286,6 +286,8 @@ static inline s64 iio_get_time_ns(void)
 #define INDIO_ALL_BUFFER_MODES					\
 	(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE)
 
+#define INDIO_MAX_RAW_ELEMENTS		4
+
 struct iio_trigger; /* forward declaration */
 struct iio_dev;
 
@@ -300,6 +302,14 @@ struct iio_dev;
  *			the channel in question.  Return value will specify the
  *			type of value returned by the device. val and val2 will
  *			contain the elements making up the returned value.
+ * @read_raw_multi:	function to return values from the device.
+ *			mask specifies which value. Note 0 means a reading of
+ *			the channel in question.  Return value will specify the
+ *			type of value returned by the device. vals pointer
+ *			contain the elements making up the returned value.
+ *			val_len specifies maximum number of elements
+ *			vals pointer can contain. In contrast to to read_raw
+ *			device can return multiple values not just two.
  * @write_raw:		function to write a value to the device.
  *			Parameters are the same as for read_raw.
  * @write_raw_get_fmt:	callback function to query the expected
@@ -334,6 +344,12 @@ struct iio_info {
 			int *val2,
 			long mask);
 
+	int (*read_raw_multi)(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int val_len,
+			int *vals,
+			long mask);
+
 	int (*write_raw)(struct iio_dev *indio_dev,
 			 struct iio_chan_spec const *chan,
 			 int val,
-- 
1.8.3.2

[PATCH 2/4] IIO: core: Modify scan element type

[Srinivas Pandruvada]

The current scan element type uses the following format:
  [be|le]:[s|u]bits/storagebits[>>shift].
To specify multiple elements in this type, added a repeat value.
So new format is:
  [be|le]:([s|u]bits/storagebits){repeat}[>>shift].
Here repeat is specifying how may times, real/storage bits are repeating.

When repeat is value is 0 or 1, then repeat value is not used in the format,
and it will be same as existing format.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 drivers/iio/industrialio-buffer.c | 41 +++++++++++++++++++++++++++++++++------
 include/linux/iio/iio.h           |  9 +++++++++
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
index 7f9152c..ee57d94 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -121,7 +121,16 @@ static ssize_t iio_show_fixed_type(struct device *dev,
 		type = IIO_BE;
 #endif
 	}
-	return sprintf(buf, "%s:%c%d/%d>>%u\n",
+	if (this_attr->c->scan_type.repeat > 1)
+		return sprintf(buf, "%s:(%c%d/%d){%d}>>%u\n",
+		       iio_endian_prefix[type],
+		       this_attr->c->scan_type.sign,
+		       this_attr->c->scan_type.realbits,
+		       this_attr->c->scan_type.storagebits,
+		       this_attr->c->scan_type.repeat,
+		       this_attr->c->scan_type.shift);
+		else
+			return sprintf(buf, "%s:%c%d/%d>>%u\n",
 		       iio_endian_prefix[type],
 		       this_attr->c->scan_type.sign,
 		       this_attr->c->scan_type.realbits,
@@ -446,14 +455,22 @@ static int iio_compute_scan_bytes(struct iio_dev *indio_dev,
 	for_each_set_bit(i, mask,
 			 indio_dev->masklength) {
 		ch = iio_find_channel_from_si(indio_dev, i);
-		length = ch->scan_type.storagebits / 8;
+		if (ch->scan_type.repeat > 1)
+			length = ch->scan_type.storagebits / 8 *
+				ch->scan_type.repeat;
+		else
+			length = ch->scan_type.storagebits / 8;
 		bytes = ALIGN(bytes, length);
 		bytes += length;
 	}
 	if (timestamp) {
 		ch = iio_find_channel_from_si(indio_dev,
 					      indio_dev->scan_index_timestamp);
-		length = ch->scan_type.storagebits / 8;
+		if (ch->scan_type.repeat > 1)
+			length = ch->scan_type.storagebits / 8 *
+				ch->scan_type.repeat;
+		else
+			length = ch->scan_type.storagebits / 8;
 		bytes = ALIGN(bytes, length);
 		bytes += length;
 	}
@@ -932,7 +949,11 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
 					       indio_dev->masklength,
 					       in_ind + 1);
 			ch = iio_find_channel_from_si(indio_dev, in_ind);
-			length = ch->scan_type.storagebits/8;
+			if (ch->scan_type.repeat > 1)
+				length = ch->scan_type.storagebits / 8 *
+					ch->scan_type.repeat;
+			else
+				length = ch->scan_type.storagebits / 8;
 			/* Make sure we are aligned */
 			in_loc += length;
 			if (in_loc % length)
@@ -944,7 +965,11 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
 			goto error_clear_mux_table;
 		}
 		ch = iio_find_channel_from_si(indio_dev, in_ind);
-		length = ch->scan_type.storagebits/8;
+		if (ch->scan_type.repeat > 1)
+			length = ch->scan_type.storagebits / 8 *
+				ch->scan_type.repeat;
+		else
+			length = ch->scan_type.storagebits / 8;
 		if (out_loc % length)
 			out_loc += length - out_loc % length;
 		if (in_loc % length)
@@ -965,7 +990,11 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
 		}
 		ch = iio_find_channel_from_si(indio_dev,
 			indio_dev->scan_index_timestamp);
-		length = ch->scan_type.storagebits/8;
+		if (ch->scan_type.repeat > 1)
+			length = ch->scan_type.storagebits / 8 *
+				ch->scan_type.repeat;
+		else
+			length = ch->scan_type.storagebits / 8;
 		if (out_loc % length)
 			out_loc += length - out_loc % length;
 		if (in_loc % length)
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 7f76a45..0ac25a0 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -177,6 +177,14 @@ struct iio_event_spec {
  *			shift:		Shift right by this before masking out
  *					realbits.
  *			endianness:	little or big endian
+ *			repeat:		No. of times real/storage bits repeats.
+ *					By default, when repeat is set to 0
+ *					repeat value is treated as 1. When
+ *					repeat value is 0 or 1, then there is
+ *					no change in existing scan element
+ *					type, in sysfs. When set to more than
+ *					1, then the type element in sysfs will
+ *					show repeat value.
  * @info_mask_separate: What information is to be exported that is specific to
  *			this channel.
  * @info_mask_shared_by_type: What information is to be exported that is shared
@@ -220,6 +228,7 @@ struct iio_chan_spec {
 		u8	realbits;
 		u8	storagebits;
 		u8	shift;
+		u8	repeat;
 		enum iio_endian endianness;
 	} scan_type;
 	long			info_mask_separate;
-- 
1.8.3.2

[PATCH 3/4] IIO: core: Introduce Quaternion types

[Srinivas Pandruvada]

Introduced IIO_VAL_QUATERNION and its formatting. Format used here:
x:y:z:w
In addition IIO_QUAT_ROT is added to the channel type and name.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 drivers/iio/industrialio-core.c | 4 ++++
 include/linux/iio/types.h       | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index f8b730a..267b0a0 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -69,6 +69,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_ALTVOLTAGE] = "altvoltage",
 	[IIO_CCT] = "cct",
 	[IIO_PRESSURE] = "pressure",
+	[IIO_QUAT_ROT] = "rotquaternion",
 };
 
 static const char * const iio_modifier_names[] = {
@@ -403,6 +404,9 @@ ssize_t iio_format_value(char *buf, unsigned int type, int *vals)
 		vals[1] = do_div(tmp, 1000000000LL);
 		vals[0] = tmp;
 		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
+	case IIO_VAL_QUATERNION:
+		return sprintf(buf, "%d:%d:%d:%d\n", vals[0], vals[1], vals[2],
+							vals[3]);
 	default:
 		return 0;
 	}
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 4ac928e..878db0e 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -29,6 +29,7 @@ enum iio_chan_type {
 	IIO_ALTVOLTAGE,
 	IIO_CCT,
 	IIO_PRESSURE,
+	IIO_QUAT_ROT,
 };
 
 enum iio_modifier {
@@ -52,6 +53,7 @@ enum iio_modifier {
 	IIO_MOD_LIGHT_RED,
 	IIO_MOD_LIGHT_GREEN,
 	IIO_MOD_LIGHT_BLUE,
+	IIO_MOD_QUATERNION,
 };
 
 enum iio_event_type {
@@ -78,6 +80,7 @@ enum iio_event_direction {
 #define IIO_VAL_INT_PLUS_MICRO 2
 #define IIO_VAL_INT_PLUS_NANO 3
 #define IIO_VAL_INT_PLUS_MICRO_DB 4
+#define IIO_VAL_QUATERNION 5
 #define IIO_VAL_FRACTIONAL 10
 #define IIO_VAL_FRACTIONAL_LOG2 11
 
-- 
1.8.3.2

[PATCH 4/4] iio: hid-sensors: Added device rotation support

[Srinivas Pandruvada]

Added usage id processing for device rotation. This uses IIO
interfaces for triggered buffer to present data to user
mode.This uses HID sensor framework for registering callback
events from the sensor hub.
Data is exported to user space in the form of quaternion rotation
format.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 drivers/iio/orientation/Kconfig               |  11 +
 drivers/iio/orientation/Makefile              |   1 +
 drivers/iio/orientation/hid-sensor-rotation.c | 360 ++++++++++++++++++++++++++
 include/linux/hid-sensor-ids.h                |   1 +
 4 files changed, 373 insertions(+)
 create mode 100644 drivers/iio/orientation/hid-sensor-rotation.c

diff --git a/drivers/iio/orientation/Kconfig b/drivers/iio/orientation/Kconfig
index 58c62c8..da8bd8a 100644
--- a/drivers/iio/orientation/Kconfig
+++ b/drivers/iio/orientation/Kconfig
@@ -16,4 +16,15 @@ config HID_SENSOR_INCLINOMETER_3D
 	  Say yes here to build support for the HID SENSOR
 	  Inclinometer 3D.
 
+config HID_SENSOR_DEVICE_ROTATION
+	depends on HID_SENSOR_HUB
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
+	select HID_SENSOR_IIO_COMMON
+	select HID_SENSOR_IIO_TRIGGER
+	tristate "HID Device Rotation"
+	help
+	  Say yes here to build support for the HID SENSOR
+	  device rotation.
+
 endmenu
diff --git a/drivers/iio/orientation/Makefile b/drivers/iio/orientation/Makefile
index 2c97572..4734dab 100644
--- a/drivers/iio/orientation/Makefile
+++ b/drivers/iio/orientation/Makefile
@@ -4,3 +4,4 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_HID_SENSOR_INCLINOMETER_3D) += hid-sensor-incl-3d.o
+obj-$(CONFIG_HID_SENSOR_DEVICE_ROTATION) += hid-sensor-rotation.o
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
new file mode 100644
index 0000000..3ff0e72
--- /dev/null
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -0,0 +1,360 @@
+/*
+ * HID Sensors Driver
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/slab.h>
+#include <linux/hid-sensor-hub.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include "../common/hid-sensors/hid-sensor-trigger.h"
+
+#define MAX_QUATERNION_COMP	4
+
+struct dev_rot_state {
+	struct hid_sensor_hub_callbacks callbacks;
+	struct hid_sensor_common common_attributes;
+	struct hid_sensor_hub_attribute_info quaternion;
+	u32 sampled_vals[MAX_QUATERNION_COMP];
+};
+
+/* Channel definitions */
+static const struct iio_chan_spec dev_rot_channels[] = {
+	{
+		.type = IIO_QUAT_ROT,
+		.modified = 1,
+		.channel2 = IIO_MOD_QUATERNION,
+		.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+					BIT(IIO_CHAN_INFO_SCALE) |
+					BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+					BIT(IIO_CHAN_INFO_HYSTERESIS) |
+					BIT(IIO_CHAN_INFO_RAW),
+	}
+};
+
+/* Adjust channel real bits based on report descriptor */
+static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec *chan,
+					    int size)
+{
+	chan->scan_type.sign = 's';
+	/* Real storage bits will change based on the report desc. */
+	chan->scan_type.realbits = size * 8;
+	/* Maximum size of a sample to capture is u32 */
+	chan->scan_type.storagebits = sizeof(u32) * 8;
+	chan->scan_type.repeat = MAX_QUATERNION_COMP;
+}
+
+/* Channel read_raw handler */
+static int dev_rot_read_raw(struct iio_dev *indio_dev,
+			      struct iio_chan_spec const *chan,
+			    int size, int *vals,
+			      long mask)
+{
+	struct dev_rot_state *rot_state = iio_priv(indio_dev);
+	int ret_type;
+	int i;
+
+	vals[0] = 0;
+	vals[1] = 0;
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		if (size >= MAX_QUATERNION_COMP) {
+			for (i = 0; i < MAX_QUATERNION_COMP; ++i)
+				vals[i] = rot_state->sampled_vals[i];
+			ret_type = IIO_VAL_QUATERNION;
+		} else
+			ret_type = -EINVAL;
+		break;
+	case IIO_CHAN_INFO_SCALE:
+		vals[0] = rot_state->quaternion.units;
+		ret_type = IIO_VAL_INT;
+		break;
+	case IIO_CHAN_INFO_OFFSET:
+		vals[1] = hid_sensor_convert_exponent(
+			rot_state->quaternion.unit_expo);
+		ret_type = IIO_VAL_INT;
+		break;
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		ret_type = hid_sensor_read_samp_freq_value(
+			&rot_state->common_attributes, &vals[0], &vals[1]);
+		break;
+	case IIO_CHAN_INFO_HYSTERESIS:
+		ret_type = hid_sensor_read_raw_hyst_value(
+			&rot_state->common_attributes, &vals[0], &vals[1]);
+		break;
+	default:
+		ret_type = -EINVAL;
+		break;
+	}
+
+	return ret_type;
+}
+
+/* Channel write_raw handler */
+static int dev_rot_write_raw(struct iio_dev *indio_dev,
+			       struct iio_chan_spec const *chan,
+			       int val,
+			       int val2,
+			       long mask)
+{
+	struct dev_rot_state *rot_state = iio_priv(indio_dev);
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		ret = hid_sensor_write_samp_freq_value(
+				&rot_state->common_attributes, val, val2);
+		break;
+	case IIO_CHAN_INFO_HYSTERESIS:
+		ret = hid_sensor_write_raw_hyst_value(
+				&rot_state->common_attributes, val, val2);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+static const struct iio_info dev_rot_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw_multi = &dev_rot_read_raw,
+	.write_raw = &dev_rot_write_raw,
+};
+
+/* Function to push data to buffer */
+static void hid_sensor_push_data(struct iio_dev *indio_dev, u8 *data, int len)
+{
+	dev_dbg(&indio_dev->dev, "hid_sensor_push_data >>\n");
+	iio_push_to_buffers(indio_dev, (u8 *)data);
+	dev_dbg(&indio_dev->dev, "hid_sensor_push_data <<\n");
+
+}
+
+/* Callback handler to send event after all samples are received and captured */
+static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
+				unsigned usage_id,
+				void *priv)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(priv);
+	struct dev_rot_state *rot_state = iio_priv(indio_dev);
+
+	dev_dbg(&indio_dev->dev, "dev_rot_proc_event [%d]\n",
+				rot_state->common_attributes.data_ready);
+
+	if (rot_state->common_attributes.data_ready)
+		hid_sensor_push_data(indio_dev,
+				(u8 *)rot_state->sampled_vals,
+				sizeof(rot_state->sampled_vals));
+
+	return 0;
+}
+
+/* Capture samples in local storage */
+static int dev_rot_capture_sample(struct hid_sensor_hub_device *hsdev,
+				unsigned usage_id,
+				size_t raw_len, char *raw_data,
+				void *priv)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(priv);
+	struct dev_rot_state *rot_state = iio_priv(indio_dev);
+
+	if (usage_id == HID_USAGE_SENSOR_ORIENT_QUATERNION) {
+		memcpy(rot_state->sampled_vals, raw_data,
+					sizeof(rot_state->sampled_vals));
+		dev_dbg(&indio_dev->dev, "Recd Quat len:%lu::%lu\n", raw_len,
+					sizeof(rot_state->sampled_vals));
+	}
+
+	return 0;
+}
+
+/* Parse report which is specific to an usage id*/
+static int dev_rot_parse_report(struct platform_device *pdev,
+				struct hid_sensor_hub_device *hsdev,
+				struct iio_chan_spec *channels,
+				unsigned usage_id,
+				struct dev_rot_state *st)
+{
+	int ret;
+
+	ret = sensor_hub_input_get_attribute_info(hsdev,
+				HID_INPUT_REPORT,
+				usage_id,
+				HID_USAGE_SENSOR_ORIENT_QUATERNION,
+				&st->quaternion);
+	if (ret)
+		return ret;
+	dev_rot_adjust_channel_bit_mask(&channels[0],
+		st->quaternion.size / MAX_QUATERNION_COMP);
+
+	dev_dbg(&pdev->dev, "dev_rot %x:%x\n", st->quaternion.index,
+		st->quaternion.report_id);
+
+	dev_dbg(&pdev->dev, "dev_rot: attrib size %d\n",
+				st->quaternion.size);
+
+	/* Set Sensitivity field ids, when there is no individual modifier */
+	if (st->common_attributes.sensitivity.index < 0) {
+		sensor_hub_input_get_attribute_info(hsdev,
+			HID_FEATURE_REPORT, usage_id,
+			HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
+			HID_USAGE_SENSOR_DATA_ORIENTATION,
+			&st->common_attributes.sensitivity);
+		dev_dbg(&pdev->dev, "Sensitivity index:report %d:%d\n",
+			st->common_attributes.sensitivity.index,
+			st->common_attributes.sensitivity.report_id);
+	}
+	return 0;
+}
+
+/* Function to initialize the processing for usage id */
+static int hid_dev_rot_probe(struct platform_device *pdev)
+{
+	int ret;
+	static char *name = "dev_rotation";
+	struct iio_dev *indio_dev;
+	struct dev_rot_state *rot_state;
+	struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+	struct iio_chan_spec *channels;
+
+	indio_dev = devm_iio_device_alloc(&pdev->dev,
+					  sizeof(struct dev_rot_state));
+	if (indio_dev == NULL)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, indio_dev);
+
+	rot_state = iio_priv(indio_dev);
+	rot_state->common_attributes.hsdev = hsdev;
+	rot_state->common_attributes.pdev = pdev;
+
+	ret = hid_sensor_parse_common_attributes(hsdev,
+				HID_USAGE_SENSOR_DEVICE_ORIENTATION,
+				&rot_state->common_attributes);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to setup common attributes\n");
+		return ret;
+	}
+
+	channels = kmemdup(dev_rot_channels, sizeof(dev_rot_channels),
+			   GFP_KERNEL);
+	if (!channels) {
+		dev_err(&pdev->dev, "failed to duplicate channels\n");
+		return -ENOMEM;
+	}
+
+	ret = dev_rot_parse_report(pdev, hsdev, channels,
+			HID_USAGE_SENSOR_DEVICE_ORIENTATION, rot_state);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to setup attributes\n");
+		goto error_free_dev_mem;
+	}
+
+	indio_dev->channels = channels;
+	indio_dev->num_channels = ARRAY_SIZE(dev_rot_channels);
+	indio_dev->dev.parent = &pdev->dev;
+	indio_dev->info = &dev_rot_info;
+	indio_dev->name = name;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	ret = iio_triggered_buffer_setup(indio_dev, &iio_pollfunc_store_time,
+		NULL, NULL);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to initialize trigger buffer\n");
+		goto error_free_dev_mem;
+	}
+	rot_state->common_attributes.data_ready = false;
+	ret = hid_sensor_setup_trigger(indio_dev, name,
+					&rot_state->common_attributes);
+	if (ret) {
+		dev_err(&pdev->dev, "trigger setup failed\n");
+		goto error_unreg_buffer_funcs;
+	}
+
+	ret = iio_device_register(indio_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "device register failed\n");
+		goto error_remove_trigger;
+	}
+
+	rot_state->callbacks.send_event = dev_rot_proc_event;
+	rot_state->callbacks.capture_sample = dev_rot_capture_sample;
+	rot_state->callbacks.pdev = pdev;
+	ret = sensor_hub_register_callback(hsdev,
+					HID_USAGE_SENSOR_DEVICE_ORIENTATION,
+					&rot_state->callbacks);
+	if (ret) {
+		dev_err(&pdev->dev, "callback reg failed\n");
+		goto error_iio_unreg;
+	}
+
+	return 0;
+
+error_iio_unreg:
+	iio_device_unregister(indio_dev);
+error_remove_trigger:
+	hid_sensor_remove_trigger(&rot_state->common_attributes);
+error_unreg_buffer_funcs:
+	iio_triggered_buffer_cleanup(indio_dev);
+error_free_dev_mem:
+	kfree(indio_dev->channels);
+	return ret;
+}
+
+/* Function to deinitialize the processing for usage id */
+static int hid_dev_rot_remove(struct platform_device *pdev)
+{
+	struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+	struct dev_rot_state *rot_state = iio_priv(indio_dev);
+
+	sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_DEVICE_ORIENTATION);
+	iio_device_unregister(indio_dev);
+	hid_sensor_remove_trigger(&rot_state->common_attributes);
+	iio_triggered_buffer_cleanup(indio_dev);
+	kfree(indio_dev->channels);
+
+	return 0;
+}
+
+static struct platform_device_id hid_dev_rot_ids[] = {
+	{
+		/* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+		.name = "HID-SENSOR-20008a",
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_dev_rot_ids);
+
+static struct platform_driver hid_dev_rot_platform_driver = {
+	.id_table = hid_dev_rot_ids,
+	.driver = {
+		.name	= KBUILD_MODNAME,
+		.owner	= THIS_MODULE,
+	},
+	.probe		= hid_dev_rot_probe,
+	.remove		= hid_dev_rot_remove,
+};
+module_platform_driver(hid_dev_rot_platform_driver);
+
+MODULE_DESCRIPTION("HID Sensor Device Rotation");
+MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index a3f863d..a264ec7 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -66,6 +66,7 @@
 #define HID_USAGE_SENSOR_ORIENT_TILT_Y				0x200480
 #define HID_USAGE_SENSOR_ORIENT_TILT_Z				0x200481
 
+#define HID_USAGE_SENSOR_DEVICE_ORIENTATION			0x20008A
 #define HID_USAGE_SENSOR_ORIENT_ROTATION_MATRIX			0x200482
 #define HID_USAGE_SENSOR_ORIENT_QUATERNION			0x200483
 #define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX			0x200484
-- 
1.8.3.2

Re: [PATCH 1/4] IIO: core: Introduce read_raw_multi

[Jonathan Cameron]

On 20/01/14 05:02, Srinivas Pandruvada wrote:
> This callback is introduced to overcome some limitations of existing
> read_raw callback. The functionality of both existing read_raw and
> read_raw_multi is similar, both are used to request values from the
> device. The current read_raw callback allows only two return values.
> The new read_raw_multi allows returning multiple values. Instead of
> passing just address of val and val2, it passes length and pointer
> to values. Depending on the type and length of passed buffer, iio
> client drivers can return multiple values.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
I am fairly happy with this set, but would like to get a few more opinions
before taking this new chunk of ABI into the subsystem.

Peter made the point that there were other cases (RGB colour sensors,
where perhaps such a multi component type makes sense) and as such we
may have some redundancy.  I agree that this is a possible issue but
in the case of quaternion rotations the components have no meaning whatsoever
on their own under any circumstances. As such supporting them as single
components is a non starter to my mind.

The other option Peter raised was to only allow such compound types via
the buffered interface.  This would certainly be an option as then we could
use available channel masks to ensure that all or none of hte elements are
present.

I think I prefer the approach taken here as it still allows for 'what is my
current orientation' type polled queries via sysfs.

Anyhow, I've cc'd everyone I could immediately think of who might have an
opinion and / or has some involvement with inertial sensors that 'might'
use this functionality at some point.

Jonathan

p.s You will probably want to read the whole series if you haven't seen this
before.

> ---
>   drivers/iio/iio_core.h           |  2 +-
>   drivers/iio/industrialio-core.c  | 51 +++++++++++++++++++++++-----------------
>   drivers/iio/industrialio-event.c |  6 +++--
>   drivers/iio/inkern.c             | 15 ++++++++++--
>   include/linux/iio/iio.h          | 16 +++++++++++++
>   5 files changed, 63 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> index f6db6af..4172f22 100644
> --- a/drivers/iio/iio_core.h
> +++ b/drivers/iio/iio_core.h
> @@ -35,7 +35,7 @@ int __iio_add_chan_devattr(const char *postfix,
>   			   struct list_head *attr_list);
>   void iio_free_chan_devattr_list(struct list_head *attr_list);
>
> -ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2);
> +ssize_t iio_format_value(char *buf, unsigned int type, int *val);
>
>   /* Event interface flags */
>   #define IIO_BUSY_BIT_POS 1
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 18f72e3..f8b730a 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -367,41 +367,42 @@ EXPORT_SYMBOL_GPL(iio_enum_write);
>    * @buf: The buffer to which the formated value gets written
>    * @type: One of the IIO_VAL_... constants. This decides how the val and val2
>    *        parameters are formatted.
> - * @val: First part of the value, exact meaning depends on the type parameter.
> - * @val2: Second part of the value, exact meaning depends on the type parameter.
> + * @vals: pointer to the values, exact meaning depends on the type parameter.
>    */
> -ssize_t iio_format_value(char *buf, unsigned int type, int val, int val2)
> +ssize_t iio_format_value(char *buf, unsigned int type, int *vals)
>   {
>   	unsigned long long tmp;
>   	bool scale_db = false;
>
>   	switch (type) {
>   	case IIO_VAL_INT:
> -		return sprintf(buf, "%d\n", val);
> +		return sprintf(buf, "%d\n", vals[0]);
>   	case IIO_VAL_INT_PLUS_MICRO_DB:
>   		scale_db = true;
>   	case IIO_VAL_INT_PLUS_MICRO:
> -		if (val2 < 0)
> -			return sprintf(buf, "-%ld.%06u%s\n", abs(val), -val2,
> +		if (vals[1] < 0)
> +			return sprintf(buf, "-%ld.%06u%s\n", abs(vals[0]),
> +					-vals[1],
>   				scale_db ? " dB" : "");
>   		else
> -			return sprintf(buf, "%d.%06u%s\n", val, val2,
> +			return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
>   				scale_db ? " dB" : "");
>   	case IIO_VAL_INT_PLUS_NANO:
> -		if (val2 < 0)
> -			return sprintf(buf, "-%ld.%09u\n", abs(val), -val2);
> +		if (vals[1] < 0)
> +			return sprintf(buf, "-%ld.%09u\n", abs(vals[0]),
> +					-vals[1]);
>   		else
> -			return sprintf(buf, "%d.%09u\n", val, val2);
> +			return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>   	case IIO_VAL_FRACTIONAL:
> -		tmp = div_s64((s64)val * 1000000000LL, val2);
> -		val2 = do_div(tmp, 1000000000LL);
> -		val = tmp;
> -		return sprintf(buf, "%d.%09u\n", val, val2);
> +		tmp = div_s64((s64)vals[0] * 1000000000LL, vals[1]);
> +		vals[1] = do_div(tmp, 1000000000LL);
> +		vals[0] = tmp;
> +		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>   	case IIO_VAL_FRACTIONAL_LOG2:
> -		tmp = (s64)val * 1000000000LL >> val2;
> -		val2 = do_div(tmp, 1000000000LL);
> -		val = tmp;
> -		return sprintf(buf, "%d.%09u\n", val, val2);
> +		tmp = (s64)vals[0] * 1000000000LL >> vals[1];
> +		vals[1] = do_div(tmp, 1000000000LL);
> +		vals[0] = tmp;
> +		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>   	default:
>   		return 0;
>   	}
> @@ -413,14 +414,20 @@ static ssize_t iio_read_channel_info(struct device *dev,
>   {
>   	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>   	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> -	int val, val2;
> -	int ret = indio_dev->info->read_raw(indio_dev, this_attr->c,
> -					    &val, &val2, this_attr->address);
> +	int vals[INDIO_MAX_RAW_ELEMENTS];
> +	int ret;
> +
> +	if (indio_dev->info->read_raw_multi)
> +		ret = indio_dev->info->read_raw_multi(indio_dev, this_attr->c,
> +			    INDIO_MAX_RAW_ELEMENTS, vals, this_attr->address);
> +	else
> +		ret = indio_dev->info->read_raw(indio_dev, this_attr->c,
> +				    &vals[0], &vals[1], this_attr->address);
>
>   	if (ret < 0)
>   		return ret;
>
> -	return iio_format_value(buf, ret, val, val2);
> +	return iio_format_value(buf, ret, vals);
>   }
>
>   /**
> diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-event.c
> index c10eab6..b249b48 100644
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -274,7 +274,7 @@ static ssize_t iio_ev_value_show(struct device *dev,
>   {
>   	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>   	struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> -	int val, val2;
> +	int val, val2, val_arr[2];
>   	int ret;
>
>   	if (indio_dev->info->read_event_value) {
> @@ -290,7 +290,9 @@ static ssize_t iio_ev_value_show(struct device *dev,
>   			&val, &val2);
>   		if (ret < 0)
>   			return ret;
> -		return iio_format_value(buf, ret, val, val2);
> +		val_arr[0] = val;
> +		val_arr[1] = val2;
> +		return iio_format_value(buf, ret, val_arr);
>   	}
>   }
>
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index 0cf5f8e..6a93d57 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -417,12 +417,23 @@ static int iio_channel_read(struct iio_channel *chan, int *val, int *val2,
>   	enum iio_chan_info_enum info)
>   {
>   	int unused;
> +	int vals[INDIO_MAX_RAW_ELEMENTS];
> +	int ret;
>
>   	if (val2 == NULL)
>   		val2 = &unused;
>
> -	return chan->indio_dev->info->read_raw(chan->indio_dev, chan->channel,
> -						val, val2, info);
> +	if (chan->indio_dev->info->read_raw_multi) {
> +		ret = chan->indio_dev->info->read_raw_multi(chan->indio_dev,
> +					chan->channel, INDIO_MAX_RAW_ELEMENTS,
> +					vals, info);
> +		*val = vals[0];
> +		*val2 = vals[1];
> +	} else
> +		ret = chan->indio_dev->info->read_raw(chan->indio_dev,
> +					chan->channel, val, val2, info);
> +
> +	return ret;
>   }
>
>   int iio_read_channel_raw(struct iio_channel *chan, int *val)
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index 256a90a..7f76a45 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -286,6 +286,8 @@ static inline s64 iio_get_time_ns(void)
>   #define INDIO_ALL_BUFFER_MODES					\
>   	(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE)
>
> +#define INDIO_MAX_RAW_ELEMENTS		4
> +
>   struct iio_trigger; /* forward declaration */
>   struct iio_dev;
>
> @@ -300,6 +302,14 @@ struct iio_dev;
>    *			the channel in question.  Return value will specify the
>    *			type of value returned by the device. val and val2 will
>    *			contain the elements making up the returned value.
> + * @read_raw_multi:	function to return values from the device.
> + *			mask specifies which value. Note 0 means a reading of
> + *			the channel in question.  Return value will specify the
> + *			type of value returned by the device. vals pointer
> + *			contain the elements making up the returned value.
> + *			val_len specifies maximum number of elements
> + *			vals pointer can contain. In contrast to to read_raw
> + *			device can return multiple values not just two.
>    * @write_raw:		function to write a value to the device.
>    *			Parameters are the same as for read_raw.
>    * @write_raw_get_fmt:	callback function to query the expected
> @@ -334,6 +344,12 @@ struct iio_info {
>   			int *val2,
>   			long mask);
>
> +	int (*read_raw_multi)(struct iio_dev *indio_dev,
> +			struct iio_chan_spec const *chan,
> +			int val_len,
> +			int *vals,
> +			long mask);
> +
>   	int (*write_raw)(struct iio_dev *indio_dev,
>   			 struct iio_chan_spec const *chan,
>   			 int val,
>

Re: [PATCH 3/4] IIO: core: Introduce Quaternion types

[Jonathan Cameron]

On 20/01/14 05:02, Srinivas Pandruvada wrote:
> Introduced IIO_VAL_QUATERNION and its formatting. Format used here:
> x:y:z:w
> In addition IIO_QUAT_ROT is added to the channel type and name.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Since reviewing the interface for the ecap driver the other day I've been
wondering if a new channel is the right approach here. In that driver
I pointed out that modifiers can result in different units for the output.
I'm not sure we want to do that in general, but perhaps here it makes
sense?

So we would have a quaternion modifier (treating it the same as an axis)
giving us attributes like

in_rot_quaternion_raw

etc.

Would this be prefereable to the approach here of having new channel type
to cover it?  That is do we want the channel type to always specify the
representation, or do we allow it to be done through the modifier?
We have let in relativehumidity as a type which arguably could
have been humidity and a relative modifier.  Perhaps we are better just
going with these compound types.  They don't really restrict us, but just
feel a little untidy.

Also, Srinivas - whatever we end up with needs documenting in
Documentation/ABI/testing/sysfs-bus-iio

Whilst looking at this I notice we confusingly have both rot and angl
channel types. Are they actually different?  Conceptually devices tend
to be thought of as measuring one or the other - so you'd probably
never describe an inclinometer as measuring rotation.  Hmm.. As it is now been
in the ABI for some time we are pretty much stuck with this.
> ---
>   drivers/iio/industrialio-core.c | 4 ++++
>   include/linux/iio/types.h       | 3 +++
>   2 files changed, 7 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index f8b730a..267b0a0 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -69,6 +69,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   	[IIO_ALTVOLTAGE] = "altvoltage",
>   	[IIO_CCT] = "cct",
>   	[IIO_PRESSURE] = "pressure",
> +	[IIO_QUAT_ROT] = "rotquaternion",
>   };
>
>   static const char * const iio_modifier_names[] = {
> @@ -403,6 +404,9 @@ ssize_t iio_format_value(char *buf, unsigned int type, int *vals)
>   		vals[1] = do_div(tmp, 1000000000LL);
>   		vals[0] = tmp;
>   		return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
> +	case IIO_VAL_QUATERNION:
> +		return sprintf(buf, "%d:%d:%d:%d\n", vals[0], vals[1], vals[2],
> +							vals[3]);
>   	default:
>   		return 0;
>   	}
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 4ac928e..878db0e 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -29,6 +29,7 @@ enum iio_chan_type {
>   	IIO_ALTVOLTAGE,
>   	IIO_CCT,
>   	IIO_PRESSURE,
> +	IIO_QUAT_ROT,
>   };
>
>   enum iio_modifier {
> @@ -52,6 +53,7 @@ enum iio_modifier {
>   	IIO_MOD_LIGHT_RED,
>   	IIO_MOD_LIGHT_GREEN,
>   	IIO_MOD_LIGHT_BLUE,
> +	IIO_MOD_QUATERNION,
>   };
>
>   enum iio_event_type {
> @@ -78,6 +80,7 @@ enum iio_event_direction {
>   #define IIO_VAL_INT_PLUS_MICRO 2
>   #define IIO_VAL_INT_PLUS_NANO 3
>   #define IIO_VAL_INT_PLUS_MICRO_DB 4
> +#define IIO_VAL_QUATERNION 5
>   #define IIO_VAL_FRACTIONAL 10
>   #define IIO_VAL_FRACTIONAL_LOG2 11
>
>

Re: [PATCH 3/4] IIO: core: Introduce Quaternion types

[Srinivas Pandruvada]

On 02/18/2014 12:29 AM, Jonathan Cameron wrote:
> On 20/01/14 05:02, Srinivas Pandruvada wrote:
>> Introduced IIO_VAL_QUATERNION and its formatting. Format used here:
>> x:y:z:w
>> In addition IIO_QUAT_ROT is added to the channel type and name.
>>
>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Since reviewing the interface for the ecap driver the other day I've been
> wondering if a new channel is the right approach here. In that driver
> I pointed out that modifiers can result in different units for the output.
> I'm not sure we want to do that in general, but perhaps here it makes
> sense?
>
> So we would have a quaternion modifier (treating it the same as an axis)
> giving us attributes like
>
> in_rot_quaternion_raw
>
> etc.
>
This is what it looks now, with new set of patches:
iio:deviceX/
├── buffer
│   ├── enable
│   └── length
..
├── in_rotquaternion_raw
├── name
├── scan_elements
│   ├── in_rotquaternion_en
│   ├── in_rotquaternion_index
│   └── in_rotquaternion_type
├── trigger
│   └── current_trigger

This is what you prefer?



> Would this be prefereable to the approach here of having new channel type
> to cover it?  That is do we want the channel type to always specify the
> representation, or do we allow it to be done through the modifier?
> We have let in relativehumidity as a type which arguably could
> have been humidity and a relative modifier.  Perhaps we are better just
> going with these compound types.  They don't really restrict us, but just
> feel a little untidy.
>
> Also, Srinivas - whatever we end up with needs documenting in
> Documentation/ABI/testing/sysfs-bus-iio

Submitted a new series with this patch

Thanks,
Srinivas



> Whilst looking at this I notice we confusingly have both rot and angl
> channel types. Are they actually different?  Conceptually devices tend
> to be thought of as measuring one or the other - so you'd probably
> never describe an inclinometer as measuring rotation.  Hmm.. As it is
> now been
> in the ABI for some time we are pretty much stuck with this.
>> ---
>>   drivers/iio/industrialio-core.c | 4 ++++
>>   include/linux/iio/types.h       | 3 +++
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-core.c
>> b/drivers/iio/industrialio-core.c
>> index f8b730a..267b0a0 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -69,6 +69,7 @@ static const char * const iio_chan_type_name_spec[] = {
>>       [IIO_ALTVOLTAGE] = "altvoltage",
>>       [IIO_CCT] = "cct",
>>       [IIO_PRESSURE] = "pressure",
>> +    [IIO_QUAT_ROT] = "rotquaternion",
>>   };
>>
>>   static const char * const iio_modifier_names[] = {
>> @@ -403,6 +404,9 @@ ssize_t iio_format_value(char *buf, unsigned int
>> type, int *vals)
>>           vals[1] = do_div(tmp, 1000000000LL);
>>           vals[0] = tmp;
>>           return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>> +    case IIO_VAL_QUATERNION:
>> +        return sprintf(buf, "%d:%d:%d:%d\n", vals[0], vals[1], vals[2],
>> +                            vals[3]);
>>       default:
>>           return 0;
>>       }
>> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
>> index 4ac928e..878db0e 100644
>> --- a/include/linux/iio/types.h
>> +++ b/include/linux/iio/types.h
>> @@ -29,6 +29,7 @@ enum iio_chan_type {
>>       IIO_ALTVOLTAGE,
>>       IIO_CCT,
>>       IIO_PRESSURE,
>> +    IIO_QUAT_ROT,
>>   };
>>
>>   enum iio_modifier {
>> @@ -52,6 +53,7 @@ enum iio_modifier {
>>       IIO_MOD_LIGHT_RED,
>>       IIO_MOD_LIGHT_GREEN,
>>       IIO_MOD_LIGHT_BLUE,
>> +    IIO_MOD_QUATERNION,
>>   };
>>
>>   enum iio_event_type {
>> @@ -78,6 +80,7 @@ enum iio_event_direction {
>>   #define IIO_VAL_INT_PLUS_MICRO 2
>>   #define IIO_VAL_INT_PLUS_NANO 3
>>   #define IIO_VAL_INT_PLUS_MICRO_DB 4
>> +#define IIO_VAL_QUATERNION 5
>>   #define IIO_VAL_FRACTIONAL 10
>>   #define IIO_VAL_FRACTIONAL_LOG2 11
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 3/4] IIO: core: Introduce Quaternion types

[Jonathan Cameron]

On 23/02/14 19:57, Srinivas Pandruvada wrote:
>
>
> On 02/18/2014 12:29 AM, Jonathan Cameron wrote:
>> On 20/01/14 05:02, Srinivas Pandruvada wrote:
>>> Introduced IIO_VAL_QUATERNION and its formatting. Format used here:
>>> x:y:z:w
>>> In addition IIO_QUAT_ROT is added to the channel type and name.
>>>
>>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>> Since reviewing the interface for the ecap driver the other day I've been
>> wondering if a new channel is the right approach here. In that driver
>> I pointed out that modifiers can result in different units for the output.
>> I'm not sure we want to do that in general, but perhaps here it makes
>> sense?
>>
>> So we would have a quaternion modifier (treating it the same as an axis)
>> giving us attributes like
>>
>> in_rot_quaternion_raw
>>
>> etc.
>>
> This is what it looks now, with new set of patches:
> iio:deviceX/
> ├── buffer
> │   ├── enable
> │   └── length
> ..
> ├── in_rotquaternion_raw
> ├── name
> ├── scan_elements
> │   ├── in_rotquaternion_en
> │   ├── in_rotquaternion_index
> │   └── in_rotquaternion_type
> ├── trigger
> │   └── current_trigger
>
> This is what you prefer?
I was suggesting in this email that we consider using a modifier to specify the
quaternion bit (much like x, y, z for axes).  I'm still a bit in two minds
about this so was hoping to start a bit more of a discussion about it!

Right now I think I slighly prefer the approach you have taken here as it
avoids some confusion.  Having said that I'll probably need to rethink my
response to the ecap driver as the interfaces of these two are in some ways
raising the same sorts of questions!

Thanks and sorry for delaying the merging of these patchs.

Good to get the Docs in there though.  I should have picked up on that earlier.

Jonathan
>
>
>
>> Would this be prefereable to the approach here of having new channel type
>> to cover it?  That is do we want the channel type to always specify the
>> representation, or do we allow it to be done through the modifier?
>> We have let in relativehumidity as a type which arguably could
>> have been humidity and a relative modifier.  Perhaps we are better just
>> going with these compound types.  They don't really restrict us, but just
>> feel a little untidy.
>>
>> Also, Srinivas - whatever we end up with needs documenting in
>> Documentation/ABI/testing/sysfs-bus-iio
>
> Submitted a new series with this patch
>
> Thanks,
> Srinivas
>
>
>
>> Whilst looking at this I notice we confusingly have both rot and angl
>> channel types. Are they actually different?  Conceptually devices tend
>> to be thought of as measuring one or the other - so you'd probably
>> never describe an inclinometer as measuring rotation.  Hmm.. As it is
>> now been
>> in the ABI for some time we are pretty much stuck with this.
>>> ---
>>>   drivers/iio/industrialio-core.c | 4 ++++
>>>   include/linux/iio/types.h       | 3 +++
>>>   2 files changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/iio/industrialio-core.c
>>> b/drivers/iio/industrialio-core.c
>>> index f8b730a..267b0a0 100644
>>> --- a/drivers/iio/industrialio-core.c
>>> +++ b/drivers/iio/industrialio-core.c
>>> @@ -69,6 +69,7 @@ static const char * const iio_chan_type_name_spec[] = {
>>>       [IIO_ALTVOLTAGE] = "altvoltage",
>>>       [IIO_CCT] = "cct",
>>>       [IIO_PRESSURE] = "pressure",
>>> +    [IIO_QUAT_ROT] = "rotquaternion",
>>>   };
>>>
>>>   static const char * const iio_modifier_names[] = {
>>> @@ -403,6 +404,9 @@ ssize_t iio_format_value(char *buf, unsigned int
>>> type, int *vals)
>>>           vals[1] = do_div(tmp, 1000000000LL);
>>>           vals[0] = tmp;
>>>           return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>>> +    case IIO_VAL_QUATERNION:
>>> +        return sprintf(buf, "%d:%d:%d:%d\n", vals[0], vals[1], vals[2],
>>> +                            vals[3]);
>>>       default:
>>>           return 0;
>>>       }
>>> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
>>> index 4ac928e..878db0e 100644
>>> --- a/include/linux/iio/types.h
>>> +++ b/include/linux/iio/types.h
>>> @@ -29,6 +29,7 @@ enum iio_chan_type {
>>>       IIO_ALTVOLTAGE,
>>>       IIO_CCT,
>>>       IIO_PRESSURE,
>>> +    IIO_QUAT_ROT,
>>>   };
>>>
>>>   enum iio_modifier {
>>> @@ -52,6 +53,7 @@ enum iio_modifier {
>>>       IIO_MOD_LIGHT_RED,
>>>       IIO_MOD_LIGHT_GREEN,
>>>       IIO_MOD_LIGHT_BLUE,
>>> +    IIO_MOD_QUATERNION,
>>>   };
>>>
>>>   enum iio_event_type {
>>> @@ -78,6 +80,7 @@ enum iio_event_direction {
>>>   #define IIO_VAL_INT_PLUS_MICRO 2
>>>   #define IIO_VAL_INT_PLUS_NANO 3
>>>   #define IIO_VAL_INT_PLUS_MICRO_DB 4
>>> +#define IIO_VAL_QUATERNION 5
>>>   #define IIO_VAL_FRACTIONAL 10
>>>   #define IIO_VAL_FRACTIONAL_LOG2 11
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html