All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] iio: accel: BMC150 accel support
@ 2014-06-20 18:12 Srinivas Pandruvada
  2014-06-22 14:23 ` Jonathan Cameron
  2014-06-29 20:43 ` Peter Meerwald
  0 siblings, 2 replies; 12+ messages in thread
From: Srinivas Pandruvada @ 2014-06-20 18:12 UTC (permalink / raw)
  To: jic23; +Cc: linux-iio, Srinivas Pandruvada

This change implements BMC150 accelerometer driver. A BMC150 package
consist of a compass and an accelerometer. This driver only implements
accelerometer part.
Spec downloaded from:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf

This sensor chip supports many advanced features, but this driver
implements minimum feature set which is a must to be useful.
This driver can be enhanced incrementally.
If the sensor vendor wants to update full featured version, they
can substitute or enhance this driver when they get chance.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 drivers/iio/accel/Kconfig        |  13 +
 drivers/iio/accel/Makefile       |   1 +
 drivers/iio/accel/bmc150-accel.c | 947 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 961 insertions(+)
 create mode 100644 drivers/iio/accel/bmc150-accel.c

diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 12addf2..5704d6b 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -17,6 +17,19 @@ config BMA180
 	  To compile this driver as a module, choose M here: the
 	  module will be called bma180.
 
+config BMC150_ACCEL
+	tristate "Bosch BMC150 Accelerometer Driver"
+	depends on I2C
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
+	help
+	  Say yes here to build support for the Bosch BMC150 accelerometer.
+	  Currently this only supports the device via an i2c interface.
+
+	  This is a combo module with both accelerometer and magnetometer.
+	  This driver is only implementing accelerometer part, which has
+	  its own address and register map.
+
 config HID_SENSOR_ACCEL_3D
 	depends on HID_SENSOR_HUB
 	select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 6578ca1..a593996 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -4,6 +4,7 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_BMA180) += bma180.o
+obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
 obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
 obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
 obj-$(CONFIG_KXSD9)	+= kxsd9.o
diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
new file mode 100644
index 0000000..330a3d7
--- /dev/null
+++ b/drivers/iio/accel/bmc150-accel.c
@@ -0,0 +1,947 @@
+/*
+ * BMC150 3-axis accelerometer 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/module.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/acpi.h>
+#include <linux/gpio/consumer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+
+#define BMC150_ACCEL_DRV_NAME			"bmc150_accel"
+#define BMC150_ACCEL_IRQ_NAME			"bmc150_accel_event"
+
+#define BMC150_ACCEL_REG_CHIP_ID		0x00
+#define BMC150_ACCEL_CHIP_ID_VAL		0xFA
+
+#define BMC150_ACCEL_REG_PMU_LPW		0x11
+#define BMC150_ACCEL_PMU_SLP_MASK		0xE0
+#define BMC150_ACCEL_PMU_SLP_SHIFT		5
+#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK	0x17
+#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT	1
+
+#define BMC150_ACCEL_REG_PMU_RANGE		0x0F
+
+#define BMC150_ACCEL_DEF_RANGE_2G		0x03
+#define BMC150_ACCEL_DEF_RANGE_4G		0x05
+#define BMC150_ACCEL_DEF_RANGE_8G		0x08
+#define BMC150_ACCEL_DEF_RANGE_16G		0x0C
+
+/* Default BW: 125Hz */
+#define BMC150_ACCEL_REG_PMU_BW			0x10
+#define BMC150_ACCEL_DEF_BW			125
+
+#define BMC150_ACCEL_REG_INT_MAP_0		0x19
+#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE	BIT(2)
+
+#define BMC150_ACCEL_REG_INT_RST_LATCH		0x21
+#define BMC150_ACCEL_INT_MODE_LATCH_RESET	0x80
+#define BMC150_ACCEL_INT_MODE_LATCH_INT		0x0F
+
+#define BMC150_ACCEL_REG_INT_EN_0		0x16
+#define BMC150_ACCEL_INT_EN_BIT_SLP_X		BIT(0)
+#define BMC150_ACCEL_INT_EN_BIT_SLP_Y		BIT(1)
+#define BMC150_ACCEL_INT_EN_BIT_SLP_Z		BIT(2)
+
+#define BMC150_ACCEL_REG_INT_OUT_CTRL		0x20
+#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL	BIT(0)
+
+#define BMC150_ACCEL_REG_INT_5			0x27
+#define BMC150_ACCEL_SLOPE_DUR_MASK		0x03
+
+#define BMC150_ACCEL_REG_INT_6			0x28
+#define BMC150_ACCEL_SLOPE_THRES_MASK		0xFF
+
+#define BMC150_ACCEL_REG_XOUT_L			0x02
+#define BMC150_ACCEL_REG_XOUT_H			0x03
+#define BMC150_ACCEL_REG_YOUT_L			0x04
+#define BMC150_ACCEL_REG_YOUT_H			0x05
+#define BMC150_ACCEL_REG_ZOUT_L			0x06
+#define BMC150_ACCEL_REG_ZOUT_H			0x07
+
+#define BMC150_ACCEL_MAX_STARTUP_TIME_MS	100
+
+/* Slope duration in terms of number of samples */
+#define BMC150_ACCEL_DEF_SLOPE_DURATION		2
+/* in terms of multiples of g's/LSB, based on range */
+#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD	5
+
+/* Sleep Duration values */
+#define BMC150_ACCEL_SLEEP_500_MICRO		0x05
+#define BMC150_ACCEL_SLEEP_1_MS			0x06
+#define BMC150_ACCEL_SLEEP_2_MS			0x07
+#define BMC150_ACCEL_SLEEP_4_MS			0x08
+#define BMC150_ACCEL_SLEEP_6_MS			0x09
+#define BMC150_ACCEL_SLEEP_10_MS		0x0A
+#define BMC150_ACCEL_SLEEP_25_MS		0x0B
+#define BMC150_ACCEL_SLEEP_50_MS		0x0C
+#define BMC150_ACCEL_SLEEP_100_MS		0x0D
+#define BMC150_ACCEL_SLEEP_500_MS		0x0E
+#define BMC150_ACCEL_SLEEP_1_SEC		0x0F
+
+/* Sleep Modes */
+#define BMC150_ACCEL_SLEEP_MODE_NORMAL		0x00
+#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND	0x01
+#define BMC150_ACCEL_SLEEP_MODE_LPM		0x03
+#define BMC150_ACCEL_SLEEP_MODE_SUSPEND		0x04
+
+struct bmc150_accel_data {
+	struct i2c_client *client;
+	struct iio_trigger *trig;
+	bool	trig_mode;
+	struct mutex mutex;
+	s16 buffer[3];
+	int power_state;
+	u8 bw_bits;
+	u32 slope_dur;
+	u32 slope_thres;
+	u32 range;
+};
+
+enum bmc150_accel_axis {
+	AXIS_X,
+	AXIS_Y,
+	AXIS_Z,
+};
+
+static const struct {
+	int val;
+	int val2;
+	int bw_bits;
+} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 0x09},
+				     {31, 250000, 0x0A}, {62, 500000, 0x0B},
+				     {125, 0, 0x0C}, {250, 0, 0x0D},
+				     {500, 0, 0x0E}, {1000, 0, 0x0F} };
+
+static const struct {
+	int bw_bits;
+	int msec;
+} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 16},
+				     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
+				     {0x0E, 1}, {0x0F, 1} };
+
+static const struct {
+	int scale;
+	int range;
+} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
+				 {19122, BMC150_ACCEL_DEF_RANGE_4G},
+				 {38344, BMC150_ACCEL_DEF_RANGE_8G},
+				 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
+
+
+static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
+{
+	int ret;
+
+	switch (sleep_dur_us) {
+	case 0:
+		ret = 0;
+		break;
+	case 500:
+		ret = BMC150_ACCEL_SLEEP_500_MICRO;
+		break;
+	case 1000:
+		ret = BMC150_ACCEL_SLEEP_1_MS;
+		break;
+	case 2000:
+		ret = BMC150_ACCEL_SLEEP_2_MS;
+		break;
+	case 4000:
+		ret = BMC150_ACCEL_SLEEP_4_MS;
+		break;
+	case 6000:
+		ret = BMC150_ACCEL_SLEEP_6_MS;
+		break;
+	case 10000:
+		ret = BMC150_ACCEL_SLEEP_10_MS;
+		break;
+	case 25000:
+		ret = BMC150_ACCEL_SLEEP_25_MS;
+		break;
+	case 50000:
+		ret = BMC150_ACCEL_SLEEP_50_MS;
+		break;
+	case 100000:
+		ret = BMC150_ACCEL_SLEEP_100_MS;
+		break;
+	case 500000:
+		ret = BMC150_ACCEL_SLEEP_500_MS;
+		break;
+	case 1000000:
+		ret = BMC150_ACCEL_SLEEP_1_SEC;
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int mode,
+				 int dur_us)
+{
+	int ret;
+	u8 lpw_bits = 0;
+	int dur;
+
+	dur = bmc150_accel_convert_sleep_value(dur_us);
+	if (dur < 0)
+		return dur;
+
+	lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
+	lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
+
+	dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
+
+	ret = i2c_smbus_write_byte_data(data->client,
+					BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int bmc150_accel_convert_freq_to_bit(int val)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
+		if (bmc150_accel_samp_freq_table[i].val == val)
+			return bmc150_accel_samp_freq_table[i].bw_bits;
+	}
+
+	return -EINVAL;
+}
+
+static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val)
+{
+	int ret;
+	int bw_bits;
+
+	bw_bits = bmc150_accel_convert_freq_to_bit(val);
+	if (bw_bits < 0)
+		return bw_bits;
+
+	ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_PMU_BW,
+					bw_bits);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error writing pmu_bw\n");
+		return ret;
+	}
+
+	data->bw_bits = bw_bits;
+
+	return 0;
+}
+
+static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
+{
+	int ret;
+
+	ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_CHIP_ID);
+	if (ret < 0) {
+		dev_err(&data->client->dev,
+			"Error:BMC150_ACCEL_REG_CHIP_ID\n");
+		return ret;
+	}
+
+	dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
+	if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
+		dev_err(&data->client->dev, "invalid chip %x\n", ret);
+		return -ENODEV;
+	}
+
+	/* Set Bandwidth */
+	ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
+	if (ret < 0)
+		return ret;
+
+	/* Set Default Range */
+	ret = i2c_smbus_write_byte_data(data->client,
+					BMC150_ACCEL_REG_PMU_RANGE,
+					BMC150_ACCEL_DEF_RANGE_4G);
+	if (ret < 0) {
+		dev_err(&data->client->dev,
+					"Error writing pmu_range\n");
+		return ret;
+	}
+	data->range = BMC150_ACCEL_DEF_RANGE_4G;
+
+	data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
+	data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
+
+	ret = bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
+
+	return ret;
+}
+
+static int bmc150_accel_chip_setup_interrupt(struct bmc150_accel_data *data,
+					  bool status)
+{
+	int ret;
+
+	/* Enable/Disable INT1 mapping */
+	ret = i2c_smbus_read_byte_data(data->client,
+				       BMC150_ACCEL_REG_INT_MAP_0);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error read reg_int_map0\n");
+		return ret;
+	}
+	if (status)
+		ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
+	else
+		ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
+
+
+	ret = i2c_smbus_write_byte_data(data->client,
+					BMC150_ACCEL_REG_INT_MAP_0,
+					ret);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error write reg_int_map0\n");
+		return ret;
+	}
+
+	/* Set latched mode interrupt and clear any latched interrupt */
+	ret = i2c_smbus_write_byte_data(data->client,
+					BMC150_ACCEL_REG_INT_RST_LATCH,
+					BMC150_ACCEL_INT_MODE_LATCH_INT |
+					BMC150_ACCEL_INT_MODE_LATCH_RESET);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error write reg_rst_latch\n");
+		return ret;
+	}
+
+	/* Enable/Disable slope interrupts */
+	if (status) {
+		/* Set slope duration (no of samples) */
+		ret = i2c_smbus_write_byte_data(data->client,
+						BMC150_ACCEL_REG_INT_5,
+						data->slope_dur);
+		if (ret < 0) {
+			dev_err(&data->client->dev, "Error write eg_int_5\n");
+			return ret;
+		}
+
+		/* Set slope thresholds */
+		ret = i2c_smbus_write_byte_data(data->client,
+						BMC150_ACCEL_REG_INT_6,
+						data->slope_thres);
+		if (ret < 0) {
+			dev_err(&data->client->dev, "Error write reg_int_6\n");
+			return ret;
+		}
+
+		ret = i2c_smbus_write_byte_data(data->client,
+						BMC150_ACCEL_REG_INT_EN_0,
+						BMC150_ACCEL_INT_EN_BIT_SLP_X |
+						BMC150_ACCEL_INT_EN_BIT_SLP_Y |
+						BMC150_ACCEL_INT_EN_BIT_SLP_Z);
+		if (ret < 0) {
+			dev_err(&data->client->dev, "Error wr reg_int_en0\n");
+			return ret;
+		}
+
+	} else
+		ret = i2c_smbus_write_byte_data(data->client,
+						BMC150_ACCEL_REG_INT_EN_0,
+						0);
+
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error writing reg_int_en0\n");
+		return ret;
+	}
+
+	return ret;
+}
+
+static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
+{
+	int ret;
+
+	/* Set latched mode interrupt and clear any latched interrupt */
+	ret = i2c_smbus_write_byte_data(data->client,
+					BMC150_ACCEL_REG_INT_RST_LATCH,
+					BMC150_ACCEL_INT_MODE_LATCH_INT |
+					BMC150_ACCEL_INT_MODE_LATCH_RESET);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
+		return ret;
+	}
+
+
+	return ret;
+}
+
+static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int *val,
+			       int *val2)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
+		if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
+			*val = bmc150_accel_samp_freq_table[i].val;
+			*val2 = bmc150_accel_samp_freq_table[i].val2;
+			return IIO_VAL_INT_PLUS_MICRO;
+		}
+	}
+
+	return -EINVAL;
+}
+
+static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, int axis)
+{
+	u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
+	int ret;
+
+	ret = i2c_smbus_read_word_data(data->client, reg);
+	if (ret < 0) {
+		dev_err(&data->client->dev,
+			"failed to read accel_%c registers\n", 'x' + axis);
+		return ret;
+	}
+
+	return ret;
+}
+
+static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
+		if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
+			return bmc150_accel_sample_upd_time[i].msec;
+
+	}
+
+	return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
+}
+
+static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
+{
+	int ret, i;
+
+	for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
+		if (bmc150_accel_scale_table[i].scale == val) {
+			ret = i2c_smbus_write_byte_data(
+					data->client,
+					BMC150_ACCEL_REG_PMU_RANGE,
+					bmc150_accel_scale_table[i].range);
+			if (ret < 0) {
+				dev_err(&data->client->dev,
+					"Error writing pmu_range\n");
+				return ret;
+			}
+			data->range = bmc150_accel_scale_table[i].range;
+			return 0;
+		}
+	}
+
+	return -EINVAL;
+}
+
+static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
+				 struct iio_chan_spec const *chan,
+				 int *val, int *val2, long mask)
+{
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&data->mutex);
+		if (iio_buffer_enabled(indio_dev))
+			ret = -EBUSY;
+		else {
+			int sleep_val;
+			if (!data->power_state) {
+				ret = bmc150_accel_set_mode(data,
+						BMC150_ACCEL_SLEEP_MODE_NORMAL,
+						0);
+				if (ret < 0) {
+					mutex_unlock(&data->mutex);
+					return ret;
+				}
+				sleep_val =
+					bmc150_accel_get_startup_times(data);
+				if (sleep_val < 20)
+					usleep_range(sleep_val * 1000, 20000);
+				else
+					msleep_interruptible(sleep_val);
+			}
+			++data->power_state;
+			ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
+			if (--data->power_state == 0)
+				bmc150_accel_set_mode(data,
+						BMC150_ACCEL_SLEEP_MODE_SUSPEND,
+						0);
+				/* Nothing can be done if above call fails */
+		}
+		mutex_unlock(&data->mutex);
+		if (ret < 0)
+			return ret;
+
+		*val = sign_extend32(ret >> 4, 11);
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		*val = 0;
+		switch (data->range) {
+		case BMC150_ACCEL_DEF_RANGE_2G:
+			*val = 9610;
+			break;
+		case BMC150_ACCEL_DEF_RANGE_4G:
+			*val2 = 19122;
+			break;
+		case BMC150_ACCEL_DEF_RANGE_8G:
+			*val2 = 38344;
+			break;
+		case BMC150_ACCEL_DEF_RANGE_16G:
+			*val2 = 77057;
+			break;
+		default:
+			return -EINVAL;
+		}
+		return IIO_VAL_INT_PLUS_MICRO;
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		mutex_lock(&data->mutex);
+		ret = bmc150_accel_get_bw(data, val, val2);
+		mutex_unlock(&data->mutex);
+		return ret;
+	default:
+		return -EINVAL;
+	}
+}
+
+static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
+				  struct iio_chan_spec const *chan,
+				  int val, int val2, long mask)
+{
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_SAMP_FREQ:
+		mutex_lock(&data->mutex);
+		ret = bmc150_accel_set_bw(data, val);
+		mutex_unlock(&data->mutex);
+		break;
+	case IIO_CHAN_INFO_SCALE:
+		if (val)
+			return -EINVAL;
+		mutex_lock(&data->mutex);
+		ret = bmc150_accel_set_scale(data, val2);
+		mutex_unlock(&data->mutex);
+		return ret;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+/* power_mode ABI is a documented ABI for accelerometers, utiliziing
+ * this makes lot of sense when no buffered mode available because
+ * of lake of interrupt configuration. If user mode calls to read raw
+ * value with a very high frequency, instead of turn on/off for each
+ * read, keeping system on by setting power mode to "on" will give
+ * better performance.
+ */
+static const char * const bmc150_accel_power_modes[] = {
+	"off",
+	"on",
+};
+
+static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
+				       const struct iio_chan_spec *chan)
+{
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	return data->power_state;
+}
+
+static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
+				       const struct iio_chan_spec *chan,
+				       unsigned int mode)
+{
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+	int ret = 0;
+
+	mutex_lock(&data->mutex);
+	if (mode) {
+		if (!data->power_state)
+			ret = bmc150_accel_set_mode(data,
+						BMC150_ACCEL_SLEEP_MODE_NORMAL,
+						0);
+		++data->power_state;
+	} else {
+		if (--data->power_state == 0)
+			ret = bmc150_accel_set_mode(data,
+					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
+					0);
+	}
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static int bmc150_validate_trigger(struct iio_dev *indio_dev,
+				   struct iio_trigger *trig)
+{
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	if (data->trig != trig)
+		return -EINVAL;
+
+	return 0;
+}
+
+static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
+		"7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
+
+static struct attribute *bmc150_accel_attributes[] = {
+	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group bmc150_accel_attrs_group = {
+	.attrs = bmc150_accel_attributes,
+};
+
+static const struct iio_enum bmc150_accel_power_mode_enum = {
+	.items = bmc150_accel_power_modes,
+	.num_items = ARRAY_SIZE(bmc150_accel_power_modes),
+	.get = bmc150_accel_get_power_mode,
+	.set = bmc150_accel_set_power_mode,
+};
+
+static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
+	IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
+	IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
+	{ },
+};
+
+#define BMC150_ACCEL_CHANNEL(_axis) {					\
+	.type = IIO_ACCEL,						\
+	.modified = 1,							\
+	.channel2 = IIO_MOD_##_axis,					\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),			\
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |		\
+				BIT(IIO_CHAN_INFO_SAMP_FREQ),		\
+	.scan_index = AXIS_##_axis,					\
+	.scan_type = {							\
+		.sign = 's',						\
+		.realbits = 12,						\
+		.storagebits = 16,					\
+		.shift = 4,						\
+	},								\
+	.ext_info = bmc150_accel_ext_info,				\
+}
+
+static const struct iio_chan_spec bmc150_accel_channels[] = {
+	BMC150_ACCEL_CHANNEL(X),
+	BMC150_ACCEL_CHANNEL(Y),
+	BMC150_ACCEL_CHANNEL(Z),
+	IIO_CHAN_SOFT_TIMESTAMP(3),
+};
+
+static const struct iio_info bmc150_accel_info = {
+	.attrs			= &bmc150_accel_attrs_group,
+	.read_raw		= bmc150_accel_read_raw,
+	.write_raw		= bmc150_accel_write_raw,
+	.validate_trigger	= bmc150_validate_trigger,
+	.driver_module		= THIS_MODULE,
+};
+
+static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
+{
+	struct iio_poll_func *pf = p;
+	struct iio_dev *indio_dev = pf->indio_dev;
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+	int bit, ret, i = 0;
+
+	mutex_lock(&data->mutex);
+
+	for_each_set_bit(bit, indio_dev->buffer->scan_mask,
+			 indio_dev->masklength) {
+		ret = bmc150_accel_get_acc_reg(data, bit);
+		if (ret < 0) {
+			bmc150_accel_chip_ack_intr(data);
+			mutex_unlock(&data->mutex);
+			goto err;
+		}
+		data->buffer[i++] = ret;
+	}
+
+	bmc150_accel_chip_ack_intr(data);
+
+	mutex_unlock(&data->mutex);
+
+	iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
+					   pf->timestamp);
+err:
+	iio_trigger_notify_done(indio_dev->trig);
+
+	return IRQ_HANDLED;
+}
+
+static int bmc150_accel_data_rdy_trigger_set_state(struct iio_trigger *trig,
+						   bool state)
+{
+	struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	mutex_lock(&data->mutex);
+	if (state) {
+		bmc150_accel_chip_setup_interrupt(data, true);
+		if (!data->power_state)
+			bmc150_accel_set_mode(data,
+					BMC150_ACCEL_SLEEP_MODE_NORMAL,
+					0);
+		++data->power_state;
+	} else {
+		if (--data->power_state == 0)
+			bmc150_accel_set_mode(data,
+					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
+					0);
+		bmc150_accel_chip_setup_interrupt(data, false);
+	}
+	mutex_unlock(&data->mutex);
+
+	return 0;
+}
+
+static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
+	.set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
+	.owner = THIS_MODULE,
+};
+
+static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
+					struct bmc150_accel_data *data)
+{
+	const struct acpi_device_id *id;
+	struct device *dev;
+	struct gpio_desc *gpio;
+	int ret;
+
+	if (!client)
+		return -EINVAL;
+
+	dev = &client->dev;
+	if (!ACPI_HANDLE(dev))
+		return -ENODEV;
+
+	id = acpi_match_device(dev->driver->acpi_match_table, dev);
+	if (!id)
+		return -ENODEV;
+
+	/* data ready gpio interrupt pin */
+	gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
+	if (IS_ERR(gpio)) {
+		dev_err(dev, "acpi gpio get index failed\n");
+		return PTR_ERR(gpio);
+	}
+
+	ret = gpiod_direction_input(gpio);
+	if (ret)
+		return ret;
+
+	ret = gpiod_to_irq(gpio);
+
+	dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
+
+	return ret;
+}
+
+static int bmc150_accel_probe(struct i2c_client *client,
+			      const struct i2c_device_id *id)
+{
+	struct bmc150_accel_data *data;
+	struct iio_dev *indio_dev;
+	struct iio_trigger *trig = NULL;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	data = iio_priv(indio_dev);
+	i2c_set_clientdata(client, indio_dev);
+	data->client = client;
+
+	ret = bmc150_accel_chip_init(data);
+	if (ret < 0)
+		return ret;
+
+	mutex_init(&data->mutex);
+
+	indio_dev->dev.parent = &client->dev;
+	indio_dev->channels = bmc150_accel_channels;
+	indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
+	indio_dev->name = BMC150_ACCEL_DRV_NAME;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->info = &bmc150_accel_info;
+
+	if (client->irq < 0)
+		client->irq = bmc150_accel_acpi_gpio_probe(client, data);
+
+	if (client->irq >= 0) {
+		trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
+					 indio_dev->id);
+		if (!trig)
+			return -ENOMEM;
+
+		data->trig_mode = true;
+
+		ret = devm_request_irq(&client->dev, client->irq,
+				       iio_trigger_generic_data_rdy_poll,
+				       IRQF_TRIGGER_RISING,
+				       BMC150_ACCEL_IRQ_NAME,
+				       trig);
+		if (ret) {
+			dev_err(&client->dev, "unable to request IRQ\n");
+			goto err_trigger_free;
+		}
+
+		trig->dev.parent = &client->dev;
+		trig->ops = &bmc150_accel_trigger_ops;
+		iio_trigger_set_drvdata(trig, indio_dev);
+		data->trig = trig;
+		indio_dev->trig = trig;
+
+		ret = iio_trigger_register(trig);
+		if (ret)
+			goto err_trigger_free;
+
+		ret = iio_triggered_buffer_setup(indio_dev,
+						 &iio_pollfunc_store_time,
+						 bmc150_accel_trigger_handler,
+						 NULL);
+		if (ret < 0) {
+			dev_err(&client->dev,
+				"iio triggered buffer setup failed\n");
+			goto err_trigger_unregister;
+		}
+	}
+
+	ret = iio_device_register(indio_dev);
+	if (ret < 0) {
+		dev_err(&client->dev, "unable to register iio device\n");
+		goto err_buffer_cleanup;
+	}
+
+	return 0;
+
+err_buffer_cleanup:
+	if (data->trig_mode)
+		iio_triggered_buffer_cleanup(indio_dev);
+err_trigger_unregister:
+	if (data->trig_mode)
+		iio_trigger_unregister(trig);
+err_trigger_free:
+	if (data->trig_mode)
+		iio_trigger_free(trig);
+
+	return ret;
+}
+
+static int bmc150_accel_remove(struct i2c_client *client)
+{
+	struct iio_dev *indio_dev = i2c_get_clientdata(client);
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	iio_device_unregister(indio_dev);
+
+	if (data->trig_mode) {
+		iio_triggered_buffer_cleanup(indio_dev);
+		iio_trigger_unregister(data->trig);
+		iio_trigger_free(data->trig);
+	}
+
+	mutex_lock(&data->mutex);
+	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
+	mutex_unlock(&data->mutex);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int bmc150_accel_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	mutex_lock(&data->mutex);
+	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
+	mutex_unlock(&data->mutex);
+
+	return 0;
+}
+
+static int bmc150_accel_resume(struct device *dev)
+{
+	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
+	struct bmc150_accel_data *data = iio_priv(indio_dev);
+
+	mutex_lock(&data->mutex);
+	if (data->power_state)
+		bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
+	mutex_unlock(&data->mutex);
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
+			 bmc150_accel_resume);
+#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
+#else
+#define BMC150_ACCEL_PM_OPS NULL
+#endif
+
+static const struct acpi_device_id bmc150_accel_acpi_match[] = {
+	{"BSBA0150", 0},
+	{"BMC150A", 0},
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
+
+static const struct i2c_device_id bmc150_accel_id[] = {
+	{"bmc150_accel", 0},
+	{}
+};
+
+MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
+
+static struct i2c_driver bmc150_accel_driver = {
+	.driver = {
+		.name	= BMC150_ACCEL_DRV_NAME,
+		.acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
+		.pm	= BMC150_ACCEL_PM_OPS,
+	},
+	.probe		= bmc150_accel_probe,
+	.remove		= bmc150_accel_remove,
+	.id_table	= bmc150_accel_id,
+};
+module_i2c_driver(bmc150_accel_driver);
+
+MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("BMC150 accelerometer driver");
-- 
1.7.11.7

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-20 18:12 [PATCH] iio: accel: BMC150 accel support Srinivas Pandruvada
@ 2014-06-22 14:23 ` Jonathan Cameron
  2014-06-23  1:22   ` Srinivas Pandruvada
  2014-06-29 20:43 ` Peter Meerwald
  1 sibling, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2014-06-22 14:23 UTC (permalink / raw)
  To: Srinivas Pandruvada; +Cc: linux-iio

On 20/06/14 19:12, Srinivas Pandruvada wrote:
> This change implements BMC150 accelerometer driver. A BMC150 package
> consist of a compass and an accelerometer. This driver only implements
> accelerometer part.
> Spec downloaded from:
> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf
>
> This sensor chip supports many advanced features, but this driver
> implements minimum feature set which is a must to be useful.
> This driver can be enhanced incrementally.
> If the sensor vendor wants to update full featured version, they
> can substitute or enhance this driver when they get chance.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

Various bits inline.

The trigger type is unusual, but if useful that is fine.  However
I think with a few little changes you can loose the requirement that
it is used to drive this device, giving a nicer, more correct solution.

Also, setting indio_dev->trig is generally a bad idea.

Jonathan
> ---
>   drivers/iio/accel/Kconfig        |  13 +
>   drivers/iio/accel/Makefile       |   1 +
>   drivers/iio/accel/bmc150-accel.c | 947 +++++++++++++++++++++++++++++++++++++++
>   3 files changed, 961 insertions(+)
>   create mode 100644 drivers/iio/accel/bmc150-accel.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 12addf2..5704d6b 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -17,6 +17,19 @@ config BMA180
>   	  To compile this driver as a module, choose M here: the
>   	  module will be called bma180.
>
> +config BMC150_ACCEL
> +	tristate "Bosch BMC150 Accelerometer Driver"
> +	depends on I2C
> +	select IIO_BUFFER
> +	select IIO_TRIGGERED_BUFFER
> +	help
> +	  Say yes here to build support for the Bosch BMC150 accelerometer.
> +	  Currently this only supports the device via an i2c interface.
> +
> +	  This is a combo module with both accelerometer and magnetometer.
> +	  This driver is only implementing accelerometer part, which has
> +	  its own address and register map.
> +
>   config HID_SENSOR_ACCEL_3D
>   	depends on HID_SENSOR_HUB
>   	select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 6578ca1..a593996 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,6 +4,7 @@
>
>   # When adding new entries keep the list in alphabetical order
>   obj-$(CONFIG_BMA180) += bma180.o
> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>   obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>   obj-$(CONFIG_KXSD9)	+= kxsd9.o
> diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
> new file mode 100644
> index 0000000..330a3d7
> --- /dev/null
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -0,0 +1,947 @@
> +/*
> + * BMC150 3-axis accelerometer 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/module.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/acpi.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> +#define BMC150_ACCEL_DRV_NAME			"bmc150_accel"
> +#define BMC150_ACCEL_IRQ_NAME			"bmc150_accel_event"
> +
> +#define BMC150_ACCEL_REG_CHIP_ID		0x00
> +#define BMC150_ACCEL_CHIP_ID_VAL		0xFA
> +
> +#define BMC150_ACCEL_REG_PMU_LPW		0x11
> +#define BMC150_ACCEL_PMU_SLP_MASK		0xE0
> +#define BMC150_ACCEL_PMU_SLP_SHIFT		5
> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK	0x17
> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT	1
> +
> +#define BMC150_ACCEL_REG_PMU_RANGE		0x0F
> +
> +#define BMC150_ACCEL_DEF_RANGE_2G		0x03
> +#define BMC150_ACCEL_DEF_RANGE_4G		0x05
> +#define BMC150_ACCEL_DEF_RANGE_8G		0x08
> +#define BMC150_ACCEL_DEF_RANGE_16G		0x0C
> +
> +/* Default BW: 125Hz */
> +#define BMC150_ACCEL_REG_PMU_BW			0x10
> +#define BMC150_ACCEL_DEF_BW			125
> +
> +#define BMC150_ACCEL_REG_INT_MAP_0		0x19
> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE	BIT(2)
> +
> +#define BMC150_ACCEL_REG_INT_RST_LATCH		0x21
> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET	0x80
> +#define BMC150_ACCEL_INT_MODE_LATCH_INT		0x0F
> +
> +#define BMC150_ACCEL_REG_INT_EN_0		0x16
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X		BIT(0)
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y		BIT(1)
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z		BIT(2)
> +
> +#define BMC150_ACCEL_REG_INT_OUT_CTRL		0x20
> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL	BIT(0)
> +
> +#define BMC150_ACCEL_REG_INT_5			0x27
> +#define BMC150_ACCEL_SLOPE_DUR_MASK		0x03
> +
> +#define BMC150_ACCEL_REG_INT_6			0x28
> +#define BMC150_ACCEL_SLOPE_THRES_MASK		0xFF
> +
> +#define BMC150_ACCEL_REG_XOUT_L			0x02
> +#define BMC150_ACCEL_REG_XOUT_H			0x03
> +#define BMC150_ACCEL_REG_YOUT_L			0x04
> +#define BMC150_ACCEL_REG_YOUT_H			0x05
> +#define BMC150_ACCEL_REG_ZOUT_L			0x06
> +#define BMC150_ACCEL_REG_ZOUT_H			0x07
> +
> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS	100
> +
> +/* Slope duration in terms of number of samples */
> +#define BMC150_ACCEL_DEF_SLOPE_DURATION		2
> +/* in terms of multiples of g's/LSB, based on range */
> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD	5
> +
> +/* Sleep Duration values */
> +#define BMC150_ACCEL_SLEEP_500_MICRO		0x05
> +#define BMC150_ACCEL_SLEEP_1_MS			0x06
> +#define BMC150_ACCEL_SLEEP_2_MS			0x07
> +#define BMC150_ACCEL_SLEEP_4_MS			0x08
> +#define BMC150_ACCEL_SLEEP_6_MS			0x09
> +#define BMC150_ACCEL_SLEEP_10_MS		0x0A
> +#define BMC150_ACCEL_SLEEP_25_MS		0x0B
> +#define BMC150_ACCEL_SLEEP_50_MS		0x0C
> +#define BMC150_ACCEL_SLEEP_100_MS		0x0D
> +#define BMC150_ACCEL_SLEEP_500_MS		0x0E
> +#define BMC150_ACCEL_SLEEP_1_SEC		0x0F
> +
> +/* Sleep Modes */
> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL		0x00
> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND	0x01
> +#define BMC150_ACCEL_SLEEP_MODE_LPM		0x03
> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND		0x04
> +
> +struct bmc150_accel_data {
> +	struct i2c_client *client;
> +	struct iio_trigger *trig;
Odd spacing on next line. As suggested later, I'm not
certain this adds much.
> +	bool	trig_mode;
> +	struct mutex mutex;
> +	s16 buffer[3];
This is not big enough to take the timestamp (as required
by the iio_push_to_buffers_with_timestamp call).
> +	int power_state;
> +	u8 bw_bits;

So at the moment we have no control over these?
Note that these correspond directly (I think) to our ROC type
events though they allow both the change and the length over
which it is to be measured to be adjusted.

Looking again, I see you are using these as a trigger. A perfectly
acceptable option.  I have at times wondered if we can come up
with a clean and generic way to do just that, when otherwise reporting
these as events.  Not actually worked out how yet though!
> +	u32 slope_dur;
> +	u32 slope_thres;
> +	u32 range;
> +};
> +
> +enum bmc150_accel_axis {
> +	AXIS_X,
> +	AXIS_Y,
> +	AXIS_Z,
> +};
> +
> +static const struct {
> +	int val;
> +	int val2;
> +	int bw_bits;
I know it would take more lines, but I think I'd prefer to see this formatted
as one per line rather than 2.  Easier to immeidately tell if there is
anything 'unusual' in the form of the values.
> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 0x09},
> +				     {31, 250000, 0x0A}, {62, 500000, 0x0B},
> +				     {125, 0, 0x0C}, {250, 0, 0x0D},
> +				     {500, 0, 0x0E}, {1000, 0, 0x0F} };
> +
> +static const struct {
> +	int bw_bits;
> +	int msec;
Same here, 1 per line makes for more lines of code, but does actually aid
readability (slightly!)
> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 16},
> +				     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
> +				     {0x0E, 1}, {0x0F, 1} };
> +
> +static const struct {
> +	int scale;
> +	int range;
> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
> +				 {19122, BMC150_ACCEL_DEF_RANGE_4G},
> +				 {38344, BMC150_ACCEL_DEF_RANGE_8G},
> +				 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
> +
> +
> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
> +{
> +	int ret;
Why not just drop this variable and reutrn directly from each
case statement?
> +
> +	switch (sleep_dur_us) {
> +	case 0:
> +		ret = 0;
> +		break;
> +	case 500:
> +		ret = BMC150_ACCEL_SLEEP_500_MICRO;
> +		break;
> +	case 1000:
> +		ret = BMC150_ACCEL_SLEEP_1_MS;
> +		break;
> +	case 2000:
> +		ret = BMC150_ACCEL_SLEEP_2_MS;
> +		break;
> +	case 4000:
> +		ret = BMC150_ACCEL_SLEEP_4_MS;
> +		break;
> +	case 6000:
> +		ret = BMC150_ACCEL_SLEEP_6_MS;
> +		break;
> +	case 10000:
> +		ret = BMC150_ACCEL_SLEEP_10_MS;
> +		break;
> +	case 25000:
> +		ret = BMC150_ACCEL_SLEEP_25_MS;
> +		break;
> +	case 50000:
> +		ret = BMC150_ACCEL_SLEEP_50_MS;
> +		break;
> +	case 100000:
> +		ret = BMC150_ACCEL_SLEEP_100_MS;
> +		break;
> +	case 500000:
> +		ret = BMC150_ACCEL_SLEEP_500_MS;
> +		break;
> +	case 1000000:
> +		ret = BMC150_ACCEL_SLEEP_1_SEC;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int mode,
> +				 int dur_us)
> +{
> +	int ret;
> +	u8 lpw_bits = 0;
> +	int dur;
> +
> +	dur = bmc150_accel_convert_sleep_value(dur_us);
> +	if (dur < 0)
> +		return dur;
> +
> +	lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
> +	lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
> +
> +	dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
> +
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_convert_freq_to_bit(int val)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> +		if (bmc150_accel_samp_freq_table[i].val == val)
> +			return bmc150_accel_samp_freq_table[i].bw_bits;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val)>
  +{
> +	int ret;
> +	int bw_bits;
> +
> +	bw_bits = bmc150_accel_convert_freq_to_bit(val);
> +	if (bw_bits < 0)
> +		return bw_bits;
> +
> +	ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_PMU_BW,
> +					bw_bits);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing pmu_bw\n");
> +		return ret;
> +	}
> +
> +	data->bw_bits = bw_bits;
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
> +{
> +	int ret;
> +
> +	ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_CHIP_ID);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +			"Error:BMC150_ACCEL_REG_CHIP_ID\n");
> +		return ret;
> +	}
> +
> +	dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
> +	if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
> +		dev_err(&data->client->dev, "invalid chip %x\n", ret);
> +		return -ENODEV;
> +	}
> +
> +	/* Set Bandwidth */
> +	ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Set Default Range */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_PMU_RANGE,
> +					BMC150_ACCEL_DEF_RANGE_4G);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +					"Error writing pmu_range\n");
> +		return ret;
> +	}
> +	data->range = BMC150_ACCEL_DEF_RANGE_4G;
> +
> +	data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
> +	data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
> +
> +	ret = bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_chip_setup_interrupt(struct bmc150_accel_data *data,
> +					  bool status)
> +{
> +	int ret;
> +
> +	/* Enable/Disable INT1 mapping */
> +	ret = i2c_smbus_read_byte_data(data->client,
> +				       BMC150_ACCEL_REG_INT_MAP_0);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error read reg_int_map0\n");
> +		return ret;
> +	}
There is actually very little overlap in here between the enable and disable
code.  I wonder if it would not be cleaner to have them as separate
functions?  Not that fussed either way however!
> +	if (status)
> +		ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
> +	else
> +		ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
> +
> +
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_MAP_0,
> +					ret);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error write reg_int_map0\n");
> +		return ret;
> +	}
> +
> +	/* Set latched mode interrupt and clear any latched interrupt */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_RST_LATCH,
> +					BMC150_ACCEL_INT_MODE_LATCH_INT |
> +					BMC150_ACCEL_INT_MODE_LATCH_RESET);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error write reg_rst_latch\n");
> +		return ret;
> +	}
> +
> +	/* Enable/Disable slope interrupts */
> +	if (status) {
> +		/* Set slope duration (no of samples) */
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_5,
> +						data->slope_dur);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error write eg_int_5\n");
> +			return ret;
> +		}
> +
> +		/* Set slope thresholds */
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_6,
> +						data->slope_thres);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error write reg_int_6\n");
> +			return ret;
> +		}
> +
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_EN_0,
> +						BMC150_ACCEL_INT_EN_BIT_SLP_X |
> +						BMC150_ACCEL_INT_EN_BIT_SLP_Y |
> +						BMC150_ACCEL_INT_EN_BIT_SLP_Z);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error wr reg_int_en0\n");
> +			return ret;
> +		}
> +
> +	} else
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_EN_0,
> +						0);
> +
Whilst valid, would look more normal to handle the ret inside the else
statement.
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_int_en0\n");
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
> +{
> +	int ret;
> +
> +	/* Set latched mode interrupt and clear any latched interrupt */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_RST_LATCH,
> +					BMC150_ACCEL_INT_MODE_LATCH_INT |
> +					BMC150_ACCEL_INT_MODE_LATCH_RESET);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
> +		return ret;
> +	}
> +
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int *val,
> +			       int *val2)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> +		if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
> +			*val = bmc150_accel_samp_freq_table[i].val;
> +			*val2 = bmc150_accel_samp_freq_table[i].val2;
> +			return IIO_VAL_INT_PLUS_MICRO;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
I am a unconvinced that this wrapper really adds anything, and would be tempted
to move it inline, perhaps with a macro for the register address from
axis conversion.
> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, int axis)
> +{
> +	u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
> +	int ret;
> +
> +	ret = i2c_smbus_read_word_data(data->client, reg);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +			"failed to read accel_%c registers\n", 'x' + axis);
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
> +		if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
> +			return bmc150_accel_sample_upd_time[i].msec;
> +
No need for a blank line here.
> +	}
> +
> +	return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
> +}
> +
> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
> +{
> +	int ret, i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
> +		if (bmc150_accel_scale_table[i].scale == val) {
> +			ret = i2c_smbus_write_byte_data(
> +					data->client,
> +					BMC150_ACCEL_REG_PMU_RANGE,
> +					bmc150_accel_scale_table[i].range);
> +			if (ret < 0) {
> +				dev_err(&data->client->dev,
> +					"Error writing pmu_range\n");
> +				return ret;
> +			}
> +			data->range = bmc150_accel_scale_table[i].range;
> +			return 0;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
> +				 struct iio_chan_spec const *chan,
> +				 int *val, int *val2, long mask)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&data->mutex);
> +		if (iio_buffer_enabled(indio_dev))
> +			ret = -EBUSY;
> +		else {
   I think I'd factor this out to a function for neatness sake.
> +			int sleep_val;
> +			if (!data->power_state) {
> +				ret = bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +						0);
> +				if (ret < 0) {
> +					mutex_unlock(&data->mutex);
> +					return ret;
> +				}
> +				sleep_val =
> +					bmc150_accel_get_startup_times(data);
> +				if (sleep_val < 20)
> +					usleep_range(sleep_val * 1000, 20000);
> +				else
> +					msleep_interruptible(sleep_val);
> +			}
> +			++data->power_state;
> +			ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
handle possible errors here
> +			if (--data->power_state == 0)
> +				bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +						0);
> +				/* Nothing can be done if above call fails
Whilst true, it's still worth passing the error on to userspace so it is aware
something has gone wrong.
				
> +		}
> +		mutex_unlock(&data->mutex);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = sign_extend32(ret >> 4, 11);
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 0;
> +		switch (data->range) {
> +		case BMC150_ACCEL_DEF_RANGE_2G:
> +			*val = 9610;
val2?
> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_4G:
> +			*val2 = 19122;
> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_8G:
> +			*val2 = 38344;
> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_16G:
> +			*val2 = 77057;
> +			break;
> +		default:
> +			return -EINVAL;
> +		}
> +		return IIO_VAL_INT_PLUS_MICRO;
> +	case IIO_CHAN_INFO_SAMP_FREQ:
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_get_bw(data, val, val2);
> +		mutex_unlock(&data->mutex);
> +		return ret;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
> +				  struct iio_chan_spec const *chan,
> +				  int val, int val2, long mask)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_SAMP_FREQ:
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_set_bw(data, val);
The available definitely has stuff in val2.  Should you not be verifying that
as well?
> +		mutex_unlock(&data->mutex);
> +		break;
> +	case IIO_CHAN_INFO_SCALE:
> +		if (val)
> +			return -EINVAL;
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_set_scale(data, val2);
> +		mutex_unlock(&data->mutex);
> +		return ret;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
Multiline comment syntax.  Whilst documented it's also not documented as
having these options, so please add the docs.  I wonder if we want something
more informative than on / off.  Perhaps startup_fast vs startup_slow?
Anyhow, propose the ABI addition and we'll see what people think..
> + * this makes lot of sense when no buffered mode available because
> + * of lake of interrupt configuration. If user mode calls to read raw
lack
> + * value with a very high frequency, instead of turn on/off for each
> + * read, keeping system on by setting power mode to "on" will give
> + * better performance.
> + */
> +static const char * const bmc150_accel_power_modes[] = {
> +	"off",
> +	"on",
> +};
> +
> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
> +				       const struct iio_chan_spec *chan)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	return data->power_state;
> +}
> +
> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
> +				       const struct iio_chan_spec *chan,
> +				       unsigned int mode)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->mutex);
> +	if (mode) {
> +		if (!data->power_state)
> +			ret = bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +						0);
> +		++data->power_state;
> +	} else {
> +		if (--data->power_state == 0)
> +			ret = bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +					0);
> +	}
> +	mutex_unlock(&data->mutex);
> +
> +	return ret;
> +}
> +
> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
> +				   struct iio_trigger *trig)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	if (data->trig != trig)
> +		return -EINVAL;
> +
> +	return 0;
> +}
Why do you need to validate this one?  Ah, the interrupt is cleared
in the buffer handler.  No need to do that.  Just have the clear
in the trigger try_reenable callback (unless I am missing something
odd in the hardware of course!)
> +
> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
> +		"7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
> +
> +static struct attribute *bmc150_accel_attributes[] = {
> +	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
> +	NULL,
> +};
> +
> +static const struct attribute_group bmc150_accel_attrs_group = {
> +	.attrs = bmc150_accel_attributes,
> +};
> +
> +static const struct iio_enum bmc150_accel_power_mode_enum = {
> +	.items = bmc150_accel_power_modes,
> +	.num_items = ARRAY_SIZE(bmc150_accel_power_modes),
> +	.get = bmc150_accel_get_power_mode,
> +	.set = bmc150_accel_set_power_mode,
> +};
> +
> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
> +	IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
> +	IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
Documentation?
> +	{ },
> +};
> +
> +#define BMC150_ACCEL_CHANNEL(_axis) {					\
> +	.type = IIO_ACCEL,						\
> +	.modified = 1,							\
> +	.channel2 = IIO_MOD_##_axis,					\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),			\
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |		\
> +				BIT(IIO_CHAN_INFO_SAMP_FREQ),		\
Given you have only one type, I think conventionally we'd have samp_freq
as a shared_by_all, but this is perfectly valid under the ABI if you
prefer it like this (not documented though, so you'll want to add relevant
lines to Documentation/ABI/testing/sysfs-bus-iio.

> +	.scan_index = AXIS_##_axis,					\
> +	.scan_type = {							\
> +		.sign = 's',						\
> +		.realbits = 12,						\
> +		.storagebits = 16,					\
> +		.shift = 4,						\
> +	},								\
> +	.ext_info = bmc150_accel_ext_info,				\
> +}
> +
> +static const struct iio_chan_spec bmc150_accel_channels[] = {
> +	BMC150_ACCEL_CHANNEL(X),
> +	BMC150_ACCEL_CHANNEL(Y),
> +	BMC150_ACCEL_CHANNEL(Z),
> +	IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> +static const struct iio_info bmc150_accel_info = {
> +	.attrs			= &bmc150_accel_attrs_group,
> +	.read_raw		= bmc150_accel_read_raw,
> +	.write_raw		= bmc150_accel_write_raw,
> +	.validate_trigger	= bmc150_validate_trigger,
> +	.driver_module		= THIS_MODULE,
> +};
> +
> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
> +{
> +	struct iio_poll_func *pf = p;
> +	struct iio_dev *indio_dev = pf->indio_dev;
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int bit, ret, i = 0;
> +
> +	mutex_lock(&data->mutex);
> +
> +	for_each_set_bit(bit, indio_dev->buffer->scan_mask,
> +			 indio_dev->masklength) {
> +		ret = bmc150_accel_get_acc_reg(data, bit);
> +		if (ret < 0) {
> +			bmc150_accel_chip_ack_intr(data);
> +			mutex_unlock(&data->mutex);
> +			goto err;
> +		}
> +		data->buffer[i++] = ret;
> +	}
> +
> +	bmc150_accel_chip_ack_intr(data);

Is a read of the data needed to clear this interrupt?  If not
have a try_reenable callback with the interrupt acknowledge in
it and it should be fine to use this buffer with any trigger
and any trigger with any buffer.

> +
> +	mutex_unlock(&data->mutex);
> +
> +	iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> +					   pf->timestamp);
buffer isn't large enough.  Sometimes I regret that we introduced the function
in the first place... Semantics are odd and that causes so many bugs
like this one.
> +err:
> +	iio_trigger_notify_done(indio_dev->trig);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bmc150_accel_data_rdy_trigger_set_state(struct iio_trigger *trig,
> +						   bool state)
> +{
> +	struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	if (state) {
> +		bmc150_accel_chip_setup_interrupt(data, true);

The above can return an error, ideally you'd handle it and pass onwards.
> +		if (!data->power_state)
> +			bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +					0);
This can also return an error.  Please check handling of errors for these
throughout the driver as I'm not going to mention any more!
> +		++data->power_state;
> +	} else {
> +		if (--data->power_state == 0)
> +			bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +					0);
> +		bmc150_accel_chip_setup_interrupt(data, false);
> +	}
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
> +	.set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
> +					struct bmc150_accel_data *data)
> +{
> +	const struct acpi_device_id *id;
> +	struct device *dev;
> +	struct gpio_desc *gpio;
> +	int ret;
> +
> +	if (!client)
> +		return -EINVAL;
> +
> +	dev = &client->dev;
> +	if (!ACPI_HANDLE(dev))
> +		return -ENODEV;
> +
> +	id = acpi_match_device(dev->driver->acpi_match_table, dev);
> +	if (!id)
> +		return -ENODEV;
> +
> +	/* data ready gpio interrupt pin */
> +	gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
> +	if (IS_ERR(gpio)) {
> +		dev_err(dev, "acpi gpio get index failed\n");
> +		return PTR_ERR(gpio);
> +	}
> +
> +	ret = gpiod_direction_input(gpio);
> +	if (ret)
> +		return ret;
> +
> +	ret = gpiod_to_irq(gpio);
> +
> +	dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_probe(struct i2c_client *client,
> +			      const struct i2c_device_id *id)
> +{
> +	struct bmc150_accel_data *data;
> +	struct iio_dev *indio_dev;
> +	struct iio_trigger *trig = NULL;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	data = iio_priv(indio_dev);
> +	i2c_set_clientdata(client, indio_dev);
> +	data->client = client;
> +
> +	ret = bmc150_accel_chip_init(data);
> +	if (ret < 0)
> +		return ret;
> +
> +	mutex_init(&data->mutex);
> +
> +	indio_dev->dev.parent = &client->dev;
> +	indio_dev->channels = bmc150_accel_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
> +	indio_dev->name = BMC150_ACCEL_DRV_NAME;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->info = &bmc150_accel_info;
> +
> +	if (client->irq < 0)
> +		client->irq = bmc150_accel_acpi_gpio_probe(client, data);
> +
> +	if (client->irq >= 0) {
You could (and probably should given the devm_request_irq after this)
use devm_iio_trigger_alloc and loose all the iio_trigger_free calls.
> +		trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
> +					 indio_dev->id);
> +		if (!trig)
> +			return -ENOMEM;
> +
> +		data->trig_mode = true;
I'm not sure on the necesity for an extra variable to store this
given we can just use whether the trig variable != NULL for the same
thing.  I guess it might make things ever so slightly easier to read...

> +
> +		ret = devm_request_irq(&client->dev, client->irq,
> +				       iio_trigger_generic_data_rdy_poll,
> +				       IRQF_TRIGGER_RISING,
> +				       BMC150_ACCEL_IRQ_NAME,
> +				       trig);
> +		if (ret) {
> +			dev_err(&client->dev, "unable to request IRQ\n");
> +			goto err_trigger_free;
> +		}
> +
> +		trig->dev.parent = &client->dev;
> +		trig->ops = &bmc150_accel_trigger_ops;
> +		iio_trigger_set_drvdata(trig, indio_dev);
> +		data->trig = trig;
> +		indio_dev->trig = trig;
This is dangerous.  Doing it like this will, IIRC leave the wrong
reference counts for the trigger.  If you really, really want to do
this then call iio_get_trigger on the trigger as well to increment
the use count.  Prefered option is to leave the binding to userspace
after the driver is probed.
> +
> +		ret = iio_trigger_register(trig);
> +		if (ret)
> +			goto err_trigger_free;
> +
> +		ret = iio_triggered_buffer_setup(indio_dev,
> +						 &iio_pollfunc_store_time,
> +						 bmc150_accel_trigger_handler,
> +						 NULL);
> +		if (ret < 0) {
> +			dev_err(&client->dev,
> +				"iio triggered buffer setup failed\n");
> +			goto err_trigger_unregister;
> +		}
> +	}
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "unable to register iio device\n");
> +		goto err_buffer_cleanup;
> +	}
> +
> +	return 0;
> +
> +err_buffer_cleanup:
> +	if (data->trig_mode)
> +		iio_triggered_buffer_cleanup(indio_dev);
> +err_trigger_unregister:
> +	if (data->trig_mode)
> +		iio_trigger_unregister(trig);
> +err_trigger_free:
> +	if (data->trig_mode)
> +		iio_trigger_free(trig);
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_remove(struct i2c_client *client)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(client);
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	iio_device_unregister(indio_dev);
> +
> +	if (data->trig_mode) {
> +		iio_triggered_buffer_cleanup(indio_dev);
> +		iio_trigger_unregister(data->trig);
> +		iio_trigger_free(data->trig);
> +	}
> +
> +	mutex_lock(&data->mutex);
> +	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int bmc150_accel_suspend(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_resume(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	if (data->power_state)
> +		bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
> +			 bmc150_accel_resume);
> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
> +#else
> +#define BMC150_ACCEL_PM_OPS NULL
> +#endif
> +
> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
> +	{"BSBA0150", 0},
> +	{"BMC150A", 0},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
> +
> +static const struct i2c_device_id bmc150_accel_id[] = {
> +	{"bmc150_accel", 0},
> +	{}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
> +
> +static struct i2c_driver bmc150_accel_driver = {
> +	.driver = {
> +		.name	= BMC150_ACCEL_DRV_NAME,
> +		.acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
> +		.pm	= BMC150_ACCEL_PM_OPS,
> +	},
> +	.probe		= bmc150_accel_probe,
> +	.remove		= bmc150_accel_remove,
> +	.id_table	= bmc150_accel_id,
> +};
> +module_i2c_driver(bmc150_accel_driver);
> +
> +MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
>


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-22 14:23 ` Jonathan Cameron
@ 2014-06-23  1:22   ` Srinivas Pandruvada
  2014-06-29 11:12     ` Jonathan Cameron
  0 siblings, 1 reply; 12+ messages in thread
From: Srinivas Pandruvada @ 2014-06-23  1:22 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio

Hi Jonathan,

Thanks for the review. I have one question on using power_mode ABI.
The current documentation says
"
What:           /sys/.../iio:deviceX/in_accelX_power_mode
KernelVersion:  3.11
Contact:        linux-iio@vger.kernel.org
Description:
                 Specifies the chip power mode.
                 low_noise: reduce noise level from ADC,
                 low_power: enable low current consumption.
                 For a list of available output power modes read
                 in_accel_power_mode_available.

"

Here I feel power mode is defined for various modes of operation once 
powered on,
but not the way I have used for "on" and "off"
For power and performance, when for simply using raw mode, we may need to
keep the sensor on for extended period of time and other case power down 
after
taking one sample.

So what do you thing about
/sys/.../iio:deviceX/in_XXX_power_state
with possible values
"on", "off" "sleep" "deep_sleep"  etc,

Others inline

On 06/22/2014 07:23 AM, Jonathan Cameron wrote:
> On 20/06/14 19:12, Srinivas Pandruvada wrote:
>> This change implements BMC150 accelerometer driver. A BMC150 package
>> consist of a compass and an accelerometer. This driver only implements
>> accelerometer part.
>> Spec downloaded from:
>> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf 
>>
>>
>> This sensor chip supports many advanced features, but this driver
>> implements minimum feature set which is a must to be useful.
>> This driver can be enhanced incrementally.
>> If the sensor vendor wants to update full featured version, they
>> can substitute or enhance this driver when they get chance.
>>
>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> Various bits inline.
>
> The trigger type is unusual, but if useful that is fine.  However
> I think with a few little changes you can loose the requirement that
> it is used to drive this device, giving a nicer, more correct solution.
>
> Also, setting indio_dev->trig is generally a bad idea.
>
> Jonathan
>> ---
>>   drivers/iio/accel/Kconfig        |  13 +
>>   drivers/iio/accel/Makefile       |   1 +
>>   drivers/iio/accel/bmc150-accel.c | 947 
>> +++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 961 insertions(+)
>>   create mode 100644 drivers/iio/accel/bmc150-accel.c
>>
>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>> index 12addf2..5704d6b 100644
>> --- a/drivers/iio/accel/Kconfig
>> +++ b/drivers/iio/accel/Kconfig
>> @@ -17,6 +17,19 @@ config BMA180
>>         To compile this driver as a module, choose M here: the
>>         module will be called bma180.
>>
>> +config BMC150_ACCEL
>> +    tristate "Bosch BMC150 Accelerometer Driver"
>> +    depends on I2C
>> +    select IIO_BUFFER
>> +    select IIO_TRIGGERED_BUFFER
>> +    help
>> +      Say yes here to build support for the Bosch BMC150 accelerometer.
>> +      Currently this only supports the device via an i2c interface.
>> +
>> +      This is a combo module with both accelerometer and magnetometer.
>> +      This driver is only implementing accelerometer part, which has
>> +      its own address and register map.
>> +
>>   config HID_SENSOR_ACCEL_3D
>>       depends on HID_SENSOR_HUB
>>       select IIO_BUFFER
>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>> index 6578ca1..a593996 100644
>> --- a/drivers/iio/accel/Makefile
>> +++ b/drivers/iio/accel/Makefile
>> @@ -4,6 +4,7 @@
>>
>>   # When adding new entries keep the list in alphabetical order
>>   obj-$(CONFIG_BMA180) += bma180.o
>> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>>   obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>>   obj-$(CONFIG_KXSD9)    += kxsd9.o
>> diff --git a/drivers/iio/accel/bmc150-accel.c 
>> b/drivers/iio/accel/bmc150-accel.c
>> new file mode 100644
>> index 0000000..330a3d7
>> --- /dev/null
>> +++ b/drivers/iio/accel/bmc150-accel.c
>> @@ -0,0 +1,947 @@
>> +/*
>> + * BMC150 3-axis accelerometer 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/module.h>
>> +#include <linux/i2c.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/delay.h>
>> +#include <linux/slab.h>
>> +#include <linux/acpi.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/iio/iio.h>
>> +#include <linux/iio/sysfs.h>
>> +#include <linux/iio/buffer.h>
>> +#include <linux/iio/trigger.h>
>> +#include <linux/iio/trigger_consumer.h>
>> +#include <linux/iio/triggered_buffer.h>
>> +
>> +#define BMC150_ACCEL_DRV_NAME            "bmc150_accel"
>> +#define BMC150_ACCEL_IRQ_NAME            "bmc150_accel_event"
>> +
>> +#define BMC150_ACCEL_REG_CHIP_ID        0x00
>> +#define BMC150_ACCEL_CHIP_ID_VAL        0xFA
>> +
>> +#define BMC150_ACCEL_REG_PMU_LPW        0x11
>> +#define BMC150_ACCEL_PMU_SLP_MASK        0xE0
>> +#define BMC150_ACCEL_PMU_SLP_SHIFT        5
>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK    0x17
>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT    1
>> +
>> +#define BMC150_ACCEL_REG_PMU_RANGE        0x0F
>> +
>> +#define BMC150_ACCEL_DEF_RANGE_2G        0x03
>> +#define BMC150_ACCEL_DEF_RANGE_4G        0x05
>> +#define BMC150_ACCEL_DEF_RANGE_8G        0x08
>> +#define BMC150_ACCEL_DEF_RANGE_16G        0x0C
>> +
>> +/* Default BW: 125Hz */
>> +#define BMC150_ACCEL_REG_PMU_BW            0x10
>> +#define BMC150_ACCEL_DEF_BW            125
>> +
>> +#define BMC150_ACCEL_REG_INT_MAP_0        0x19
>> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE    BIT(2)
>> +
>> +#define BMC150_ACCEL_REG_INT_RST_LATCH        0x21
>> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET    0x80
>> +#define BMC150_ACCEL_INT_MODE_LATCH_INT        0x0F
>> +
>> +#define BMC150_ACCEL_REG_INT_EN_0        0x16
>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X        BIT(0)
>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y        BIT(1)
>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z        BIT(2)
>> +
>> +#define BMC150_ACCEL_REG_INT_OUT_CTRL        0x20
>> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL    BIT(0)
>> +
>> +#define BMC150_ACCEL_REG_INT_5            0x27
>> +#define BMC150_ACCEL_SLOPE_DUR_MASK        0x03
>> +
>> +#define BMC150_ACCEL_REG_INT_6            0x28
>> +#define BMC150_ACCEL_SLOPE_THRES_MASK        0xFF
>> +
>> +#define BMC150_ACCEL_REG_XOUT_L            0x02
>> +#define BMC150_ACCEL_REG_XOUT_H            0x03
>> +#define BMC150_ACCEL_REG_YOUT_L            0x04
>> +#define BMC150_ACCEL_REG_YOUT_H            0x05
>> +#define BMC150_ACCEL_REG_ZOUT_L            0x06
>> +#define BMC150_ACCEL_REG_ZOUT_H            0x07
>> +
>> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS    100
>> +
>> +/* Slope duration in terms of number of samples */
>> +#define BMC150_ACCEL_DEF_SLOPE_DURATION        2
>> +/* in terms of multiples of g's/LSB, based on range */
>> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD    5
>> +
>> +/* Sleep Duration values */
>> +#define BMC150_ACCEL_SLEEP_500_MICRO        0x05
>> +#define BMC150_ACCEL_SLEEP_1_MS            0x06
>> +#define BMC150_ACCEL_SLEEP_2_MS            0x07
>> +#define BMC150_ACCEL_SLEEP_4_MS            0x08
>> +#define BMC150_ACCEL_SLEEP_6_MS            0x09
>> +#define BMC150_ACCEL_SLEEP_10_MS        0x0A
>> +#define BMC150_ACCEL_SLEEP_25_MS        0x0B
>> +#define BMC150_ACCEL_SLEEP_50_MS        0x0C
>> +#define BMC150_ACCEL_SLEEP_100_MS        0x0D
>> +#define BMC150_ACCEL_SLEEP_500_MS        0x0E
>> +#define BMC150_ACCEL_SLEEP_1_SEC        0x0F
>> +
>> +/* Sleep Modes */
>> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL        0x00
>> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND    0x01
>> +#define BMC150_ACCEL_SLEEP_MODE_LPM        0x03
>> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND        0x04
>> +
>> +struct bmc150_accel_data {
>> +    struct i2c_client *client;
>> +    struct iio_trigger *trig;
> Odd spacing on next line. As suggested later, I'm not
> certain this adds much.
>> +    bool    trig_mode;
>> +    struct mutex mutex;
>> +    s16 buffer[3];
> This is not big enough to take the timestamp (as required
> by the iio_push_to_buffers_with_timestamp call).
>> +    int power_state;
>> +    u8 bw_bits;
>
> So at the moment we have no control over these?
> Note that these correspond directly (I think) to our ROC type
> events though they allow both the change and the length over
> which it is to be measured to be adjusted.
>
> Looking again, I see you are using these as a trigger. A perfectly
> acceptable option.  I have at times wondered if we can come up
> with a clean and generic way to do just that, when otherwise reporting
> these as events.  Not actually worked out how yet though!
I thought of using events, but I don't want user space have to take care 
to enable and process events.
This keeps user space simple.
May be we should allow current threshold and period settings non event 
specific, so that
they can be used along with triggers. When corresponding event is 
enabled, then they
will generate events.
>> +    u32 slope_dur;
>> +    u32 slope_thres;
>> +    u32 range;
>> +};
>> +
>> +enum bmc150_accel_axis {
>> +    AXIS_X,
>> +    AXIS_Y,
>> +    AXIS_Z,
>> +};
>> +
>> +static const struct {
>> +    int val;
>> +    int val2;
>> +    int bw_bits;
> I know it would take more lines, but I think I'd prefer to see this 
> formatted
> as one per line rather than 2.  Easier to immeidately tell if there is
> anything 'unusual' in the form of the values.
OK
>> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 
>> 0x09},
>> +                     {31, 250000, 0x0A}, {62, 500000, 0x0B},
>> +                     {125, 0, 0x0C}, {250, 0, 0x0D},
>> +                     {500, 0, 0x0E}, {1000, 0, 0x0F} };
>> +
>> +static const struct {
>> +    int bw_bits;
>> +    int msec;
> Same here, 1 per line makes for more lines of code, but does actually aid
> readability (slightly!)
OK
>> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 
>> 16},
>> +                     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
>> +                     {0x0E, 1}, {0x0F, 1} };
>> +
>> +static const struct {
>> +    int scale;
>> +    int range;
>> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
>> +                 {19122, BMC150_ACCEL_DEF_RANGE_4G},
>> +                 {38344, BMC150_ACCEL_DEF_RANGE_8G},
>> +                 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
>> +
>> +
>> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
>> +{
>> +    int ret;
> Why not just drop this variable and reutrn directly from each
> case statement?
OK
>> +
>> +    switch (sleep_dur_us) {
>> +    case 0:
>> +        ret = 0;
>> +        break;
>> +    case 500:
>> +        ret = BMC150_ACCEL_SLEEP_500_MICRO;
>> +        break;
>> +    case 1000:
>> +        ret = BMC150_ACCEL_SLEEP_1_MS;
>> +        break;
>> +    case 2000:
>> +        ret = BMC150_ACCEL_SLEEP_2_MS;
>> +        break;
>> +    case 4000:
>> +        ret = BMC150_ACCEL_SLEEP_4_MS;
>> +        break;
>> +    case 6000:
>> +        ret = BMC150_ACCEL_SLEEP_6_MS;
>> +        break;
>> +    case 10000:
>> +        ret = BMC150_ACCEL_SLEEP_10_MS;
>> +        break;
>> +    case 25000:
>> +        ret = BMC150_ACCEL_SLEEP_25_MS;
>> +        break;
>> +    case 50000:
>> +        ret = BMC150_ACCEL_SLEEP_50_MS;
>> +        break;
>> +    case 100000:
>> +        ret = BMC150_ACCEL_SLEEP_100_MS;
>> +        break;
>> +    case 500000:
>> +        ret = BMC150_ACCEL_SLEEP_500_MS;
>> +        break;
>> +    case 1000000:
>> +        ret = BMC150_ACCEL_SLEEP_1_SEC;
>> +        break;
>> +    default:
>> +        ret = -EINVAL;
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int 
>> mode,
>> +                 int dur_us)
>> +{
>> +    int ret;
>> +    u8 lpw_bits = 0;
>> +    int dur;
>> +
>> +    dur = bmc150_accel_convert_sleep_value(dur_us);
>> +    if (dur < 0)
>> +        return dur;
>> +
>> +    lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
>> +    lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>> +
>> +    dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>> +
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
>> +        return ret;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static int bmc150_accel_convert_freq_to_bit(int val)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>> +        if (bmc150_accel_samp_freq_table[i].val == val)
>> +            return bmc150_accel_samp_freq_table[i].bw_bits;
>> +    }
>> +
>> +    return -EINVAL;
>> +}
>> +
>> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int 
>> val)>
>  +{
>> +    int ret;
>> +    int bw_bits;
>> +
>> +    bw_bits = bmc150_accel_convert_freq_to_bit(val);
>> +    if (bw_bits < 0)
>> +        return bw_bits;
>> +
>> +    ret = i2c_smbus_write_byte_data(data->client, 
>> BMC150_ACCEL_REG_PMU_BW,
>> +                    bw_bits);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error writing pmu_bw\n");
>> +        return ret;
>> +    }
>> +
>> +    data->bw_bits = bw_bits;
>> +
>> +    return 0;
>> +}
>> +
>> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
>> +{
>> +    int ret;
>> +
>> +    ret = i2c_smbus_read_byte_data(data->client, 
>> BMC150_ACCEL_REG_CHIP_ID);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev,
>> +            "Error:BMC150_ACCEL_REG_CHIP_ID\n");
>> +        return ret;
>> +    }
>> +
>> +    dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
>> +    if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
>> +        dev_err(&data->client->dev, "invalid chip %x\n", ret);
>> +        return -ENODEV;
>> +    }
>> +
>> +    /* Set Bandwidth */
>> +    ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
>> +    if (ret < 0)
>> +        return ret;
>> +
>> +    /* Set Default Range */
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>> +                    BMC150_ACCEL_DEF_RANGE_4G);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev,
>> +                    "Error writing pmu_range\n");
>> +        return ret;
>> +    }
>> +    data->range = BMC150_ACCEL_DEF_RANGE_4G;
>> +
>> +    data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
>> +    data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
>> +
>> +    ret = bmc150_accel_set_mode(data, 
>> BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_chip_setup_interrupt(struct 
>> bmc150_accel_data *data,
>> +                      bool status)
>> +{
>> +    int ret;
>> +
>> +    /* Enable/Disable INT1 mapping */
>> +    ret = i2c_smbus_read_byte_data(data->client,
>> +                       BMC150_ACCEL_REG_INT_MAP_0);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error read reg_int_map0\n");
>> +        return ret;
>> +    }
> There is actually very little overlap in here between the enable and 
> disable
> code.  I wonder if it would not be cleaner to have them as separate
> functions?  Not that fussed either way however!
OK
>> +    if (status)
>> +        ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>> +    else
>> +        ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>> +
>> +
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    BMC150_ACCEL_REG_INT_MAP_0,
>> +                    ret);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error write reg_int_map0\n");
>> +        return ret;
>> +    }
>> +
>> +    /* Set latched mode interrupt and clear any latched interrupt */
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error write reg_rst_latch\n");
>> +        return ret;
>> +    }
>> +
>> +    /* Enable/Disable slope interrupts */
>> +    if (status) {
>> +        /* Set slope duration (no of samples) */
>> +        ret = i2c_smbus_write_byte_data(data->client,
>> +                        BMC150_ACCEL_REG_INT_5,
>> +                        data->slope_dur);
>> +        if (ret < 0) {
>> +            dev_err(&data->client->dev, "Error write eg_int_5\n");
>> +            return ret;
>> +        }
>> +
>> +        /* Set slope thresholds */
>> +        ret = i2c_smbus_write_byte_data(data->client,
>> +                        BMC150_ACCEL_REG_INT_6,
>> +                        data->slope_thres);
>> +        if (ret < 0) {
>> +            dev_err(&data->client->dev, "Error write reg_int_6\n");
>> +            return ret;
>> +        }
>> +
>> +        ret = i2c_smbus_write_byte_data(data->client,
>> +                        BMC150_ACCEL_REG_INT_EN_0,
>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_X |
>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Y |
>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Z);
>> +        if (ret < 0) {
>> +            dev_err(&data->client->dev, "Error wr reg_int_en0\n");
>> +            return ret;
>> +        }
>> +
>> +    } else
>> +        ret = i2c_smbus_write_byte_data(data->client,
>> +                        BMC150_ACCEL_REG_INT_EN_0,
>> +                        0);
>> +
> Whilst valid, would look more normal to handle the ret inside the else
> statement.
OK
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error writing reg_int_en0\n");
>> +        return ret;
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
>> +{
>> +    int ret;
>> +
>> +    /* Set latched mode interrupt and clear any latched interrupt */
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
>> +        return ret;
>> +    }
>> +
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int 
>> *val,
>> +                   int *val2)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>> +        if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
>> +            *val = bmc150_accel_samp_freq_table[i].val;
>> +            *val2 = bmc150_accel_samp_freq_table[i].val2;
>> +            return IIO_VAL_INT_PLUS_MICRO;
>> +        }
>> +    }
>> +
>> +    return -EINVAL;
>> +}
>> +
> I am a unconvinced that this wrapper really adds anything, and would 
> be tempted
> to move it inline, perhaps with a macro for the register address from
> axis conversion.
OK
>> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, 
>> int axis)
>> +{
>> +    u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
>> +    int ret;
>> +
>> +    ret = i2c_smbus_read_word_data(data->client, reg);
>> +    if (ret < 0) {
>> +        dev_err(&data->client->dev,
>> +            "failed to read accel_%c registers\n", 'x' + axis);
>> +        return ret;
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data 
>> *data)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
>> +        if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
>> +            return bmc150_accel_sample_upd_time[i].msec;
>> +
> No need for a blank line here.
OK
>> +    }
>> +
>> +    return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
>> +}
>> +
>> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, 
>> int val)
>> +{
>> +    int ret, i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
>> +        if (bmc150_accel_scale_table[i].scale == val) {
>> +            ret = i2c_smbus_write_byte_data(
>> +                    data->client,
>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>> +                    bmc150_accel_scale_table[i].range);
>> +            if (ret < 0) {
>> +                dev_err(&data->client->dev,
>> +                    "Error writing pmu_range\n");
>> +                return ret;
>> +            }
>> +            data->range = bmc150_accel_scale_table[i].range;
>> +            return 0;
>> +        }
>> +    }
>> +
>> +    return -EINVAL;
>> +}
>> +
>> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
>> +                 struct iio_chan_spec const *chan,
>> +                 int *val, int *val2, long mask)
>> +{
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +    int ret;
>> +
>> +    switch (mask) {
>> +    case IIO_CHAN_INFO_RAW:
>> +        mutex_lock(&data->mutex);
>> +        if (iio_buffer_enabled(indio_dev))
>> +            ret = -EBUSY;
>> +        else {
>   I think I'd factor this out to a function for neatness sake.
OK
>> +            int sleep_val;
>> +            if (!data->power_state) {
>> +                ret = bmc150_accel_set_mode(data,
>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>> +                        0);
>> +                if (ret < 0) {
>> +                    mutex_unlock(&data->mutex);
>> +                    return ret;
>> +                }
>> +                sleep_val =
>> +                    bmc150_accel_get_startup_times(data);
>> +                if (sleep_val < 20)
>> +                    usleep_range(sleep_val * 1000, 20000);
>> +                else
>> +                    msleep_interruptible(sleep_val);
>> +            }
>> +            ++data->power_state;
>> +            ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
> handle possible errors here
>> +            if (--data->power_state == 0)
>> +                bmc150_accel_set_mode(data,
>> +                        BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>> +                        0);
>> +                /* Nothing can be done if above call fails
> Whilst true, it's still worth passing the error on to userspace so it 
> is aware
> something has gone wrong.
OK
>
>> +        }
>> +        mutex_unlock(&data->mutex);
>> +        if (ret < 0)
>> +            return ret;
>> +
>> +        *val = sign_extend32(ret >> 4, 11);
>> +        return IIO_VAL_INT;
>> +    case IIO_CHAN_INFO_SCALE:
>> +        *val = 0;
>> +        switch (data->range) {
>> +        case BMC150_ACCEL_DEF_RANGE_2G:
>> +            *val = 9610;
> val2?
Yes
>> +            break;
>> +        case BMC150_ACCEL_DEF_RANGE_4G:
>> +            *val2 = 19122;
>> +            break;
>> +        case BMC150_ACCEL_DEF_RANGE_8G:
>> +            *val2 = 38344;
>> +            break;
>> +        case BMC150_ACCEL_DEF_RANGE_16G:
>> +            *val2 = 77057;
>> +            break;
>> +        default:
>> +            return -EINVAL;
>> +        }
>> +        return IIO_VAL_INT_PLUS_MICRO;
>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>> +        mutex_lock(&data->mutex);
>> +        ret = bmc150_accel_get_bw(data, val, val2);
>> +        mutex_unlock(&data->mutex);
>> +        return ret;
>> +    default:
>> +        return -EINVAL;
>> +    }
>> +}
>> +
>> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
>> +                  struct iio_chan_spec const *chan,
>> +                  int val, int val2, long mask)
>> +{
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +    int ret;
>> +
>> +    switch (mask) {
>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>> +        mutex_lock(&data->mutex);
>> +        ret = bmc150_accel_set_bw(data, val);
> The available definitely has stuff in val2.  Should you not be 
> verifying that
> as well?
The val field is unique, so I thought not checking val2, for fractions. 
Some user spaces
dropping precision when they read write, failing fraction comparisons.
But I will add back.
>> + mutex_unlock(&data->mutex);
>> +        break;
>> +    case IIO_CHAN_INFO_SCALE:
>> +        if (val)
>> +            return -EINVAL;
>> +        mutex_lock(&data->mutex);
>> +        ret = bmc150_accel_set_scale(data, val2);
>> +        mutex_unlock(&data->mutex);
>> +        return ret;
>> +    default:
>> +        ret = -EINVAL;
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
> Multiline comment syntax.  Whilst documented it's also not documented as
> having these options, so please add the docs.  I wonder if we want 
> something
> more informative than on / off.  Perhaps startup_fast vs startup_slow?
> Anyhow, propose the ABI addition and we'll see what people think..
I don't expect this comment to be there in final version, but to raise 
question
whether "power_mode" is correct to use. I see only one driver is using 
this for
low_noise, low_power. No one is using for ON/OFF type control
>> + * this makes lot of sense when no buffered mode available because
>> + * of lake of interrupt configuration. If user mode calls to read raw
> lack
>> + * value with a very high frequency, instead of turn on/off for each
>> + * read, keeping system on by setting power mode to "on" will give
>> + * better performance.
>> + */
>> +static const char * const bmc150_accel_power_modes[] = {
>> +    "off",
>> +    "on",
>> +};
>> +
>> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
>> +                       const struct iio_chan_spec *chan)
>> +{
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    return data->power_state;
>> +}
>> +
>> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
>> +                       const struct iio_chan_spec *chan,
>> +                       unsigned int mode)
>> +{
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +    int ret = 0;
>> +
>> +    mutex_lock(&data->mutex);
>> +    if (mode) {
>> +        if (!data->power_state)
>> +            ret = bmc150_accel_set_mode(data,
>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>> +                        0);
>> +        ++data->power_state;
>> +    } else {
>> +        if (--data->power_state == 0)
>> +            ret = bmc150_accel_set_mode(data,
>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>> +                    0);
>> +    }
>> +    mutex_unlock(&data->mutex);
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
>> +                   struct iio_trigger *trig)
>> +{
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    if (data->trig != trig)
>> +        return -EINVAL;
>> +
>> +    return 0;
>> +}
> Why do you need to validate this one?  Ah, the interrupt is cleared
> in the buffer handler.  No need to do that.  Just have the clear
> in the trigger try_reenable callback (unless I am missing something
> odd in the hardware of course!)
OK
>> +
>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
>> +        "7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
>> +
>> +static struct attribute *bmc150_accel_attributes[] = {
>> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
>> +    NULL,
>> +};
>> +
>> +static const struct attribute_group bmc150_accel_attrs_group = {
>> +    .attrs = bmc150_accel_attributes,
>> +};
>> +
>> +static const struct iio_enum bmc150_accel_power_mode_enum = {
>> +    .items = bmc150_accel_power_modes,
>> +    .num_items = ARRAY_SIZE(bmc150_accel_power_modes),
>> +    .get = bmc150_accel_get_power_mode,
>> +    .set = bmc150_accel_set_power_mode,
>> +};
>> +
>> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
>> +    IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
>> +    IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
> Documentation?
>> +    { },
>> +};
>> +
>> +#define BMC150_ACCEL_CHANNEL(_axis) {                    \
>> +    .type = IIO_ACCEL,                        \
>> +    .modified = 1,                            \
>> +    .channel2 = IIO_MOD_##_axis,                    \
>> +    .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),            \
>> +    .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |        \
>> +                BIT(IIO_CHAN_INFO_SAMP_FREQ),        \
> Given you have only one type, I think conventionally we'd have samp_freq
> as a shared_by_all, but this is perfectly valid under the ABI if you
> prefer it like this (not documented though, so you'll want to add 
> relevant
> lines to Documentation/ABI/testing/sysfs-bus-iio.
>
I will check.
>> +    .scan_index = AXIS_##_axis,                    \
>> +    .scan_type = {                            \
>> +        .sign = 's',                        \
>> +        .realbits = 12,                        \
>> +        .storagebits = 16,                    \
>> +        .shift = 4,                        \
>> +    },                                \
>> +    .ext_info = bmc150_accel_ext_info,                \
>> +}
>> +
>> +static const struct iio_chan_spec bmc150_accel_channels[] = {
>> +    BMC150_ACCEL_CHANNEL(X),
>> +    BMC150_ACCEL_CHANNEL(Y),
>> +    BMC150_ACCEL_CHANNEL(Z),
>> +    IIO_CHAN_SOFT_TIMESTAMP(3),
>> +};
>> +
>> +static const struct iio_info bmc150_accel_info = {
>> +    .attrs            = &bmc150_accel_attrs_group,
>> +    .read_raw        = bmc150_accel_read_raw,
>> +    .write_raw        = bmc150_accel_write_raw,
>> +    .validate_trigger    = bmc150_validate_trigger,
>> +    .driver_module        = THIS_MODULE,
>> +};
>> +
>> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
>> +{
>> +    struct iio_poll_func *pf = p;
>> +    struct iio_dev *indio_dev = pf->indio_dev;
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +    int bit, ret, i = 0;
>> +
>> +    mutex_lock(&data->mutex);
>> +
>> +    for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>> +             indio_dev->masklength) {
>> +        ret = bmc150_accel_get_acc_reg(data, bit);
>> +        if (ret < 0) {
>> +            bmc150_accel_chip_ack_intr(data);
>> +            mutex_unlock(&data->mutex);
>> +            goto err;
>> +        }
>> +        data->buffer[i++] = ret;
>> +    }
>> +
>> +    bmc150_accel_chip_ack_intr(data);
>
> Is a read of the data needed to clear this interrupt?  If not
> have a try_reenable callback with the interrupt acknowledge in
> it and it should be fine to use this buffer with any trigger
> and any trigger with any buffer.
>
OK
>> +
>> +    mutex_unlock(&data->mutex);
>> +
>> +    iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
>> +                       pf->timestamp);
> buffer isn't large enough.  Sometimes I regret that we introduced the 
> function
> in the first place... Semantics are odd and that causes so many bugs
> like this one.
Definitely a bug.

>> + iio_trigger_notify_done(indio_dev->trig);
>> +
>> +    return IRQ_HANDLED;
>> +}
>> +
>> +static int bmc150_accel_data_rdy_trigger_set_state(struct 
>> iio_trigger *trig,
>> +                           bool state)
>> +{
>> +    struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    mutex_lock(&data->mutex);
>> +    if (state) {
>> +        bmc150_accel_chip_setup_interrupt(data, true);
>
> The above can return an error, ideally you'd handle it and pass onwards.
>> +        if (!data->power_state)
>> +            bmc150_accel_set_mode(data,
>> +                    BMC150_ACCEL_SLEEP_MODE_NORMAL,
>> +                    0);
> This can also return an error.  Please check handling of errors for these
> throughout the driver as I'm not going to mention any more!
OK
>> +        ++data->power_state;
>> +    } else {
>> +        if (--data->power_state == 0)
>> +            bmc150_accel_set_mode(data,
>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>> +                    0);
>> +        bmc150_accel_chip_setup_interrupt(data, false);
>> +    }
>> +    mutex_unlock(&data->mutex);
>> +
>> +    return 0;
>> +}
>> +
>> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
>> +    .set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
>> +    .owner = THIS_MODULE,
>> +};
>> +
>> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
>> +                    struct bmc150_accel_data *data)
>> +{
>> +    const struct acpi_device_id *id;
>> +    struct device *dev;
>> +    struct gpio_desc *gpio;
>> +    int ret;
>> +
>> +    if (!client)
>> +        return -EINVAL;
>> +
>> +    dev = &client->dev;
>> +    if (!ACPI_HANDLE(dev))
>> +        return -ENODEV;
>> +
>> +    id = acpi_match_device(dev->driver->acpi_match_table, dev);
>> +    if (!id)
>> +        return -ENODEV;
>> +
>> +    /* data ready gpio interrupt pin */
>> +    gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
>> +    if (IS_ERR(gpio)) {
>> +        dev_err(dev, "acpi gpio get index failed\n");
>> +        return PTR_ERR(gpio);
>> +    }
>> +
>> +    ret = gpiod_direction_input(gpio);
>> +    if (ret)
>> +        return ret;
>> +
>> +    ret = gpiod_to_irq(gpio);
>> +
>> +    dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", 
>> desc_to_gpio(gpio), ret);
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_probe(struct i2c_client *client,
>> +                  const struct i2c_device_id *id)
>> +{
>> +    struct bmc150_accel_data *data;
>> +    struct iio_dev *indio_dev;
>> +    struct iio_trigger *trig = NULL;
>> +    int ret;
>> +
>> +    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>> +    if (!indio_dev)
>> +        return -ENOMEM;
>> +
>> +    data = iio_priv(indio_dev);
>> +    i2c_set_clientdata(client, indio_dev);
>> +    data->client = client;
>> +
>> +    ret = bmc150_accel_chip_init(data);
>> +    if (ret < 0)
>> +        return ret;
>> +
>> +    mutex_init(&data->mutex);
>> +
>> +    indio_dev->dev.parent = &client->dev;
>> +    indio_dev->channels = bmc150_accel_channels;
>> +    indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
>> +    indio_dev->name = BMC150_ACCEL_DRV_NAME;
>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>> +    indio_dev->info = &bmc150_accel_info;
>> +
>> +    if (client->irq < 0)
>> +        client->irq = bmc150_accel_acpi_gpio_probe(client, data);
>> +
>> +    if (client->irq >= 0) {
> You could (and probably should given the devm_request_irq after this)
> use devm_iio_trigger_alloc and loose all the iio_trigger_free calls.
OK
>> +        trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
>> +                     indio_dev->id);
>> +        if (!trig)
>> +            return -ENOMEM;
>> +
>> +        data->trig_mode = true;
> I'm not sure on the necesity for an extra variable to store this
> given we can just use whether the trig variable != NULL for the same
> thing.  I guess it might make things ever so slightly easier to read...
>
OK
>> +
>> +        ret = devm_request_irq(&client->dev, client->irq,
>> +                       iio_trigger_generic_data_rdy_poll,
>> +                       IRQF_TRIGGER_RISING,
>> +                       BMC150_ACCEL_IRQ_NAME,
>> +                       trig);
>> +        if (ret) {
>> +            dev_err(&client->dev, "unable to request IRQ\n");
>> +            goto err_trigger_free;
>> +        }
>> +
>> +        trig->dev.parent = &client->dev;
>> +        trig->ops = &bmc150_accel_trigger_ops;
>> +        iio_trigger_set_drvdata(trig, indio_dev);
>> +        data->trig = trig;
>> +        indio_dev->trig = trig;
> This is dangerous.  Doing it like this will, IIRC leave the wrong
> reference counts for the trigger.  If you really, really want to do
> this then call iio_get_trigger on the trigger as well to increment
> the use count.  Prefered option is to leave the binding to userspace
> after the driver is probed.
OK
>> +
>> +        ret = iio_trigger_register(trig);
>> +        if (ret)
>> +            goto err_trigger_free;
>> +
>> +        ret = iio_triggered_buffer_setup(indio_dev,
>> +                         &iio_pollfunc_store_time,
>> +                         bmc150_accel_trigger_handler,
>> +                         NULL);
>> +        if (ret < 0) {
>> +            dev_err(&client->dev,
>> +                "iio triggered buffer setup failed\n");
>> +            goto err_trigger_unregister;
>> +        }
>> +    }
>> +
>> +    ret = iio_device_register(indio_dev);
>> +    if (ret < 0) {
>> +        dev_err(&client->dev, "unable to register iio device\n");
>> +        goto err_buffer_cleanup;
>> +    }
>> +
>> +    return 0;
>> +
>> +err_buffer_cleanup:
>> +    if (data->trig_mode)
>> +        iio_triggered_buffer_cleanup(indio_dev);
>> +err_trigger_unregister:
>> +    if (data->trig_mode)
>> +        iio_trigger_unregister(trig);
>> +err_trigger_free:
>> +    if (data->trig_mode)
>> +        iio_trigger_free(trig);
>> +
>> +    return ret;
>> +}
>> +
>> +static int bmc150_accel_remove(struct i2c_client *client)
>> +{
>> +    struct iio_dev *indio_dev = i2c_get_clientdata(client);
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    iio_device_unregister(indio_dev);
>> +
>> +    if (data->trig_mode) {
>> +        iio_triggered_buffer_cleanup(indio_dev);
>> +        iio_trigger_unregister(data->trig);
>> +        iio_trigger_free(data->trig);
>> +    }
>> +
>> +    mutex_lock(&data->mutex);
>> +    bmc150_accel_set_mode(data, 
>> BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
>> +    mutex_unlock(&data->mutex);
>> +
>> +    return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int bmc150_accel_suspend(struct device *dev)
>> +{
>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    mutex_lock(&data->mutex);
>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>> +    mutex_unlock(&data->mutex);
>> +
>> +    return 0;
>> +}
>> +
>> +static int bmc150_accel_resume(struct device *dev)
>> +{
>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>> +
>> +    mutex_lock(&data->mutex);
>> +    if (data->power_state)
>> +        bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
>> +    mutex_unlock(&data->mutex);
>> +
>> +    return 0;
>> +}
>> +
>> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
>> +             bmc150_accel_resume);
>> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
>> +#else
>> +#define BMC150_ACCEL_PM_OPS NULL
>> +#endif
>> +
>> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
>> +    {"BSBA0150", 0},
>> +    {"BMC150A", 0},
>> +    { },
>> +};
>> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
>> +
>> +static const struct i2c_device_id bmc150_accel_id[] = {
>> +    {"bmc150_accel", 0},
>> +    {}
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
>> +
>> +static struct i2c_driver bmc150_accel_driver = {
>> +    .driver = {
>> +        .name    = BMC150_ACCEL_DRV_NAME,
>> +        .acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
>> +        .pm    = BMC150_ACCEL_PM_OPS,
>> +    },
>> +    .probe        = bmc150_accel_probe,
>> +    .remove        = bmc150_accel_remove,
>> +    .id_table    = bmc150_accel_id,
>> +};
>> +module_i2c_driver(bmc150_accel_driver);
>> +
>> +MODULE_AUTHOR("Srinivas Pandruvada 
>> <srinivas.pandruvada@linux.intel.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
>>
>
>
Thanks,
Srinivas

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-23  1:22   ` Srinivas Pandruvada
@ 2014-06-29 11:12     ` Jonathan Cameron
  2014-06-29 14:27       ` Srinivas Pandruvada
  0 siblings, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2014-06-29 11:12 UTC (permalink / raw)
  To: Srinivas Pandruvada; +Cc: linux-iio

On 23/06/14 02:22, Srinivas Pandruvada wrote:
> Hi Jonathan,
>
> Thanks for the review. I have one question on using power_mode ABI.
> The current documentation says
> "
> What:           /sys/.../iio:deviceX/in_accelX_power_mode
> KernelVersion:  3.11
> Contact:        linux-iio@vger.kernel.org
> Description:
>                  Specifies the chip power mode.
>                  low_noise: reduce noise level from ADC,
>                  low_power: enable low current consumption.
>                  For a list of available output power modes read
>                  in_accel_power_mode_available.
>
> "
>
> Here I feel power mode is defined for various modes of operation once powered on,
> but not the way I have used for "on" and "off"
> For power and performance, when for simply using raw mode, we may need to
> keep the sensor on for extended period of time and other case power down after
> taking one sample.
>
> So what do you thing about
> /sys/.../iio:deviceX/in_XXX_power_state
> with possible values
> "on", "off" "sleep" "deep_sleep"  etc,
This comes up from time to time. I personally would really prefer if this stuff
was all handled by core kernel support rather than being implemented out in
a given subsystem.

We do have the runtime power management approach which goes some way towards this
but doesn't (IIRC) provide the level of 'hints' you are talking about here.

I wonder if instead of power state we could represent this as say
latency and hence a numeric value of the number of seconds required to take a measurement
on an attempt to read?

So in this case,

on -> 0 (or more accurate if possible)
off -> some large number (also use runtime pm in this state to allow the regulators
to power down etc).
sleep -> 0.1 perhaps
deepsleep -> 0.5

In this particular part I suspect the dominant element will be how long it takes to write the
setup back to the device so anything here would be estimates.

Still extends more naturally than defining an ever increasing set of labels to different
modes?  What do you think?
>
> Others inline
>
> On 06/22/2014 07:23 AM, Jonathan Cameron wrote:
>> On 20/06/14 19:12, Srinivas Pandruvada wrote:
>>> This change implements BMC150 accelerometer driver. A BMC150 package
>>> consist of a compass and an accelerometer. This driver only implements
>>> accelerometer part.
>>> Spec downloaded from:
>>> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf
>>>
>>> This sensor chip supports many advanced features, but this driver
>>> implements minimum feature set which is a must to be useful.
>>> This driver can be enhanced incrementally.
>>> If the sensor vendor wants to update full featured version, they
>>> can substitute or enhance this driver when they get chance.
>>>
>>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>>
>> Various bits inline.
>>
>> The trigger type is unusual, but if useful that is fine.  However
>> I think with a few little changes you can loose the requirement that
>> it is used to drive this device, giving a nicer, more correct solution.
>>
>> Also, setting indio_dev->trig is generally a bad idea.
>>
>> Jonathan
>>> ---
>>>   drivers/iio/accel/Kconfig        |  13 +
>>>   drivers/iio/accel/Makefile       |   1 +
>>>   drivers/iio/accel/bmc150-accel.c | 947 +++++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 961 insertions(+)
>>>   create mode 100644 drivers/iio/accel/bmc150-accel.c
>>>
>>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>>> index 12addf2..5704d6b 100644
>>> --- a/drivers/iio/accel/Kconfig
>>> +++ b/drivers/iio/accel/Kconfig
>>> @@ -17,6 +17,19 @@ config BMA180
>>>         To compile this driver as a module, choose M here: the
>>>         module will be called bma180.
>>>
>>> +config BMC150_ACCEL
>>> +    tristate "Bosch BMC150 Accelerometer Driver"
>>> +    depends on I2C
>>> +    select IIO_BUFFER
>>> +    select IIO_TRIGGERED_BUFFER
>>> +    help
>>> +      Say yes here to build support for the Bosch BMC150 accelerometer.
>>> +      Currently this only supports the device via an i2c interface.
>>> +
>>> +      This is a combo module with both accelerometer and magnetometer.
>>> +      This driver is only implementing accelerometer part, which has
>>> +      its own address and register map.
>>> +
>>>   config HID_SENSOR_ACCEL_3D
>>>       depends on HID_SENSOR_HUB
>>>       select IIO_BUFFER
>>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>>> index 6578ca1..a593996 100644
>>> --- a/drivers/iio/accel/Makefile
>>> +++ b/drivers/iio/accel/Makefile
>>> @@ -4,6 +4,7 @@
>>>
>>>   # When adding new entries keep the list in alphabetical order
>>>   obj-$(CONFIG_BMA180) += bma180.o
>>> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>>>   obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>>>   obj-$(CONFIG_KXSD9)    += kxsd9.o
>>> diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
>>> new file mode 100644
>>> index 0000000..330a3d7
>>> --- /dev/null
>>> +++ b/drivers/iio/accel/bmc150-accel.c
>>> @@ -0,0 +1,947 @@
>>> +/*
>>> + * BMC150 3-axis accelerometer 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/module.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/acpi.h>
>>> +#include <linux/gpio/consumer.h>
>>> +#include <linux/iio/iio.h>
>>> +#include <linux/iio/sysfs.h>
>>> +#include <linux/iio/buffer.h>
>>> +#include <linux/iio/trigger.h>
>>> +#include <linux/iio/trigger_consumer.h>
>>> +#include <linux/iio/triggered_buffer.h>
>>> +
>>> +#define BMC150_ACCEL_DRV_NAME            "bmc150_accel"
>>> +#define BMC150_ACCEL_IRQ_NAME            "bmc150_accel_event"
>>> +
>>> +#define BMC150_ACCEL_REG_CHIP_ID        0x00
>>> +#define BMC150_ACCEL_CHIP_ID_VAL        0xFA
>>> +
>>> +#define BMC150_ACCEL_REG_PMU_LPW        0x11
>>> +#define BMC150_ACCEL_PMU_SLP_MASK        0xE0
>>> +#define BMC150_ACCEL_PMU_SLP_SHIFT        5
>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK    0x17
>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT    1
>>> +
>>> +#define BMC150_ACCEL_REG_PMU_RANGE        0x0F
>>> +
>>> +#define BMC150_ACCEL_DEF_RANGE_2G        0x03
>>> +#define BMC150_ACCEL_DEF_RANGE_4G        0x05
>>> +#define BMC150_ACCEL_DEF_RANGE_8G        0x08
>>> +#define BMC150_ACCEL_DEF_RANGE_16G        0x0C
>>> +
>>> +/* Default BW: 125Hz */
>>> +#define BMC150_ACCEL_REG_PMU_BW            0x10
>>> +#define BMC150_ACCEL_DEF_BW            125
>>> +
>>> +#define BMC150_ACCEL_REG_INT_MAP_0        0x19
>>> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE    BIT(2)
>>> +
>>> +#define BMC150_ACCEL_REG_INT_RST_LATCH        0x21
>>> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET    0x80
>>> +#define BMC150_ACCEL_INT_MODE_LATCH_INT        0x0F
>>> +
>>> +#define BMC150_ACCEL_REG_INT_EN_0        0x16
>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X        BIT(0)
>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y        BIT(1)
>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z        BIT(2)
>>> +
>>> +#define BMC150_ACCEL_REG_INT_OUT_CTRL        0x20
>>> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL    BIT(0)
>>> +
>>> +#define BMC150_ACCEL_REG_INT_5            0x27
>>> +#define BMC150_ACCEL_SLOPE_DUR_MASK        0x03
>>> +
>>> +#define BMC150_ACCEL_REG_INT_6            0x28
>>> +#define BMC150_ACCEL_SLOPE_THRES_MASK        0xFF
>>> +
>>> +#define BMC150_ACCEL_REG_XOUT_L            0x02
>>> +#define BMC150_ACCEL_REG_XOUT_H            0x03
>>> +#define BMC150_ACCEL_REG_YOUT_L            0x04
>>> +#define BMC150_ACCEL_REG_YOUT_H            0x05
>>> +#define BMC150_ACCEL_REG_ZOUT_L            0x06
>>> +#define BMC150_ACCEL_REG_ZOUT_H            0x07
>>> +
>>> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS    100
>>> +
>>> +/* Slope duration in terms of number of samples */
>>> +#define BMC150_ACCEL_DEF_SLOPE_DURATION        2
>>> +/* in terms of multiples of g's/LSB, based on range */
>>> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD    5
>>> +
>>> +/* Sleep Duration values */
>>> +#define BMC150_ACCEL_SLEEP_500_MICRO        0x05
>>> +#define BMC150_ACCEL_SLEEP_1_MS            0x06
>>> +#define BMC150_ACCEL_SLEEP_2_MS            0x07
>>> +#define BMC150_ACCEL_SLEEP_4_MS            0x08
>>> +#define BMC150_ACCEL_SLEEP_6_MS            0x09
>>> +#define BMC150_ACCEL_SLEEP_10_MS        0x0A
>>> +#define BMC150_ACCEL_SLEEP_25_MS        0x0B
>>> +#define BMC150_ACCEL_SLEEP_50_MS        0x0C
>>> +#define BMC150_ACCEL_SLEEP_100_MS        0x0D
>>> +#define BMC150_ACCEL_SLEEP_500_MS        0x0E
>>> +#define BMC150_ACCEL_SLEEP_1_SEC        0x0F
>>> +
>>> +/* Sleep Modes */
>>> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL        0x00
>>> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND    0x01
>>> +#define BMC150_ACCEL_SLEEP_MODE_LPM        0x03
>>> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND        0x04
>>> +
>>> +struct bmc150_accel_data {
>>> +    struct i2c_client *client;
>>> +    struct iio_trigger *trig;
>> Odd spacing on next line. As suggested later, I'm not
>> certain this adds much.
>>> +    bool    trig_mode;
>>> +    struct mutex mutex;
>>> +    s16 buffer[3];
>> This is not big enough to take the timestamp (as required
>> by the iio_push_to_buffers_with_timestamp call).
>>> +    int power_state;
>>> +    u8 bw_bits;
>>
>> So at the moment we have no control over these?
>> Note that these correspond directly (I think) to our ROC type
>> events though they allow both the change and the length over
>> which it is to be measured to be adjusted.
>>
>> Looking again, I see you are using these as a trigger. A perfectly
>> acceptable option.  I have at times wondered if we can come up
>> with a clean and generic way to do just that, when otherwise reporting
>> these as events.  Not actually worked out how yet though!
> I thought of using events, but I don't want user space have to take care to enable and process events.
> This keeps user space simple.
> May be we should allow current threshold and period settings non event specific, so that
> they can be used along with triggers. When corresponding event is enabled, then they
> will generate events.
>>> +    u32 slope_dur;
>>> +    u32 slope_thres;
>>> +    u32 range;
>>> +};
>>> +
>>> +enum bmc150_accel_axis {
>>> +    AXIS_X,
>>> +    AXIS_Y,
>>> +    AXIS_Z,
>>> +};
>>> +
>>> +static const struct {
>>> +    int val;
>>> +    int val2;
>>> +    int bw_bits;
>> I know it would take more lines, but I think I'd prefer to see this formatted
>> as one per line rather than 2.  Easier to immeidately tell if there is
>> anything 'unusual' in the form of the values.
> OK
>>> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 0x09},
>>> +                     {31, 250000, 0x0A}, {62, 500000, 0x0B},
>>> +                     {125, 0, 0x0C}, {250, 0, 0x0D},
>>> +                     {500, 0, 0x0E}, {1000, 0, 0x0F} };
>>> +
>>> +static const struct {
>>> +    int bw_bits;
>>> +    int msec;
>> Same here, 1 per line makes for more lines of code, but does actually aid
>> readability (slightly!)
> OK
>>> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 16},
>>> +                     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
>>> +                     {0x0E, 1}, {0x0F, 1} };
>>> +
>>> +static const struct {
>>> +    int scale;
>>> +    int range;
>>> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
>>> +                 {19122, BMC150_ACCEL_DEF_RANGE_4G},
>>> +                 {38344, BMC150_ACCEL_DEF_RANGE_8G},
>>> +                 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
>>> +
>>> +
>>> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
>>> +{
>>> +    int ret;
>> Why not just drop this variable and reutrn directly from each
>> case statement?
> OK
>>> +
>>> +    switch (sleep_dur_us) {
>>> +    case 0:
>>> +        ret = 0;
>>> +        break;
>>> +    case 500:
>>> +        ret = BMC150_ACCEL_SLEEP_500_MICRO;
>>> +        break;
>>> +    case 1000:
>>> +        ret = BMC150_ACCEL_SLEEP_1_MS;
>>> +        break;
>>> +    case 2000:
>>> +        ret = BMC150_ACCEL_SLEEP_2_MS;
>>> +        break;
>>> +    case 4000:
>>> +        ret = BMC150_ACCEL_SLEEP_4_MS;
>>> +        break;
>>> +    case 6000:
>>> +        ret = BMC150_ACCEL_SLEEP_6_MS;
>>> +        break;
>>> +    case 10000:
>>> +        ret = BMC150_ACCEL_SLEEP_10_MS;
>>> +        break;
>>> +    case 25000:
>>> +        ret = BMC150_ACCEL_SLEEP_25_MS;
>>> +        break;
>>> +    case 50000:
>>> +        ret = BMC150_ACCEL_SLEEP_50_MS;
>>> +        break;
>>> +    case 100000:
>>> +        ret = BMC150_ACCEL_SLEEP_100_MS;
>>> +        break;
>>> +    case 500000:
>>> +        ret = BMC150_ACCEL_SLEEP_500_MS;
>>> +        break;
>>> +    case 1000000:
>>> +        ret = BMC150_ACCEL_SLEEP_1_SEC;
>>> +        break;
>>> +    default:
>>> +        ret = -EINVAL;
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int mode,
>>> +                 int dur_us)
>>> +{
>>> +    int ret;
>>> +    u8 lpw_bits = 0;
>>> +    int dur;
>>> +
>>> +    dur = bmc150_accel_convert_sleep_value(dur_us);
>>> +    if (dur < 0)
>>> +        return dur;
>>> +
>>> +    lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
>>> +    lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>>> +
>>> +    dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>>> +
>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>> +                    BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int bmc150_accel_convert_freq_to_bit(int val)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>> +        if (bmc150_accel_samp_freq_table[i].val == val)
>>> +            return bmc150_accel_samp_freq_table[i].bw_bits;
>>> +    }
>>> +
>>> +    return -EINVAL;
>>> +}
>>> +
>>> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val)>
>>  +{
>>> +    int ret;
>>> +    int bw_bits;
>>> +
>>> +    bw_bits = bmc150_accel_convert_freq_to_bit(val);
>>> +    if (bw_bits < 0)
>>> +        return bw_bits;
>>> +
>>> +    ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_PMU_BW,
>>> +                    bw_bits);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error writing pmu_bw\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    data->bw_bits = bw_bits;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
>>> +{
>>> +    int ret;
>>> +
>>> +    ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_CHIP_ID);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev,
>>> +            "Error:BMC150_ACCEL_REG_CHIP_ID\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
>>> +    if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
>>> +        dev_err(&data->client->dev, "invalid chip %x\n", ret);
>>> +        return -ENODEV;
>>> +    }
>>> +
>>> +    /* Set Bandwidth */
>>> +    ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
>>> +    if (ret < 0)
>>> +        return ret;
>>> +
>>> +    /* Set Default Range */
>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>> +                    BMC150_ACCEL_DEF_RANGE_4G);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev,
>>> +                    "Error writing pmu_range\n");
>>> +        return ret;
>>> +    }
>>> +    data->range = BMC150_ACCEL_DEF_RANGE_4G;
>>> +
>>> +    data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
>>> +    data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
>>> +
>>> +    ret = bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_chip_setup_interrupt(struct bmc150_accel_data *data,
>>> +                      bool status)
>>> +{
>>> +    int ret;
>>> +
>>> +    /* Enable/Disable INT1 mapping */
>>> +    ret = i2c_smbus_read_byte_data(data->client,
>>> +                       BMC150_ACCEL_REG_INT_MAP_0);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error read reg_int_map0\n");
>>> +        return ret;
>>> +    }
>> There is actually very little overlap in here between the enable and disable
>> code.  I wonder if it would not be cleaner to have them as separate
>> functions?  Not that fussed either way however!
> OK
>>> +    if (status)
>>> +        ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>> +    else
>>> +        ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>> +
>>> +
>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>> +                    BMC150_ACCEL_REG_INT_MAP_0,
>>> +                    ret);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error write reg_int_map0\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error write reg_rst_latch\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    /* Enable/Disable slope interrupts */
>>> +    if (status) {
>>> +        /* Set slope duration (no of samples) */
>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>> +                        BMC150_ACCEL_REG_INT_5,
>>> +                        data->slope_dur);
>>> +        if (ret < 0) {
>>> +            dev_err(&data->client->dev, "Error write eg_int_5\n");
>>> +            return ret;
>>> +        }
>>> +
>>> +        /* Set slope thresholds */
>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>> +                        BMC150_ACCEL_REG_INT_6,
>>> +                        data->slope_thres);
>>> +        if (ret < 0) {
>>> +            dev_err(&data->client->dev, "Error write reg_int_6\n");
>>> +            return ret;
>>> +        }
>>> +
>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_X |
>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Y |
>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Z);
>>> +        if (ret < 0) {
>>> +            dev_err(&data->client->dev, "Error wr reg_int_en0\n");
>>> +            return ret;
>>> +        }
>>> +
>>> +    } else
>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>> +                        0);
>>> +
>> Whilst valid, would look more normal to handle the ret inside the else
>> statement.
> OK
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error writing reg_int_en0\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
>>> +{
>>> +    int ret;
>>> +
>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int *val,
>>> +                   int *val2)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>> +        if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
>>> +            *val = bmc150_accel_samp_freq_table[i].val;
>>> +            *val2 = bmc150_accel_samp_freq_table[i].val2;
>>> +            return IIO_VAL_INT_PLUS_MICRO;
>>> +        }
>>> +    }
>>> +
>>> +    return -EINVAL;
>>> +}
>>> +
>> I am a unconvinced that this wrapper really adds anything, and would be tempted
>> to move it inline, perhaps with a macro for the register address from
>> axis conversion.
> OK
>>> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, int axis)
>>> +{
>>> +    u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
>>> +    int ret;
>>> +
>>> +    ret = i2c_smbus_read_word_data(data->client, reg);
>>> +    if (ret < 0) {
>>> +        dev_err(&data->client->dev,
>>> +            "failed to read accel_%c registers\n", 'x' + axis);
>>> +        return ret;
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
>>> +        if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
>>> +            return bmc150_accel_sample_upd_time[i].msec;
>>> +
>> No need for a blank line here.
> OK
>>> +    }
>>> +
>>> +    return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
>>> +}
>>> +
>>> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
>>> +{
>>> +    int ret, i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
>>> +        if (bmc150_accel_scale_table[i].scale == val) {
>>> +            ret = i2c_smbus_write_byte_data(
>>> +                    data->client,
>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>> +                    bmc150_accel_scale_table[i].range);
>>> +            if (ret < 0) {
>>> +                dev_err(&data->client->dev,
>>> +                    "Error writing pmu_range\n");
>>> +                return ret;
>>> +            }
>>> +            data->range = bmc150_accel_scale_table[i].range;
>>> +            return 0;
>>> +        }
>>> +    }
>>> +
>>> +    return -EINVAL;
>>> +}
>>> +
>>> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
>>> +                 struct iio_chan_spec const *chan,
>>> +                 int *val, int *val2, long mask)
>>> +{
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +    int ret;
>>> +
>>> +    switch (mask) {
>>> +    case IIO_CHAN_INFO_RAW:
>>> +        mutex_lock(&data->mutex);
>>> +        if (iio_buffer_enabled(indio_dev))
>>> +            ret = -EBUSY;
>>> +        else {
>>   I think I'd factor this out to a function for neatness sake.
> OK
>>> +            int sleep_val;
>>> +            if (!data->power_state) {
>>> +                ret = bmc150_accel_set_mode(data,
>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>> +                        0);
>>> +                if (ret < 0) {
>>> +                    mutex_unlock(&data->mutex);
>>> +                    return ret;
>>> +                }
>>> +                sleep_val =
>>> +                    bmc150_accel_get_startup_times(data);
>>> +                if (sleep_val < 20)
>>> +                    usleep_range(sleep_val * 1000, 20000);
>>> +                else
>>> +                    msleep_interruptible(sleep_val);
>>> +            }
>>> +            ++data->power_state;
>>> +            ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
>> handle possible errors here
>>> +            if (--data->power_state == 0)
>>> +                bmc150_accel_set_mode(data,
>>> +                        BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>> +                        0);
>>> +                /* Nothing can be done if above call fails
>> Whilst true, it's still worth passing the error on to userspace so it is aware
>> something has gone wrong.
> OK
>>
>>> +        }
>>> +        mutex_unlock(&data->mutex);
>>> +        if (ret < 0)
>>> +            return ret;
>>> +
>>> +        *val = sign_extend32(ret >> 4, 11);
>>> +        return IIO_VAL_INT;
>>> +    case IIO_CHAN_INFO_SCALE:
>>> +        *val = 0;
>>> +        switch (data->range) {
>>> +        case BMC150_ACCEL_DEF_RANGE_2G:
>>> +            *val = 9610;
>> val2?
> Yes
>>> +            break;
>>> +        case BMC150_ACCEL_DEF_RANGE_4G:
>>> +            *val2 = 19122;
>>> +            break;
>>> +        case BMC150_ACCEL_DEF_RANGE_8G:
>>> +            *val2 = 38344;
>>> +            break;
>>> +        case BMC150_ACCEL_DEF_RANGE_16G:
>>> +            *val2 = 77057;
>>> +            break;
>>> +        default:
>>> +            return -EINVAL;
>>> +        }
>>> +        return IIO_VAL_INT_PLUS_MICRO;
>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>> +        mutex_lock(&data->mutex);
>>> +        ret = bmc150_accel_get_bw(data, val, val2);
>>> +        mutex_unlock(&data->mutex);
>>> +        return ret;
>>> +    default:
>>> +        return -EINVAL;
>>> +    }
>>> +}
>>> +
>>> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
>>> +                  struct iio_chan_spec const *chan,
>>> +                  int val, int val2, long mask)
>>> +{
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +    int ret;
>>> +
>>> +    switch (mask) {
>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>> +        mutex_lock(&data->mutex);
>>> +        ret = bmc150_accel_set_bw(data, val);
>> The available definitely has stuff in val2.  Should you not be verifying that
>> as well?
> The val field is unique, so I thought not checking val2, for fractions. Some user spaces
> dropping precision when they read write, failing fraction comparisons.
> But I will add back.
>>> + mutex_unlock(&data->mutex);
>>> +        break;
>>> +    case IIO_CHAN_INFO_SCALE:
>>> +        if (val)
>>> +            return -EINVAL;
>>> +        mutex_lock(&data->mutex);
>>> +        ret = bmc150_accel_set_scale(data, val2);
>>> +        mutex_unlock(&data->mutex);
>>> +        return ret;
>>> +    default:
>>> +        ret = -EINVAL;
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
>> Multiline comment syntax.  Whilst documented it's also not documented as
>> having these options, so please add the docs.  I wonder if we want something
>> more informative than on / off.  Perhaps startup_fast vs startup_slow?
>> Anyhow, propose the ABI addition and we'll see what people think..
> I don't expect this comment to be there in final version, but to raise question
> whether "power_mode" is correct to use. I see only one driver is using this for
> low_noise, low_power. No one is using for ON/OFF type control
True.  We've killed off a good few of these in the past, primarily because
doing it at a subsystem level is totally wrong.  Perhaps arguably the above
latency suggestion makes it more subsystem relevant than dictating by
'power usage'.  Not sure...
>>> + * this makes lot of sense when no buffered mode available because
>>> + * of lake of interrupt configuration. If user mode calls to read raw
>> lack
>>> + * value with a very high frequency, instead of turn on/off for each
>>> + * read, keeping system on by setting power mode to "on" will give
>>> + * better performance.
>>> + */
>>> +static const char * const bmc150_accel_power_modes[] = {
>>> +    "off",
>>> +    "on",
>>> +};
>>> +
>>> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
>>> +                       const struct iio_chan_spec *chan)
>>> +{
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    return data->power_state;
>>> +}
>>> +
>>> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
>>> +                       const struct iio_chan_spec *chan,
>>> +                       unsigned int mode)
>>> +{
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +    int ret = 0;
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +    if (mode) {
>>> +        if (!data->power_state)
>>> +            ret = bmc150_accel_set_mode(data,
>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>> +                        0);
>>> +        ++data->power_state;
>>> +    } else {
>>> +        if (--data->power_state == 0)
>>> +            ret = bmc150_accel_set_mode(data,
>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>> +                    0);
>>> +    }
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
>>> +                   struct iio_trigger *trig)
>>> +{
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    if (data->trig != trig)
>>> +        return -EINVAL;
>>> +
>>> +    return 0;
>>> +}
>> Why do you need to validate this one?  Ah, the interrupt is cleared
>> in the buffer handler.  No need to do that.  Just have the clear
>> in the trigger try_reenable callback (unless I am missing something
>> odd in the hardware of course!)
> OK
>>> +
>>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
>>> +        "7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
>>> +
>>> +static struct attribute *bmc150_accel_attributes[] = {
>>> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
>>> +    NULL,
>>> +};
>>> +
>>> +static const struct attribute_group bmc150_accel_attrs_group = {
>>> +    .attrs = bmc150_accel_attributes,
>>> +};
>>> +
>>> +static const struct iio_enum bmc150_accel_power_mode_enum = {
>>> +    .items = bmc150_accel_power_modes,
>>> +    .num_items = ARRAY_SIZE(bmc150_accel_power_modes),
>>> +    .get = bmc150_accel_get_power_mode,
>>> +    .set = bmc150_accel_set_power_mode,
>>> +};
>>> +
>>> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
>>> +    IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
>>> +    IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
>> Documentation?
>>> +    { },
>>> +};
>>> +
>>> +#define BMC150_ACCEL_CHANNEL(_axis) {                    \
>>> +    .type = IIO_ACCEL,                        \
>>> +    .modified = 1,                            \
>>> +    .channel2 = IIO_MOD_##_axis,                    \
>>> +    .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),            \
>>> +    .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |        \
>>> +                BIT(IIO_CHAN_INFO_SAMP_FREQ),        \
>> Given you have only one type, I think conventionally we'd have samp_freq
>> as a shared_by_all, but this is perfectly valid under the ABI if you
>> prefer it like this (not documented though, so you'll want to add relevant
>> lines to Documentation/ABI/testing/sysfs-bus-iio.
>>
> I will check.
>>> +    .scan_index = AXIS_##_axis,                    \
>>> +    .scan_type = {                            \
>>> +        .sign = 's',                        \
>>> +        .realbits = 12,                        \
>>> +        .storagebits = 16,                    \
>>> +        .shift = 4,                        \
>>> +    },                                \
>>> +    .ext_info = bmc150_accel_ext_info,                \
>>> +}
>>> +
>>> +static const struct iio_chan_spec bmc150_accel_channels[] = {
>>> +    BMC150_ACCEL_CHANNEL(X),
>>> +    BMC150_ACCEL_CHANNEL(Y),
>>> +    BMC150_ACCEL_CHANNEL(Z),
>>> +    IIO_CHAN_SOFT_TIMESTAMP(3),
>>> +};
>>> +
>>> +static const struct iio_info bmc150_accel_info = {
>>> +    .attrs            = &bmc150_accel_attrs_group,
>>> +    .read_raw        = bmc150_accel_read_raw,
>>> +    .write_raw        = bmc150_accel_write_raw,
>>> +    .validate_trigger    = bmc150_validate_trigger,
>>> +    .driver_module        = THIS_MODULE,
>>> +};
>>> +
>>> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
>>> +{
>>> +    struct iio_poll_func *pf = p;
>>> +    struct iio_dev *indio_dev = pf->indio_dev;
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +    int bit, ret, i = 0;
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +
>>> +    for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>>> +             indio_dev->masklength) {
>>> +        ret = bmc150_accel_get_acc_reg(data, bit);
>>> +        if (ret < 0) {
>>> +            bmc150_accel_chip_ack_intr(data);
>>> +            mutex_unlock(&data->mutex);
>>> +            goto err;
>>> +        }
>>> +        data->buffer[i++] = ret;
>>> +    }
>>> +
>>> +    bmc150_accel_chip_ack_intr(data);
>>
>> Is a read of the data needed to clear this interrupt?  If not
>> have a try_reenable callback with the interrupt acknowledge in
>> it and it should be fine to use this buffer with any trigger
>> and any trigger with any buffer.
>>
> OK
>>> +
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
>>> +                       pf->timestamp);
>> buffer isn't large enough.  Sometimes I regret that we introduced the function
>> in the first place... Semantics are odd and that causes so many bugs
>> like this one.
> Definitely a bug.
>
>>> + iio_trigger_notify_done(indio_dev->trig);
>>> +
>>> +    return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int bmc150_accel_data_rdy_trigger_set_state(struct iio_trigger *trig,
>>> +                           bool state)
>>> +{
>>> +    struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +    if (state) {
>>> +        bmc150_accel_chip_setup_interrupt(data, true);
>>
>> The above can return an error, ideally you'd handle it and pass onwards.
>>> +        if (!data->power_state)
>>> +            bmc150_accel_set_mode(data,
>>> +                    BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>> +                    0);
>> This can also return an error.  Please check handling of errors for these
>> throughout the driver as I'm not going to mention any more!
> OK
>>> +        ++data->power_state;
>>> +    } else {
>>> +        if (--data->power_state == 0)
>>> +            bmc150_accel_set_mode(data,
>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>> +                    0);
>>> +        bmc150_accel_chip_setup_interrupt(data, false);
>>> +    }
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
>>> +    .set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
>>> +    .owner = THIS_MODULE,
>>> +};
>>> +
>>> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
>>> +                    struct bmc150_accel_data *data)
>>> +{
>>> +    const struct acpi_device_id *id;
>>> +    struct device *dev;
>>> +    struct gpio_desc *gpio;
>>> +    int ret;
>>> +
>>> +    if (!client)
>>> +        return -EINVAL;
>>> +
>>> +    dev = &client->dev;
>>> +    if (!ACPI_HANDLE(dev))
>>> +        return -ENODEV;
>>> +
>>> +    id = acpi_match_device(dev->driver->acpi_match_table, dev);
>>> +    if (!id)
>>> +        return -ENODEV;
>>> +
>>> +    /* data ready gpio interrupt pin */
>>> +    gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
>>> +    if (IS_ERR(gpio)) {
>>> +        dev_err(dev, "acpi gpio get index failed\n");
>>> +        return PTR_ERR(gpio);
>>> +    }
>>> +
>>> +    ret = gpiod_direction_input(gpio);
>>> +    if (ret)
>>> +        return ret;
>>> +
>>> +    ret = gpiod_to_irq(gpio);
>>> +
>>> +    dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_probe(struct i2c_client *client,
>>> +                  const struct i2c_device_id *id)
>>> +{
>>> +    struct bmc150_accel_data *data;
>>> +    struct iio_dev *indio_dev;
>>> +    struct iio_trigger *trig = NULL;
>>> +    int ret;
>>> +
>>> +    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>>> +    if (!indio_dev)
>>> +        return -ENOMEM;
>>> +
>>> +    data = iio_priv(indio_dev);
>>> +    i2c_set_clientdata(client, indio_dev);
>>> +    data->client = client;
>>> +
>>> +    ret = bmc150_accel_chip_init(data);
>>> +    if (ret < 0)
>>> +        return ret;
>>> +
>>> +    mutex_init(&data->mutex);
>>> +
>>> +    indio_dev->dev.parent = &client->dev;
>>> +    indio_dev->channels = bmc150_accel_channels;
>>> +    indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
>>> +    indio_dev->name = BMC150_ACCEL_DRV_NAME;
>>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>>> +    indio_dev->info = &bmc150_accel_info;
>>> +
>>> +    if (client->irq < 0)
>>> +        client->irq = bmc150_accel_acpi_gpio_probe(client, data);
>>> +
>>> +    if (client->irq >= 0) {
>> You could (and probably should given the devm_request_irq after this)
>> use devm_iio_trigger_alloc and loose all the iio_trigger_free calls.
> OK
>>> +        trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
>>> +                     indio_dev->id);
>>> +        if (!trig)
>>> +            return -ENOMEM;
>>> +
>>> +        data->trig_mode = true;
>> I'm not sure on the necesity for an extra variable to store this
>> given we can just use whether the trig variable != NULL for the same
>> thing.  I guess it might make things ever so slightly easier to read...
>>
> OK
>>> +
>>> +        ret = devm_request_irq(&client->dev, client->irq,
>>> +                       iio_trigger_generic_data_rdy_poll,
>>> +                       IRQF_TRIGGER_RISING,
>>> +                       BMC150_ACCEL_IRQ_NAME,
>>> +                       trig);
>>> +        if (ret) {
>>> +            dev_err(&client->dev, "unable to request IRQ\n");
>>> +            goto err_trigger_free;
>>> +        }
>>> +
>>> +        trig->dev.parent = &client->dev;
>>> +        trig->ops = &bmc150_accel_trigger_ops;
>>> +        iio_trigger_set_drvdata(trig, indio_dev);
>>> +        data->trig = trig;
>>> +        indio_dev->trig = trig;
>> This is dangerous.  Doing it like this will, IIRC leave the wrong
>> reference counts for the trigger.  If you really, really want to do
>> this then call iio_get_trigger on the trigger as well to increment
>> the use count.  Prefered option is to leave the binding to userspace
>> after the driver is probed.
> OK
>>> +
>>> +        ret = iio_trigger_register(trig);
>>> +        if (ret)
>>> +            goto err_trigger_free;
>>> +
>>> +        ret = iio_triggered_buffer_setup(indio_dev,
>>> +                         &iio_pollfunc_store_time,
>>> +                         bmc150_accel_trigger_handler,
>>> +                         NULL);
>>> +        if (ret < 0) {
>>> +            dev_err(&client->dev,
>>> +                "iio triggered buffer setup failed\n");
>>> +            goto err_trigger_unregister;
>>> +        }
>>> +    }
>>> +
>>> +    ret = iio_device_register(indio_dev);
>>> +    if (ret < 0) {
>>> +        dev_err(&client->dev, "unable to register iio device\n");
>>> +        goto err_buffer_cleanup;
>>> +    }
>>> +
>>> +    return 0;
>>> +
>>> +err_buffer_cleanup:
>>> +    if (data->trig_mode)
>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>> +err_trigger_unregister:
>>> +    if (data->trig_mode)
>>> +        iio_trigger_unregister(trig);
>>> +err_trigger_free:
>>> +    if (data->trig_mode)
>>> +        iio_trigger_free(trig);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int bmc150_accel_remove(struct i2c_client *client)
>>> +{
>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(client);
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    iio_device_unregister(indio_dev);
>>> +
>>> +    if (data->trig_mode) {
>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>> +        iio_trigger_unregister(data->trig);
>>> +        iio_trigger_free(data->trig);
>>> +    }
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int bmc150_accel_suspend(struct device *dev)
>>> +{
>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int bmc150_accel_resume(struct device *dev)
>>> +{
>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>> +
>>> +    mutex_lock(&data->mutex);
>>> +    if (data->power_state)
>>> +        bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
>>> +    mutex_unlock(&data->mutex);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
>>> +             bmc150_accel_resume);
>>> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
>>> +#else
>>> +#define BMC150_ACCEL_PM_OPS NULL
>>> +#endif
>>> +
>>> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
>>> +    {"BSBA0150", 0},
>>> +    {"BMC150A", 0},
>>> +    { },
>>> +};
>>> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
>>> +
>>> +static const struct i2c_device_id bmc150_accel_id[] = {
>>> +    {"bmc150_accel", 0},
>>> +    {}
>>> +};
>>> +
>>> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
>>> +
>>> +static struct i2c_driver bmc150_accel_driver = {
>>> +    .driver = {
>>> +        .name    = BMC150_ACCEL_DRV_NAME,
>>> +        .acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
>>> +        .pm    = BMC150_ACCEL_PM_OPS,
>>> +    },
>>> +    .probe        = bmc150_accel_probe,
>>> +    .remove        = bmc150_accel_remove,
>>> +    .id_table    = bmc150_accel_id,
>>> +};
>>> +module_i2c_driver(bmc150_accel_driver);
>>> +
>>> +MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
>>>
>>
>>
> Thanks,
> Srinivas


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-29 11:12     ` Jonathan Cameron
@ 2014-06-29 14:27       ` Srinivas Pandruvada
  2014-06-29 14:42         ` Jonathan Cameron
  0 siblings, 1 reply; 12+ messages in thread
From: Srinivas Pandruvada @ 2014-06-29 14:27 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio


On 06/29/2014 04:12 AM, Jonathan Cameron wrote:
> On 23/06/14 02:22, Srinivas Pandruvada wrote:
>> Hi Jonathan,
>>
>> Thanks for the review. I have one question on using power_mode ABI.
>> The current documentation says
>> "
>> What:           /sys/.../iio:deviceX/in_accelX_power_mode
>> KernelVersion:  3.11
>> Contact:        linux-iio@vger.kernel.org
>> Description:
>>                  Specifies the chip power mode.
>>                  low_noise: reduce noise level from ADC,
>>                  low_power: enable low current consumption.
>>                  For a list of available output power modes read
>>                  in_accel_power_mode_available.
>>
>> "
>>
>> Here I feel power mode is defined for various modes of operation once 
>> powered on,
>> but not the way I have used for "on" and "off"
>> For power and performance, when for simply using raw mode, we may 
>> need to
>> keep the sensor on for extended period of time and other case power 
>> down after
>> taking one sample.
>>
>> So what do you thing about
>> /sys/.../iio:deviceX/in_XXX_power_state
>> with possible values
>> "on", "off" "sleep" "deep_sleep"  etc,
> This comes up from time to time. I personally would really prefer if 
> this stuff
> was all handled by core kernel support rather than being implemented 
> out in
> a given subsystem.
>
> We do have the runtime power management approach which goes some way 
> towards this
> but doesn't (IIRC) provide the level of 'hints' you are talking about 
> here.
>
> I wonder if instead of power state we could represent this as say
> latency and hence a numeric value of the number of seconds required to 
> take a measurement
> on an attempt to read?
>
> So in this case,
>
> on -> 0 (or more accurate if possible)
> off -> some large number (also use runtime pm in this state to allow 
> the regulators
> to power down etc).
> sleep -> 0.1 perhaps
> deepsleep -> 0.5
>
> In this particular part I suspect the dominant element will be how 
> long it takes to write the
> setup back to the device so anything here would be estimates.
>
> Still extends more naturally than defining an ever increasing set of 
> labels to different
> modes?  What do you think?
Yes, labels are painful to handle. May be we should call 
latency_tolerance, similar to the concept of PCI LTR.
The driver if exports this attribute, it can use latency_tolerance hint 
to decide, how deeper the power state it
can enter. If userspace sets this value to 0, then driver should stay 
awake. The other values are used by
driver based on its sleep/wakeup latencies. I think units should be in 
milli-seconds.

Thanks,
Srinivas
>>
>> Others inline
>>
>> On 06/22/2014 07:23 AM, Jonathan Cameron wrote:
>>> On 20/06/14 19:12, Srinivas Pandruvada wrote:
>>>> This change implements BMC150 accelerometer driver. A BMC150 package
>>>> consist of a compass and an accelerometer. This driver only implements
>>>> accelerometer part.
>>>> Spec downloaded from:
>>>> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf 
>>>>
>>>>
>>>> This sensor chip supports many advanced features, but this driver
>>>> implements minimum feature set which is a must to be useful.
>>>> This driver can be enhanced incrementally.
>>>> If the sensor vendor wants to update full featured version, they
>>>> can substitute or enhance this driver when they get chance.
>>>>
>>>> Signed-off-by: Srinivas Pandruvada 
>>>> <srinivas.pandruvada@linux.intel.com>
>>>
>>> Various bits inline.
>>>
>>> The trigger type is unusual, but if useful that is fine. However
>>> I think with a few little changes you can loose the requirement that
>>> it is used to drive this device, giving a nicer, more correct solution.
>>>
>>> Also, setting indio_dev->trig is generally a bad idea.
>>>
>>> Jonathan
>>>> ---
>>>>   drivers/iio/accel/Kconfig        |  13 +
>>>>   drivers/iio/accel/Makefile       |   1 +
>>>>   drivers/iio/accel/bmc150-accel.c | 947 
>>>> +++++++++++++++++++++++++++++++++++++++
>>>>   3 files changed, 961 insertions(+)
>>>>   create mode 100644 drivers/iio/accel/bmc150-accel.c
>>>>
>>>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>>>> index 12addf2..5704d6b 100644
>>>> --- a/drivers/iio/accel/Kconfig
>>>> +++ b/drivers/iio/accel/Kconfig
>>>> @@ -17,6 +17,19 @@ config BMA180
>>>>         To compile this driver as a module, choose M here: the
>>>>         module will be called bma180.
>>>>
>>>> +config BMC150_ACCEL
>>>> +    tristate "Bosch BMC150 Accelerometer Driver"
>>>> +    depends on I2C
>>>> +    select IIO_BUFFER
>>>> +    select IIO_TRIGGERED_BUFFER
>>>> +    help
>>>> +      Say yes here to build support for the Bosch BMC150 
>>>> accelerometer.
>>>> +      Currently this only supports the device via an i2c interface.
>>>> +
>>>> +      This is a combo module with both accelerometer and 
>>>> magnetometer.
>>>> +      This driver is only implementing accelerometer part, which has
>>>> +      its own address and register map.
>>>> +
>>>>   config HID_SENSOR_ACCEL_3D
>>>>       depends on HID_SENSOR_HUB
>>>>       select IIO_BUFFER
>>>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>>>> index 6578ca1..a593996 100644
>>>> --- a/drivers/iio/accel/Makefile
>>>> +++ b/drivers/iio/accel/Makefile
>>>> @@ -4,6 +4,7 @@
>>>>
>>>>   # When adding new entries keep the list in alphabetical order
>>>>   obj-$(CONFIG_BMA180) += bma180.o
>>>> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>>>>   obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>>>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>>>>   obj-$(CONFIG_KXSD9)    += kxsd9.o
>>>> diff --git a/drivers/iio/accel/bmc150-accel.c 
>>>> b/drivers/iio/accel/bmc150-accel.c
>>>> new file mode 100644
>>>> index 0000000..330a3d7
>>>> --- /dev/null
>>>> +++ b/drivers/iio/accel/bmc150-accel.c
>>>> @@ -0,0 +1,947 @@
>>>> +/*
>>>> + * BMC150 3-axis accelerometer 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/module.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/delay.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/acpi.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> +#include <linux/iio/iio.h>
>>>> +#include <linux/iio/sysfs.h>
>>>> +#include <linux/iio/buffer.h>
>>>> +#include <linux/iio/trigger.h>
>>>> +#include <linux/iio/trigger_consumer.h>
>>>> +#include <linux/iio/triggered_buffer.h>
>>>> +
>>>> +#define BMC150_ACCEL_DRV_NAME            "bmc150_accel"
>>>> +#define BMC150_ACCEL_IRQ_NAME "bmc150_accel_event"
>>>> +
>>>> +#define BMC150_ACCEL_REG_CHIP_ID        0x00
>>>> +#define BMC150_ACCEL_CHIP_ID_VAL        0xFA
>>>> +
>>>> +#define BMC150_ACCEL_REG_PMU_LPW        0x11
>>>> +#define BMC150_ACCEL_PMU_SLP_MASK        0xE0
>>>> +#define BMC150_ACCEL_PMU_SLP_SHIFT        5
>>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK    0x17
>>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT    1
>>>> +
>>>> +#define BMC150_ACCEL_REG_PMU_RANGE        0x0F
>>>> +
>>>> +#define BMC150_ACCEL_DEF_RANGE_2G        0x03
>>>> +#define BMC150_ACCEL_DEF_RANGE_4G        0x05
>>>> +#define BMC150_ACCEL_DEF_RANGE_8G        0x08
>>>> +#define BMC150_ACCEL_DEF_RANGE_16G        0x0C
>>>> +
>>>> +/* Default BW: 125Hz */
>>>> +#define BMC150_ACCEL_REG_PMU_BW            0x10
>>>> +#define BMC150_ACCEL_DEF_BW            125
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_MAP_0        0x19
>>>> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE    BIT(2)
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_RST_LATCH        0x21
>>>> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET    0x80
>>>> +#define BMC150_ACCEL_INT_MODE_LATCH_INT        0x0F
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_EN_0        0x16
>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X        BIT(0)
>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y        BIT(1)
>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z        BIT(2)
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_OUT_CTRL        0x20
>>>> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL    BIT(0)
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_5            0x27
>>>> +#define BMC150_ACCEL_SLOPE_DUR_MASK        0x03
>>>> +
>>>> +#define BMC150_ACCEL_REG_INT_6            0x28
>>>> +#define BMC150_ACCEL_SLOPE_THRES_MASK        0xFF
>>>> +
>>>> +#define BMC150_ACCEL_REG_XOUT_L            0x02
>>>> +#define BMC150_ACCEL_REG_XOUT_H            0x03
>>>> +#define BMC150_ACCEL_REG_YOUT_L            0x04
>>>> +#define BMC150_ACCEL_REG_YOUT_H            0x05
>>>> +#define BMC150_ACCEL_REG_ZOUT_L            0x06
>>>> +#define BMC150_ACCEL_REG_ZOUT_H            0x07
>>>> +
>>>> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS    100
>>>> +
>>>> +/* Slope duration in terms of number of samples */
>>>> +#define BMC150_ACCEL_DEF_SLOPE_DURATION        2
>>>> +/* in terms of multiples of g's/LSB, based on range */
>>>> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD    5
>>>> +
>>>> +/* Sleep Duration values */
>>>> +#define BMC150_ACCEL_SLEEP_500_MICRO        0x05
>>>> +#define BMC150_ACCEL_SLEEP_1_MS            0x06
>>>> +#define BMC150_ACCEL_SLEEP_2_MS            0x07
>>>> +#define BMC150_ACCEL_SLEEP_4_MS            0x08
>>>> +#define BMC150_ACCEL_SLEEP_6_MS            0x09
>>>> +#define BMC150_ACCEL_SLEEP_10_MS        0x0A
>>>> +#define BMC150_ACCEL_SLEEP_25_MS        0x0B
>>>> +#define BMC150_ACCEL_SLEEP_50_MS        0x0C
>>>> +#define BMC150_ACCEL_SLEEP_100_MS        0x0D
>>>> +#define BMC150_ACCEL_SLEEP_500_MS        0x0E
>>>> +#define BMC150_ACCEL_SLEEP_1_SEC        0x0F
>>>> +
>>>> +/* Sleep Modes */
>>>> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL        0x00
>>>> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND    0x01
>>>> +#define BMC150_ACCEL_SLEEP_MODE_LPM        0x03
>>>> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND        0x04
>>>> +
>>>> +struct bmc150_accel_data {
>>>> +    struct i2c_client *client;
>>>> +    struct iio_trigger *trig;
>>> Odd spacing on next line. As suggested later, I'm not
>>> certain this adds much.
>>>> +    bool    trig_mode;
>>>> +    struct mutex mutex;
>>>> +    s16 buffer[3];
>>> This is not big enough to take the timestamp (as required
>>> by the iio_push_to_buffers_with_timestamp call).
>>>> +    int power_state;
>>>> +    u8 bw_bits;
>>>
>>> So at the moment we have no control over these?
>>> Note that these correspond directly (I think) to our ROC type
>>> events though they allow both the change and the length over
>>> which it is to be measured to be adjusted.
>>>
>>> Looking again, I see you are using these as a trigger. A perfectly
>>> acceptable option.  I have at times wondered if we can come up
>>> with a clean and generic way to do just that, when otherwise reporting
>>> these as events.  Not actually worked out how yet though!
>> I thought of using events, but I don't want user space have to take 
>> care to enable and process events.
>> This keeps user space simple.
>> May be we should allow current threshold and period settings non 
>> event specific, so that
>> they can be used along with triggers. When corresponding event is 
>> enabled, then they
>> will generate events.
>>>> +    u32 slope_dur;
>>>> +    u32 slope_thres;
>>>> +    u32 range;
>>>> +};
>>>> +
>>>> +enum bmc150_accel_axis {
>>>> +    AXIS_X,
>>>> +    AXIS_Y,
>>>> +    AXIS_Z,
>>>> +};
>>>> +
>>>> +static const struct {
>>>> +    int val;
>>>> +    int val2;
>>>> +    int bw_bits;
>>> I know it would take more lines, but I think I'd prefer to see this 
>>> formatted
>>> as one per line rather than 2.  Easier to immeidately tell if there is
>>> anything 'unusual' in the form of the values.
>> OK
>>>> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 
>>>> 630000, 0x09},
>>>> +                     {31, 250000, 0x0A}, {62, 500000, 0x0B},
>>>> +                     {125, 0, 0x0C}, {250, 0, 0x0D},
>>>> +                     {500, 0, 0x0E}, {1000, 0, 0x0F} };
>>>> +
>>>> +static const struct {
>>>> +    int bw_bits;
>>>> +    int msec;
>>> Same here, 1 per line makes for more lines of code, but does 
>>> actually aid
>>> readability (slightly!)
>> OK
>>>> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, 
>>>> {0x0A, 16},
>>>> +                     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
>>>> +                     {0x0E, 1}, {0x0F, 1} };
>>>> +
>>>> +static const struct {
>>>> +    int scale;
>>>> +    int range;
>>>> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
>>>> +                 {19122, BMC150_ACCEL_DEF_RANGE_4G},
>>>> +                 {38344, BMC150_ACCEL_DEF_RANGE_8G},
>>>> +                 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
>>>> +
>>>> +
>>>> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
>>>> +{
>>>> +    int ret;
>>> Why not just drop this variable and reutrn directly from each
>>> case statement?
>> OK
>>>> +
>>>> +    switch (sleep_dur_us) {
>>>> +    case 0:
>>>> +        ret = 0;
>>>> +        break;
>>>> +    case 500:
>>>> +        ret = BMC150_ACCEL_SLEEP_500_MICRO;
>>>> +        break;
>>>> +    case 1000:
>>>> +        ret = BMC150_ACCEL_SLEEP_1_MS;
>>>> +        break;
>>>> +    case 2000:
>>>> +        ret = BMC150_ACCEL_SLEEP_2_MS;
>>>> +        break;
>>>> +    case 4000:
>>>> +        ret = BMC150_ACCEL_SLEEP_4_MS;
>>>> +        break;
>>>> +    case 6000:
>>>> +        ret = BMC150_ACCEL_SLEEP_6_MS;
>>>> +        break;
>>>> +    case 10000:
>>>> +        ret = BMC150_ACCEL_SLEEP_10_MS;
>>>> +        break;
>>>> +    case 25000:
>>>> +        ret = BMC150_ACCEL_SLEEP_25_MS;
>>>> +        break;
>>>> +    case 50000:
>>>> +        ret = BMC150_ACCEL_SLEEP_50_MS;
>>>> +        break;
>>>> +    case 100000:
>>>> +        ret = BMC150_ACCEL_SLEEP_100_MS;
>>>> +        break;
>>>> +    case 500000:
>>>> +        ret = BMC150_ACCEL_SLEEP_500_MS;
>>>> +        break;
>>>> +    case 1000000:
>>>> +        ret = BMC150_ACCEL_SLEEP_1_SEC;
>>>> +        break;
>>>> +    default:
>>>> +        ret = -EINVAL;
>>>> +    }
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, 
>>>> int mode,
>>>> +                 int dur_us)
>>>> +{
>>>> +    int ret;
>>>> +    u8 lpw_bits = 0;
>>>> +    int dur;
>>>> +
>>>> +    dur = bmc150_accel_convert_sleep_value(dur_us);
>>>> +    if (dur < 0)
>>>> +        return dur;
>>>> +
>>>> +    lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
>>>> +    lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>>>> +
>>>> +    dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>>>> +
>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>> +                    BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_convert_freq_to_bit(int val)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>>> +        if (bmc150_accel_samp_freq_table[i].val == val)
>>>> +            return bmc150_accel_samp_freq_table[i].bw_bits;
>>>> +    }
>>>> +
>>>> +    return -EINVAL;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int 
>>>> val)>
>>>  +{
>>>> +    int ret;
>>>> +    int bw_bits;
>>>> +
>>>> +    bw_bits = bmc150_accel_convert_freq_to_bit(val);
>>>> +    if (bw_bits < 0)
>>>> +        return bw_bits;
>>>> +
>>>> +    ret = i2c_smbus_write_byte_data(data->client, 
>>>> BMC150_ACCEL_REG_PMU_BW,
>>>> +                    bw_bits);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error writing pmu_bw\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    data->bw_bits = bw_bits;
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
>>>> +{
>>>> +    int ret;
>>>> +
>>>> +    ret = i2c_smbus_read_byte_data(data->client, 
>>>> BMC150_ACCEL_REG_CHIP_ID);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev,
>>>> +            "Error:BMC150_ACCEL_REG_CHIP_ID\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
>>>> +    if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
>>>> +        dev_err(&data->client->dev, "invalid chip %x\n", ret);
>>>> +        return -ENODEV;
>>>> +    }
>>>> +
>>>> +    /* Set Bandwidth */
>>>> +    ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
>>>> +    if (ret < 0)
>>>> +        return ret;
>>>> +
>>>> +    /* Set Default Range */
>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>>> +                    BMC150_ACCEL_DEF_RANGE_4G);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev,
>>>> +                    "Error writing pmu_range\n");
>>>> +        return ret;
>>>> +    }
>>>> +    data->range = BMC150_ACCEL_DEF_RANGE_4G;
>>>> +
>>>> +    data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
>>>> +    data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
>>>> +
>>>> +    ret = bmc150_accel_set_mode(data, 
>>>> BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_chip_setup_interrupt(struct 
>>>> bmc150_accel_data *data,
>>>> +                      bool status)
>>>> +{
>>>> +    int ret;
>>>> +
>>>> +    /* Enable/Disable INT1 mapping */
>>>> +    ret = i2c_smbus_read_byte_data(data->client,
>>>> +                       BMC150_ACCEL_REG_INT_MAP_0);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error read reg_int_map0\n");
>>>> +        return ret;
>>>> +    }
>>> There is actually very little overlap in here between the enable and 
>>> disable
>>> code.  I wonder if it would not be cleaner to have them as separate
>>> functions?  Not that fussed either way however!
>> OK
>>>> +    if (status)
>>>> +        ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>>> +    else
>>>> +        ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>>> +
>>>> +
>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>> +                    BMC150_ACCEL_REG_INT_MAP_0,
>>>> +                    ret);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error write reg_int_map0\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error write reg_rst_latch\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    /* Enable/Disable slope interrupts */
>>>> +    if (status) {
>>>> +        /* Set slope duration (no of samples) */
>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>> +                        BMC150_ACCEL_REG_INT_5,
>>>> +                        data->slope_dur);
>>>> +        if (ret < 0) {
>>>> +            dev_err(&data->client->dev, "Error write eg_int_5\n");
>>>> +            return ret;
>>>> +        }
>>>> +
>>>> +        /* Set slope thresholds */
>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>> +                        BMC150_ACCEL_REG_INT_6,
>>>> +                        data->slope_thres);
>>>> +        if (ret < 0) {
>>>> +            dev_err(&data->client->dev, "Error write reg_int_6\n");
>>>> +            return ret;
>>>> +        }
>>>> +
>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_X |
>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Y |
>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Z);
>>>> +        if (ret < 0) {
>>>> +            dev_err(&data->client->dev, "Error wr reg_int_en0\n");
>>>> +            return ret;
>>>> +        }
>>>> +
>>>> +    } else
>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>>> +                        0);
>>>> +
>>> Whilst valid, would look more normal to handle the ret inside the else
>>> statement.
>> OK
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error writing reg_int_en0\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
>>>> +{
>>>> +    int ret;
>>>> +
>>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int 
>>>> *val,
>>>> +                   int *val2)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>>> +        if (bmc150_accel_samp_freq_table[i].bw_bits == 
>>>> data->bw_bits) {
>>>> +            *val = bmc150_accel_samp_freq_table[i].val;
>>>> +            *val2 = bmc150_accel_samp_freq_table[i].val2;
>>>> +            return IIO_VAL_INT_PLUS_MICRO;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    return -EINVAL;
>>>> +}
>>>> +
>>> I am a unconvinced that this wrapper really adds anything, and would 
>>> be tempted
>>> to move it inline, perhaps with a macro for the register address from
>>> axis conversion.
>> OK
>>>> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data 
>>>> *data, int axis)
>>>> +{
>>>> +    u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
>>>> +    int ret;
>>>> +
>>>> +    ret = i2c_smbus_read_word_data(data->client, reg);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&data->client->dev,
>>>> +            "failed to read accel_%c registers\n", 'x' + axis);
>>>> +        return ret;
>>>> +    }
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data 
>>>> *data)
>>>> +{
>>>> +    int i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
>>>> +        if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
>>>> +            return bmc150_accel_sample_upd_time[i].msec;
>>>> +
>>> No need for a blank line here.
>> OK
>>>> +    }
>>>> +
>>>> +    return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, 
>>>> int val)
>>>> +{
>>>> +    int ret, i;
>>>> +
>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
>>>> +        if (bmc150_accel_scale_table[i].scale == val) {
>>>> +            ret = i2c_smbus_write_byte_data(
>>>> +                    data->client,
>>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>>> +                    bmc150_accel_scale_table[i].range);
>>>> +            if (ret < 0) {
>>>> +                dev_err(&data->client->dev,
>>>> +                    "Error writing pmu_range\n");
>>>> +                return ret;
>>>> +            }
>>>> +            data->range = bmc150_accel_scale_table[i].range;
>>>> +            return 0;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    return -EINVAL;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
>>>> +                 struct iio_chan_spec const *chan,
>>>> +                 int *val, int *val2, long mask)
>>>> +{
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +    int ret;
>>>> +
>>>> +    switch (mask) {
>>>> +    case IIO_CHAN_INFO_RAW:
>>>> +        mutex_lock(&data->mutex);
>>>> +        if (iio_buffer_enabled(indio_dev))
>>>> +            ret = -EBUSY;
>>>> +        else {
>>>   I think I'd factor this out to a function for neatness sake.
>> OK
>>>> +            int sleep_val;
>>>> +            if (!data->power_state) {
>>>> +                ret = bmc150_accel_set_mode(data,
>>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>> +                        0);
>>>> +                if (ret < 0) {
>>>> +                    mutex_unlock(&data->mutex);
>>>> +                    return ret;
>>>> +                }
>>>> +                sleep_val =
>>>> +                    bmc150_accel_get_startup_times(data);
>>>> +                if (sleep_val < 20)
>>>> +                    usleep_range(sleep_val * 1000, 20000);
>>>> +                else
>>>> +                    msleep_interruptible(sleep_val);
>>>> +            }
>>>> +            ++data->power_state;
>>>> +            ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
>>> handle possible errors here
>>>> +            if (--data->power_state == 0)
>>>> +                bmc150_accel_set_mode(data,
>>>> +                        BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>> +                        0);
>>>> +                /* Nothing can be done if above call fails
>>> Whilst true, it's still worth passing the error on to userspace so 
>>> it is aware
>>> something has gone wrong.
>> OK
>>>
>>>> +        }
>>>> +        mutex_unlock(&data->mutex);
>>>> +        if (ret < 0)
>>>> +            return ret;
>>>> +
>>>> +        *val = sign_extend32(ret >> 4, 11);
>>>> +        return IIO_VAL_INT;
>>>> +    case IIO_CHAN_INFO_SCALE:
>>>> +        *val = 0;
>>>> +        switch (data->range) {
>>>> +        case BMC150_ACCEL_DEF_RANGE_2G:
>>>> +            *val = 9610;
>>> val2?
>> Yes
>>>> +            break;
>>>> +        case BMC150_ACCEL_DEF_RANGE_4G:
>>>> +            *val2 = 19122;
>>>> +            break;
>>>> +        case BMC150_ACCEL_DEF_RANGE_8G:
>>>> +            *val2 = 38344;
>>>> +            break;
>>>> +        case BMC150_ACCEL_DEF_RANGE_16G:
>>>> +            *val2 = 77057;
>>>> +            break;
>>>> +        default:
>>>> +            return -EINVAL;
>>>> +        }
>>>> +        return IIO_VAL_INT_PLUS_MICRO;
>>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>>> +        mutex_lock(&data->mutex);
>>>> +        ret = bmc150_accel_get_bw(data, val, val2);
>>>> +        mutex_unlock(&data->mutex);
>>>> +        return ret;
>>>> +    default:
>>>> +        return -EINVAL;
>>>> +    }
>>>> +}
>>>> +
>>>> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
>>>> +                  struct iio_chan_spec const *chan,
>>>> +                  int val, int val2, long mask)
>>>> +{
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +    int ret;
>>>> +
>>>> +    switch (mask) {
>>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>>> +        mutex_lock(&data->mutex);
>>>> +        ret = bmc150_accel_set_bw(data, val);
>>> The available definitely has stuff in val2.  Should you not be 
>>> verifying that
>>> as well?
>> The val field is unique, so I thought not checking val2, for 
>> fractions. Some user spaces
>> dropping precision when they read write, failing fraction comparisons.
>> But I will add back.
>>>> + mutex_unlock(&data->mutex);
>>>> +        break;
>>>> +    case IIO_CHAN_INFO_SCALE:
>>>> +        if (val)
>>>> +            return -EINVAL;
>>>> +        mutex_lock(&data->mutex);
>>>> +        ret = bmc150_accel_set_scale(data, val2);
>>>> +        mutex_unlock(&data->mutex);
>>>> +        return ret;
>>>> +    default:
>>>> +        ret = -EINVAL;
>>>> +    }
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
>>> Multiline comment syntax.  Whilst documented it's also not 
>>> documented as
>>> having these options, so please add the docs.  I wonder if we want 
>>> something
>>> more informative than on / off.  Perhaps startup_fast vs startup_slow?
>>> Anyhow, propose the ABI addition and we'll see what people think..
>> I don't expect this comment to be there in final version, but to 
>> raise question
>> whether "power_mode" is correct to use. I see only one driver is 
>> using this for
>> low_noise, low_power. No one is using for ON/OFF type control
> True.  We've killed off a good few of these in the past, primarily 
> because
> doing it at a subsystem level is totally wrong.  Perhaps arguably the 
> above
> latency suggestion makes it more subsystem relevant than dictating by
> 'power usage'.  Not sure...
>>>> + * this makes lot of sense when no buffered mode available because
>>>> + * of lake of interrupt configuration. If user mode calls to read raw
>>> lack
>>>> + * value with a very high frequency, instead of turn on/off for each
>>>> + * read, keeping system on by setting power mode to "on" will give
>>>> + * better performance.
>>>> + */
>>>> +static const char * const bmc150_accel_power_modes[] = {
>>>> +    "off",
>>>> +    "on",
>>>> +};
>>>> +
>>>> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
>>>> +                       const struct iio_chan_spec *chan)
>>>> +{
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    return data->power_state;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
>>>> +                       const struct iio_chan_spec *chan,
>>>> +                       unsigned int mode)
>>>> +{
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +    int ret = 0;
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +    if (mode) {
>>>> +        if (!data->power_state)
>>>> +            ret = bmc150_accel_set_mode(data,
>>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>> +                        0);
>>>> +        ++data->power_state;
>>>> +    } else {
>>>> +        if (--data->power_state == 0)
>>>> +            ret = bmc150_accel_set_mode(data,
>>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>> +                    0);
>>>> +    }
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
>>>> +                   struct iio_trigger *trig)
>>>> +{
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    if (data->trig != trig)
>>>> +        return -EINVAL;
>>>> +
>>>> +    return 0;
>>>> +}
>>> Why do you need to validate this one?  Ah, the interrupt is cleared
>>> in the buffer handler.  No need to do that.  Just have the clear
>>> in the trigger try_reenable callback (unless I am missing something
>>> odd in the hardware of course!)
>> OK
>>>> +
>>>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
>>>> +        "7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
>>>> +
>>>> +static struct attribute *bmc150_accel_attributes[] = {
>>>> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
>>>> +    NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group bmc150_accel_attrs_group = {
>>>> +    .attrs = bmc150_accel_attributes,
>>>> +};
>>>> +
>>>> +static const struct iio_enum bmc150_accel_power_mode_enum = {
>>>> +    .items = bmc150_accel_power_modes,
>>>> +    .num_items = ARRAY_SIZE(bmc150_accel_power_modes),
>>>> +    .get = bmc150_accel_get_power_mode,
>>>> +    .set = bmc150_accel_set_power_mode,
>>>> +};
>>>> +
>>>> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] 
>>>> = {
>>>> +    IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
>>>> +    IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
>>> Documentation?
>>>> +    { },
>>>> +};
>>>> +
>>>> +#define BMC150_ACCEL_CHANNEL(_axis) {                    \
>>>> +    .type = IIO_ACCEL,                        \
>>>> +    .modified = 1,                            \
>>>> +    .channel2 = IIO_MOD_##_axis,                    \
>>>> +    .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),            \
>>>> +    .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |        \
>>>> +                BIT(IIO_CHAN_INFO_SAMP_FREQ),        \
>>> Given you have only one type, I think conventionally we'd have 
>>> samp_freq
>>> as a shared_by_all, but this is perfectly valid under the ABI if you
>>> prefer it like this (not documented though, so you'll want to add 
>>> relevant
>>> lines to Documentation/ABI/testing/sysfs-bus-iio.
>>>
>> I will check.
>>>> +    .scan_index = AXIS_##_axis,                    \
>>>> +    .scan_type = {                            \
>>>> +        .sign = 's',                        \
>>>> +        .realbits = 12,                        \
>>>> +        .storagebits = 16,                    \
>>>> +        .shift = 4,                        \
>>>> +    },                                \
>>>> +    .ext_info = bmc150_accel_ext_info,                \
>>>> +}
>>>> +
>>>> +static const struct iio_chan_spec bmc150_accel_channels[] = {
>>>> +    BMC150_ACCEL_CHANNEL(X),
>>>> +    BMC150_ACCEL_CHANNEL(Y),
>>>> +    BMC150_ACCEL_CHANNEL(Z),
>>>> +    IIO_CHAN_SOFT_TIMESTAMP(3),
>>>> +};
>>>> +
>>>> +static const struct iio_info bmc150_accel_info = {
>>>> +    .attrs            = &bmc150_accel_attrs_group,
>>>> +    .read_raw        = bmc150_accel_read_raw,
>>>> +    .write_raw        = bmc150_accel_write_raw,
>>>> +    .validate_trigger    = bmc150_validate_trigger,
>>>> +    .driver_module        = THIS_MODULE,
>>>> +};
>>>> +
>>>> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
>>>> +{
>>>> +    struct iio_poll_func *pf = p;
>>>> +    struct iio_dev *indio_dev = pf->indio_dev;
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +    int bit, ret, i = 0;
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +
>>>> +    for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>>>> +             indio_dev->masklength) {
>>>> +        ret = bmc150_accel_get_acc_reg(data, bit);
>>>> +        if (ret < 0) {
>>>> +            bmc150_accel_chip_ack_intr(data);
>>>> +            mutex_unlock(&data->mutex);
>>>> +            goto err;
>>>> +        }
>>>> +        data->buffer[i++] = ret;
>>>> +    }
>>>> +
>>>> +    bmc150_accel_chip_ack_intr(data);
>>>
>>> Is a read of the data needed to clear this interrupt?  If not
>>> have a try_reenable callback with the interrupt acknowledge in
>>> it and it should be fine to use this buffer with any trigger
>>> and any trigger with any buffer.
>>>
>> OK
>>>> +
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
>>>> +                       pf->timestamp);
>>> buffer isn't large enough.  Sometimes I regret that we introduced 
>>> the function
>>> in the first place... Semantics are odd and that causes so many bugs
>>> like this one.
>> Definitely a bug.
>>
>>>> + iio_trigger_notify_done(indio_dev->trig);
>>>> +
>>>> +    return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_data_rdy_trigger_set_state(struct 
>>>> iio_trigger *trig,
>>>> +                           bool state)
>>>> +{
>>>> +    struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +    if (state) {
>>>> +        bmc150_accel_chip_setup_interrupt(data, true);
>>>
>>> The above can return an error, ideally you'd handle it and pass 
>>> onwards.
>>>> +        if (!data->power_state)
>>>> +            bmc150_accel_set_mode(data,
>>>> +                    BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>> +                    0);
>>> This can also return an error.  Please check handling of errors for 
>>> these
>>> throughout the driver as I'm not going to mention any more!
>> OK
>>>> +        ++data->power_state;
>>>> +    } else {
>>>> +        if (--data->power_state == 0)
>>>> +            bmc150_accel_set_mode(data,
>>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>> +                    0);
>>>> +        bmc150_accel_chip_setup_interrupt(data, false);
>>>> +    }
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
>>>> +    .set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
>>>> +    .owner = THIS_MODULE,
>>>> +};
>>>> +
>>>> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
>>>> +                    struct bmc150_accel_data *data)
>>>> +{
>>>> +    const struct acpi_device_id *id;
>>>> +    struct device *dev;
>>>> +    struct gpio_desc *gpio;
>>>> +    int ret;
>>>> +
>>>> +    if (!client)
>>>> +        return -EINVAL;
>>>> +
>>>> +    dev = &client->dev;
>>>> +    if (!ACPI_HANDLE(dev))
>>>> +        return -ENODEV;
>>>> +
>>>> +    id = acpi_match_device(dev->driver->acpi_match_table, dev);
>>>> +    if (!id)
>>>> +        return -ENODEV;
>>>> +
>>>> +    /* data ready gpio interrupt pin */
>>>> +    gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
>>>> +    if (IS_ERR(gpio)) {
>>>> +        dev_err(dev, "acpi gpio get index failed\n");
>>>> +        return PTR_ERR(gpio);
>>>> +    }
>>>> +
>>>> +    ret = gpiod_direction_input(gpio);
>>>> +    if (ret)
>>>> +        return ret;
>>>> +
>>>> +    ret = gpiod_to_irq(gpio);
>>>> +
>>>> +    dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", 
>>>> desc_to_gpio(gpio), ret);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_probe(struct i2c_client *client,
>>>> +                  const struct i2c_device_id *id)
>>>> +{
>>>> +    struct bmc150_accel_data *data;
>>>> +    struct iio_dev *indio_dev;
>>>> +    struct iio_trigger *trig = NULL;
>>>> +    int ret;
>>>> +
>>>> +    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>>>> +    if (!indio_dev)
>>>> +        return -ENOMEM;
>>>> +
>>>> +    data = iio_priv(indio_dev);
>>>> +    i2c_set_clientdata(client, indio_dev);
>>>> +    data->client = client;
>>>> +
>>>> +    ret = bmc150_accel_chip_init(data);
>>>> +    if (ret < 0)
>>>> +        return ret;
>>>> +
>>>> +    mutex_init(&data->mutex);
>>>> +
>>>> +    indio_dev->dev.parent = &client->dev;
>>>> +    indio_dev->channels = bmc150_accel_channels;
>>>> +    indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
>>>> +    indio_dev->name = BMC150_ACCEL_DRV_NAME;
>>>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>>>> +    indio_dev->info = &bmc150_accel_info;
>>>> +
>>>> +    if (client->irq < 0)
>>>> +        client->irq = bmc150_accel_acpi_gpio_probe(client, data);
>>>> +
>>>> +    if (client->irq >= 0) {
>>> You could (and probably should given the devm_request_irq after this)
>>> use devm_iio_trigger_alloc and loose all the iio_trigger_free calls.
>> OK
>>>> +        trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
>>>> +                     indio_dev->id);
>>>> +        if (!trig)
>>>> +            return -ENOMEM;
>>>> +
>>>> +        data->trig_mode = true;
>>> I'm not sure on the necesity for an extra variable to store this
>>> given we can just use whether the trig variable != NULL for the same
>>> thing.  I guess it might make things ever so slightly easier to read...
>>>
>> OK
>>>> +
>>>> +        ret = devm_request_irq(&client->dev, client->irq,
>>>> +                       iio_trigger_generic_data_rdy_poll,
>>>> +                       IRQF_TRIGGER_RISING,
>>>> +                       BMC150_ACCEL_IRQ_NAME,
>>>> +                       trig);
>>>> +        if (ret) {
>>>> +            dev_err(&client->dev, "unable to request IRQ\n");
>>>> +            goto err_trigger_free;
>>>> +        }
>>>> +
>>>> +        trig->dev.parent = &client->dev;
>>>> +        trig->ops = &bmc150_accel_trigger_ops;
>>>> +        iio_trigger_set_drvdata(trig, indio_dev);
>>>> +        data->trig = trig;
>>>> +        indio_dev->trig = trig;
>>> This is dangerous.  Doing it like this will, IIRC leave the wrong
>>> reference counts for the trigger.  If you really, really want to do
>>> this then call iio_get_trigger on the trigger as well to increment
>>> the use count.  Prefered option is to leave the binding to userspace
>>> after the driver is probed.
>> OK
>>>> +
>>>> +        ret = iio_trigger_register(trig);
>>>> +        if (ret)
>>>> +            goto err_trigger_free;
>>>> +
>>>> +        ret = iio_triggered_buffer_setup(indio_dev,
>>>> +                         &iio_pollfunc_store_time,
>>>> +                         bmc150_accel_trigger_handler,
>>>> +                         NULL);
>>>> +        if (ret < 0) {
>>>> +            dev_err(&client->dev,
>>>> +                "iio triggered buffer setup failed\n");
>>>> +            goto err_trigger_unregister;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    ret = iio_device_register(indio_dev);
>>>> +    if (ret < 0) {
>>>> +        dev_err(&client->dev, "unable to register iio device\n");
>>>> +        goto err_buffer_cleanup;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +
>>>> +err_buffer_cleanup:
>>>> +    if (data->trig_mode)
>>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>>> +err_trigger_unregister:
>>>> +    if (data->trig_mode)
>>>> +        iio_trigger_unregister(trig);
>>>> +err_trigger_free:
>>>> +    if (data->trig_mode)
>>>> +        iio_trigger_free(trig);
>>>> +
>>>> +    return ret;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_remove(struct i2c_client *client)
>>>> +{
>>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(client);
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    iio_device_unregister(indio_dev);
>>>> +
>>>> +    if (data->trig_mode) {
>>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>>> +        iio_trigger_unregister(data->trig);
>>>> +        iio_trigger_free(data->trig);
>>>> +    }
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +    bmc150_accel_set_mode(data, 
>>>> BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +#ifdef CONFIG_PM_SLEEP
>>>> +static int bmc150_accel_suspend(struct device *dev)
>>>> +{
>>>> +    struct iio_dev *indio_dev = 
>>>> i2c_get_clientdata(to_i2c_client(dev));
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static int bmc150_accel_resume(struct device *dev)
>>>> +{
>>>> +    struct iio_dev *indio_dev = 
>>>> i2c_get_clientdata(to_i2c_client(dev));
>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>> +
>>>> +    mutex_lock(&data->mutex);
>>>> +    if (data->power_state)
>>>> +        bmc150_accel_set_mode(data, 
>>>> BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
>>>> +    mutex_unlock(&data->mutex);
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
>>>> +             bmc150_accel_resume);
>>>> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
>>>> +#else
>>>> +#define BMC150_ACCEL_PM_OPS NULL
>>>> +#endif
>>>> +
>>>> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
>>>> +    {"BSBA0150", 0},
>>>> +    {"BMC150A", 0},
>>>> +    { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
>>>> +
>>>> +static const struct i2c_device_id bmc150_accel_id[] = {
>>>> +    {"bmc150_accel", 0},
>>>> +    {}
>>>> +};
>>>> +
>>>> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
>>>> +
>>>> +static struct i2c_driver bmc150_accel_driver = {
>>>> +    .driver = {
>>>> +        .name    = BMC150_ACCEL_DRV_NAME,
>>>> +        .acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
>>>> +        .pm    = BMC150_ACCEL_PM_OPS,
>>>> +    },
>>>> +    .probe        = bmc150_accel_probe,
>>>> +    .remove        = bmc150_accel_remove,
>>>> +    .id_table    = bmc150_accel_id,
>>>> +};
>>>> +module_i2c_driver(bmc150_accel_driver);
>>>> +
>>>> +MODULE_AUTHOR("Srinivas Pandruvada 
>>>> <srinivas.pandruvada@linux.intel.com>");
>>>> +MODULE_LICENSE("GPL v2");
>>>> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
>>>>
>>>
>>>
>> Thanks,
>> Srinivas
>
>


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-29 14:27       ` Srinivas Pandruvada
@ 2014-06-29 14:42         ` Jonathan Cameron
  2014-07-07 14:36           ` Mark Brown
  0 siblings, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2014-06-29 14:42 UTC (permalink / raw)
  To: Srinivas Pandruvada; +Cc: linux-iio, Mark Brown

On 29/06/14 15:27, Srinivas Pandruvada wrote:
>
> On 06/29/2014 04:12 AM, Jonathan Cameron wrote:
>> On 23/06/14 02:22, Srinivas Pandruvada wrote:
>>> Hi Jonathan,
>>>
>>> Thanks for the review. I have one question on using power_mode ABI.
>>> The current documentation says
>>> "
>>> What:           /sys/.../iio:deviceX/in_accelX_power_mode
>>> KernelVersion:  3.11
>>> Contact:        linux-iio@vger.kernel.org
>>> Description:
>>>                  Specifies the chip power mode.
>>>                  low_noise: reduce noise level from ADC,
>>>                  low_power: enable low current consumption.
>>>                  For a list of available output power modes read
>>>                  in_accel_power_mode_available.
>>>
>>> "
>>>
>>> Here I feel power mode is defined for various modes of operation once powered on,
>>> but not the way I have used for "on" and "off"
>>> For power and performance, when for simply using raw mode, we may need to
>>> keep the sensor on for extended period of time and other case power down after
>>> taking one sample.
>>>
>>> So what do you thing about
>>> /sys/.../iio:deviceX/in_XXX_power_state
>>> with possible values
>>> "on", "off" "sleep" "deep_sleep"  etc,
>> This comes up from time to time. I personally would really prefer if this stuff
>> was all handled by core kernel support rather than being implemented out in
>> a given subsystem.
>>
>> We do have the runtime power management approach which goes some way towards this
>> but doesn't (IIRC) provide the level of 'hints' you are talking about here.
>>
>> I wonder if instead of power state we could represent this as say
>> latency and hence a numeric value of the number of seconds required to take a measurement
>> on an attempt to read?
>>
>> So in this case,
>>
>> on -> 0 (or more accurate if possible)
>> off -> some large number (also use runtime pm in this state to allow the regulators
>> to power down etc).
>> sleep -> 0.1 perhaps
>> deepsleep -> 0.5
>>
>> In this particular part I suspect the dominant element will be how long it takes to write the
>> setup back to the device so anything here would be estimates.
>>
>> Still extends more naturally than defining an ever increasing set of labels to different
>> modes?  What do you think?
> Yes, labels are painful to handle. May be we should call latency_tolerance, similar to the concept of PCI LTR.
That is a better name.  At some point I'd like drivers to report their trigger latency
(e.g. how long they take to actually take a measurement after a trigger - negative if we have a delayed dataready
  signal...).  Best if this has a more specific name.

> The driver if exports this attribute, it can use latency_tolerance hint to decide, how deeper the power state it
> can enter. If userspace sets this value to 0, then driver should stay awake. The other values are used by
> driver based on its sleep/wakeup latencies. I think units should be in milli-seconds.
Sounds good.  My thoughts on seconds is that we can run this through the normal info_mask elements as a shared_by_all
as arguably it is actually about the channels.  There we have other attributes defined in seconds and the capacity to
handle much wider ranges of values...

Now if we are matching against existing interfaces elsewhere in the kernel I have no problem
at all with using seconds.

I wonder how far we can take this concept...

If we are dependent on regulators to leave certain states, do we have access to how long
they take to start up?  What about bringing buses up...

Cc'd Mark Brown on the basis he knows all sorts of hideous corners of the kernel way
better than me ;)

Mark - what do you know about that corresponds to our usecase here.  We have devices
that can go into multiple levels of sleep with different latencies to restart.
Whilst the reason these exist is to save power, for IIO we often more care about
how long they take to grab data from the different power states.  Hence
the proposal is to add a sysfs attribute to control latency_tolerance.
The drivers then get to do what they like to meet that requirement.

Is there anything similar that you know of elsewhere in kernel?



>
> Thanks,
> Srinivas
>>>
>>> Others inline
>>>
>>> On 06/22/2014 07:23 AM, Jonathan Cameron wrote:
>>>> On 20/06/14 19:12, Srinivas Pandruvada wrote:
>>>>> This change implements BMC150 accelerometer driver. A BMC150 package
>>>>> consist of a compass and an accelerometer. This driver only implements
>>>>> accelerometer part.
>>>>> Spec downloaded from:
>>>>> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf
>>>>>
>>>>> This sensor chip supports many advanced features, but this driver
>>>>> implements minimum feature set which is a must to be useful.
>>>>> This driver can be enhanced incrementally.
>>>>> If the sensor vendor wants to update full featured version, they
>>>>> can substitute or enhance this driver when they get chance.
>>>>>
>>>>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>>>>
>>>> Various bits inline.
>>>>
>>>> The trigger type is unusual, but if useful that is fine. However
>>>> I think with a few little changes you can loose the requirement that
>>>> it is used to drive this device, giving a nicer, more correct solution.
>>>>
>>>> Also, setting indio_dev->trig is generally a bad idea.
>>>>
>>>> Jonathan
>>>>> ---
>>>>>   drivers/iio/accel/Kconfig        |  13 +
>>>>>   drivers/iio/accel/Makefile       |   1 +
>>>>>   drivers/iio/accel/bmc150-accel.c | 947 +++++++++++++++++++++++++++++++++++++++
>>>>>   3 files changed, 961 insertions(+)
>>>>>   create mode 100644 drivers/iio/accel/bmc150-accel.c
>>>>>
>>>>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>>>>> index 12addf2..5704d6b 100644
>>>>> --- a/drivers/iio/accel/Kconfig
>>>>> +++ b/drivers/iio/accel/Kconfig
>>>>> @@ -17,6 +17,19 @@ config BMA180
>>>>>         To compile this driver as a module, choose M here: the
>>>>>         module will be called bma180.
>>>>>
>>>>> +config BMC150_ACCEL
>>>>> +    tristate "Bosch BMC150 Accelerometer Driver"
>>>>> +    depends on I2C
>>>>> +    select IIO_BUFFER
>>>>> +    select IIO_TRIGGERED_BUFFER
>>>>> +    help
>>>>> +      Say yes here to build support for the Bosch BMC150 accelerometer.
>>>>> +      Currently this only supports the device via an i2c interface.
>>>>> +
>>>>> +      This is a combo module with both accelerometer and magnetometer.
>>>>> +      This driver is only implementing accelerometer part, which has
>>>>> +      its own address and register map.
>>>>> +
>>>>>   config HID_SENSOR_ACCEL_3D
>>>>>       depends on HID_SENSOR_HUB
>>>>>       select IIO_BUFFER
>>>>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>>>>> index 6578ca1..a593996 100644
>>>>> --- a/drivers/iio/accel/Makefile
>>>>> +++ b/drivers/iio/accel/Makefile
>>>>> @@ -4,6 +4,7 @@
>>>>>
>>>>>   # When adding new entries keep the list in alphabetical order
>>>>>   obj-$(CONFIG_BMA180) += bma180.o
>>>>> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>>>>>   obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>>>>   obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>>>>>   obj-$(CONFIG_KXSD9)    += kxsd9.o
>>>>> diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
>>>>> new file mode 100644
>>>>> index 0000000..330a3d7
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/accel/bmc150-accel.c
>>>>> @@ -0,0 +1,947 @@
>>>>> +/*
>>>>> + * BMC150 3-axis accelerometer 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/module.h>
>>>>> +#include <linux/i2c.h>
>>>>> +#include <linux/interrupt.h>
>>>>> +#include <linux/delay.h>
>>>>> +#include <linux/slab.h>
>>>>> +#include <linux/acpi.h>
>>>>> +#include <linux/gpio/consumer.h>
>>>>> +#include <linux/iio/iio.h>
>>>>> +#include <linux/iio/sysfs.h>
>>>>> +#include <linux/iio/buffer.h>
>>>>> +#include <linux/iio/trigger.h>
>>>>> +#include <linux/iio/trigger_consumer.h>
>>>>> +#include <linux/iio/triggered_buffer.h>
>>>>> +
>>>>> +#define BMC150_ACCEL_DRV_NAME            "bmc150_accel"
>>>>> +#define BMC150_ACCEL_IRQ_NAME "bmc150_accel_event"
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_CHIP_ID        0x00
>>>>> +#define BMC150_ACCEL_CHIP_ID_VAL        0xFA
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_PMU_LPW        0x11
>>>>> +#define BMC150_ACCEL_PMU_SLP_MASK        0xE0
>>>>> +#define BMC150_ACCEL_PMU_SLP_SHIFT        5
>>>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK    0x17
>>>>> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT    1
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_PMU_RANGE        0x0F
>>>>> +
>>>>> +#define BMC150_ACCEL_DEF_RANGE_2G        0x03
>>>>> +#define BMC150_ACCEL_DEF_RANGE_4G        0x05
>>>>> +#define BMC150_ACCEL_DEF_RANGE_8G        0x08
>>>>> +#define BMC150_ACCEL_DEF_RANGE_16G        0x0C
>>>>> +
>>>>> +/* Default BW: 125Hz */
>>>>> +#define BMC150_ACCEL_REG_PMU_BW            0x10
>>>>> +#define BMC150_ACCEL_DEF_BW            125
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_MAP_0        0x19
>>>>> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE    BIT(2)
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_RST_LATCH        0x21
>>>>> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET    0x80
>>>>> +#define BMC150_ACCEL_INT_MODE_LATCH_INT        0x0F
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_EN_0        0x16
>>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X        BIT(0)
>>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y        BIT(1)
>>>>> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z        BIT(2)
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_OUT_CTRL        0x20
>>>>> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL    BIT(0)
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_5            0x27
>>>>> +#define BMC150_ACCEL_SLOPE_DUR_MASK        0x03
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_INT_6            0x28
>>>>> +#define BMC150_ACCEL_SLOPE_THRES_MASK        0xFF
>>>>> +
>>>>> +#define BMC150_ACCEL_REG_XOUT_L            0x02
>>>>> +#define BMC150_ACCEL_REG_XOUT_H            0x03
>>>>> +#define BMC150_ACCEL_REG_YOUT_L            0x04
>>>>> +#define BMC150_ACCEL_REG_YOUT_H            0x05
>>>>> +#define BMC150_ACCEL_REG_ZOUT_L            0x06
>>>>> +#define BMC150_ACCEL_REG_ZOUT_H            0x07
>>>>> +
>>>>> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS    100
>>>>> +
>>>>> +/* Slope duration in terms of number of samples */
>>>>> +#define BMC150_ACCEL_DEF_SLOPE_DURATION        2
>>>>> +/* in terms of multiples of g's/LSB, based on range */
>>>>> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD    5
>>>>> +
>>>>> +/* Sleep Duration values */
>>>>> +#define BMC150_ACCEL_SLEEP_500_MICRO        0x05
>>>>> +#define BMC150_ACCEL_SLEEP_1_MS            0x06
>>>>> +#define BMC150_ACCEL_SLEEP_2_MS            0x07
>>>>> +#define BMC150_ACCEL_SLEEP_4_MS            0x08
>>>>> +#define BMC150_ACCEL_SLEEP_6_MS            0x09
>>>>> +#define BMC150_ACCEL_SLEEP_10_MS        0x0A
>>>>> +#define BMC150_ACCEL_SLEEP_25_MS        0x0B
>>>>> +#define BMC150_ACCEL_SLEEP_50_MS        0x0C
>>>>> +#define BMC150_ACCEL_SLEEP_100_MS        0x0D
>>>>> +#define BMC150_ACCEL_SLEEP_500_MS        0x0E
>>>>> +#define BMC150_ACCEL_SLEEP_1_SEC        0x0F
>>>>> +
>>>>> +/* Sleep Modes */
>>>>> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL        0x00
>>>>> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND    0x01
>>>>> +#define BMC150_ACCEL_SLEEP_MODE_LPM        0x03
>>>>> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND        0x04
>>>>> +
>>>>> +struct bmc150_accel_data {
>>>>> +    struct i2c_client *client;
>>>>> +    struct iio_trigger *trig;
>>>> Odd spacing on next line. As suggested later, I'm not
>>>> certain this adds much.
>>>>> +    bool    trig_mode;
>>>>> +    struct mutex mutex;
>>>>> +    s16 buffer[3];
>>>> This is not big enough to take the timestamp (as required
>>>> by the iio_push_to_buffers_with_timestamp call).
>>>>> +    int power_state;
>>>>> +    u8 bw_bits;
>>>>
>>>> So at the moment we have no control over these?
>>>> Note that these correspond directly (I think) to our ROC type
>>>> events though they allow both the change and the length over
>>>> which it is to be measured to be adjusted.
>>>>
>>>> Looking again, I see you are using these as a trigger. A perfectly
>>>> acceptable option.  I have at times wondered if we can come up
>>>> with a clean and generic way to do just that, when otherwise reporting
>>>> these as events.  Not actually worked out how yet though!
>>> I thought of using events, but I don't want user space have to take care to enable and process events.
>>> This keeps user space simple.
>>> May be we should allow current threshold and period settings non event specific, so that
>>> they can be used along with triggers. When corresponding event is enabled, then they
>>> will generate events.
>>>>> +    u32 slope_dur;
>>>>> +    u32 slope_thres;
>>>>> +    u32 range;
>>>>> +};
>>>>> +
>>>>> +enum bmc150_accel_axis {
>>>>> +    AXIS_X,
>>>>> +    AXIS_Y,
>>>>> +    AXIS_Z,
>>>>> +};
>>>>> +
>>>>> +static const struct {
>>>>> +    int val;
>>>>> +    int val2;
>>>>> +    int bw_bits;
>>>> I know it would take more lines, but I think I'd prefer to see this formatted
>>>> as one per line rather than 2.  Easier to immeidately tell if there is
>>>> anything 'unusual' in the form of the values.
>>> OK
>>>>> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 0x09},
>>>>> +                     {31, 250000, 0x0A}, {62, 500000, 0x0B},
>>>>> +                     {125, 0, 0x0C}, {250, 0, 0x0D},
>>>>> +                     {500, 0, 0x0E}, {1000, 0, 0x0F} };
>>>>> +
>>>>> +static const struct {
>>>>> +    int bw_bits;
>>>>> +    int msec;
>>>> Same here, 1 per line makes for more lines of code, but does actually aid
>>>> readability (slightly!)
>>> OK
>>>>> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 16},
>>>>> +                     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
>>>>> +                     {0x0E, 1}, {0x0F, 1} };
>>>>> +
>>>>> +static const struct {
>>>>> +    int scale;
>>>>> +    int range;
>>>>> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
>>>>> +                 {19122, BMC150_ACCEL_DEF_RANGE_4G},
>>>>> +                 {38344, BMC150_ACCEL_DEF_RANGE_8G},
>>>>> +                 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
>>>>> +
>>>>> +
>>>>> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
>>>>> +{
>>>>> +    int ret;
>>>> Why not just drop this variable and reutrn directly from each
>>>> case statement?
>>> OK
>>>>> +
>>>>> +    switch (sleep_dur_us) {
>>>>> +    case 0:
>>>>> +        ret = 0;
>>>>> +        break;
>>>>> +    case 500:
>>>>> +        ret = BMC150_ACCEL_SLEEP_500_MICRO;
>>>>> +        break;
>>>>> +    case 1000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_1_MS;
>>>>> +        break;
>>>>> +    case 2000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_2_MS;
>>>>> +        break;
>>>>> +    case 4000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_4_MS;
>>>>> +        break;
>>>>> +    case 6000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_6_MS;
>>>>> +        break;
>>>>> +    case 10000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_10_MS;
>>>>> +        break;
>>>>> +    case 25000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_25_MS;
>>>>> +        break;
>>>>> +    case 50000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_50_MS;
>>>>> +        break;
>>>>> +    case 100000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_100_MS;
>>>>> +        break;
>>>>> +    case 500000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_500_MS;
>>>>> +        break;
>>>>> +    case 1000000:
>>>>> +        ret = BMC150_ACCEL_SLEEP_1_SEC;
>>>>> +        break;
>>>>> +    default:
>>>>> +        ret = -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int mode,
>>>>> +                 int dur_us)
>>>>> +{
>>>>> +    int ret;
>>>>> +    u8 lpw_bits = 0;
>>>>> +    int dur;
>>>>> +
>>>>> +    dur = bmc150_accel_convert_sleep_value(dur_us);
>>>>> +    if (dur < 0)
>>>>> +        return dur;
>>>>> +
>>>>> +    lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
>>>>> +    lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>>>>> +
>>>>> +    dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>>>>> +
>>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                    BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_convert_freq_to_bit(int val)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>>>> +        if (bmc150_accel_samp_freq_table[i].val == val)
>>>>> +            return bmc150_accel_samp_freq_table[i].bw_bits;
>>>>> +    }
>>>>> +
>>>>> +    return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val)>
>>>>  +{
>>>>> +    int ret;
>>>>> +    int bw_bits;
>>>>> +
>>>>> +    bw_bits = bmc150_accel_convert_freq_to_bit(val);
>>>>> +    if (bw_bits < 0)
>>>>> +        return bw_bits;
>>>>> +
>>>>> +    ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_PMU_BW,
>>>>> +                    bw_bits);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error writing pmu_bw\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    data->bw_bits = bw_bits;
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
>>>>> +{
>>>>> +    int ret;
>>>>> +
>>>>> +    ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_CHIP_ID);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev,
>>>>> +            "Error:BMC150_ACCEL_REG_CHIP_ID\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
>>>>> +    if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
>>>>> +        dev_err(&data->client->dev, "invalid chip %x\n", ret);
>>>>> +        return -ENODEV;
>>>>> +    }
>>>>> +
>>>>> +    /* Set Bandwidth */
>>>>> +    ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
>>>>> +    if (ret < 0)
>>>>> +        return ret;
>>>>> +
>>>>> +    /* Set Default Range */
>>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>>>> +                    BMC150_ACCEL_DEF_RANGE_4G);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev,
>>>>> +                    "Error writing pmu_range\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +    data->range = BMC150_ACCEL_DEF_RANGE_4G;
>>>>> +
>>>>> +    data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
>>>>> +    data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
>>>>> +
>>>>> +    ret = bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_chip_setup_interrupt(struct bmc150_accel_data *data,
>>>>> +                      bool status)
>>>>> +{
>>>>> +    int ret;
>>>>> +
>>>>> +    /* Enable/Disable INT1 mapping */
>>>>> +    ret = i2c_smbus_read_byte_data(data->client,
>>>>> +                       BMC150_ACCEL_REG_INT_MAP_0);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error read reg_int_map0\n");
>>>>> +        return ret;
>>>>> +    }
>>>> There is actually very little overlap in here between the enable and disable
>>>> code.  I wonder if it would not be cleaner to have them as separate
>>>> functions?  Not that fussed either way however!
>>> OK
>>>>> +    if (status)
>>>>> +        ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>>>> +    else
>>>>> +        ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
>>>>> +
>>>>> +
>>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                    BMC150_ACCEL_REG_INT_MAP_0,
>>>>> +                    ret);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error write reg_int_map0\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error write reg_rst_latch\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    /* Enable/Disable slope interrupts */
>>>>> +    if (status) {
>>>>> +        /* Set slope duration (no of samples) */
>>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                        BMC150_ACCEL_REG_INT_5,
>>>>> +                        data->slope_dur);
>>>>> +        if (ret < 0) {
>>>>> +            dev_err(&data->client->dev, "Error write eg_int_5\n");
>>>>> +            return ret;
>>>>> +        }
>>>>> +
>>>>> +        /* Set slope thresholds */
>>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                        BMC150_ACCEL_REG_INT_6,
>>>>> +                        data->slope_thres);
>>>>> +        if (ret < 0) {
>>>>> +            dev_err(&data->client->dev, "Error write reg_int_6\n");
>>>>> +            return ret;
>>>>> +        }
>>>>> +
>>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_X |
>>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Y |
>>>>> +                        BMC150_ACCEL_INT_EN_BIT_SLP_Z);
>>>>> +        if (ret < 0) {
>>>>> +            dev_err(&data->client->dev, "Error wr reg_int_en0\n");
>>>>> +            return ret;
>>>>> +        }
>>>>> +
>>>>> +    } else
>>>>> +        ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                        BMC150_ACCEL_REG_INT_EN_0,
>>>>> +                        0);
>>>>> +
>>>> Whilst valid, would look more normal to handle the ret inside the else
>>>> statement.
>>> OK
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error writing reg_int_en0\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
>>>>> +{
>>>>> +    int ret;
>>>>> +
>>>>> +    /* Set latched mode interrupt and clear any latched interrupt */
>>>>> +    ret = i2c_smbus_write_byte_data(data->client,
>>>>> +                    BMC150_ACCEL_REG_INT_RST_LATCH,
>>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_INT |
>>>>> +                    BMC150_ACCEL_INT_MODE_LATCH_RESET);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev, "Error writing reg_rst_latch\n");
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int *val,
>>>>> +                   int *val2)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>>>>> +        if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
>>>>> +            *val = bmc150_accel_samp_freq_table[i].val;
>>>>> +            *val2 = bmc150_accel_samp_freq_table[i].val2;
>>>>> +            return IIO_VAL_INT_PLUS_MICRO;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>> +    return -EINVAL;
>>>>> +}
>>>>> +
>>>> I am a unconvinced that this wrapper really adds anything, and would be tempted
>>>> to move it inline, perhaps with a macro for the register address from
>>>> axis conversion.
>>> OK
>>>>> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, int axis)
>>>>> +{
>>>>> +    u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;
>>>>> +    int ret;
>>>>> +
>>>>> +    ret = i2c_smbus_read_word_data(data->client, reg);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&data->client->dev,
>>>>> +            "failed to read accel_%c registers\n", 'x' + axis);
>>>>> +        return ret;
>>>>> +    }
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
>>>>> +{
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
>>>>> +        if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
>>>>> +            return bmc150_accel_sample_upd_time[i].msec;
>>>>> +
>>>> No need for a blank line here.
>>> OK
>>>>> +    }
>>>>> +
>>>>> +    return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
>>>>> +{
>>>>> +    int ret, i;
>>>>> +
>>>>> +    for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
>>>>> +        if (bmc150_accel_scale_table[i].scale == val) {
>>>>> +            ret = i2c_smbus_write_byte_data(
>>>>> +                    data->client,
>>>>> +                    BMC150_ACCEL_REG_PMU_RANGE,
>>>>> +                    bmc150_accel_scale_table[i].range);
>>>>> +            if (ret < 0) {
>>>>> +                dev_err(&data->client->dev,
>>>>> +                    "Error writing pmu_range\n");
>>>>> +                return ret;
>>>>> +            }
>>>>> +            data->range = bmc150_accel_scale_table[i].range;
>>>>> +            return 0;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>> +    return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
>>>>> +                 struct iio_chan_spec const *chan,
>>>>> +                 int *val, int *val2, long mask)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +    int ret;
>>>>> +
>>>>> +    switch (mask) {
>>>>> +    case IIO_CHAN_INFO_RAW:
>>>>> +        mutex_lock(&data->mutex);
>>>>> +        if (iio_buffer_enabled(indio_dev))
>>>>> +            ret = -EBUSY;
>>>>> +        else {
>>>>   I think I'd factor this out to a function for neatness sake.
>>> OK
>>>>> +            int sleep_val;
>>>>> +            if (!data->power_state) {
>>>>> +                ret = bmc150_accel_set_mode(data,
>>>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>>> +                        0);
>>>>> +                if (ret < 0) {
>>>>> +                    mutex_unlock(&data->mutex);
>>>>> +                    return ret;
>>>>> +                }
>>>>> +                sleep_val =
>>>>> +                    bmc150_accel_get_startup_times(data);
>>>>> +                if (sleep_val < 20)
>>>>> +                    usleep_range(sleep_val * 1000, 20000);
>>>>> +                else
>>>>> +                    msleep_interruptible(sleep_val);
>>>>> +            }
>>>>> +            ++data->power_state;
>>>>> +            ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
>>>> handle possible errors here
>>>>> +            if (--data->power_state == 0)
>>>>> +                bmc150_accel_set_mode(data,
>>>>> +                        BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>>> +                        0);
>>>>> +                /* Nothing can be done if above call fails
>>>> Whilst true, it's still worth passing the error on to userspace so it is aware
>>>> something has gone wrong.
>>> OK
>>>>
>>>>> +        }
>>>>> +        mutex_unlock(&data->mutex);
>>>>> +        if (ret < 0)
>>>>> +            return ret;
>>>>> +
>>>>> +        *val = sign_extend32(ret >> 4, 11);
>>>>> +        return IIO_VAL_INT;
>>>>> +    case IIO_CHAN_INFO_SCALE:
>>>>> +        *val = 0;
>>>>> +        switch (data->range) {
>>>>> +        case BMC150_ACCEL_DEF_RANGE_2G:
>>>>> +            *val = 9610;
>>>> val2?
>>> Yes
>>>>> +            break;
>>>>> +        case BMC150_ACCEL_DEF_RANGE_4G:
>>>>> +            *val2 = 19122;
>>>>> +            break;
>>>>> +        case BMC150_ACCEL_DEF_RANGE_8G:
>>>>> +            *val2 = 38344;
>>>>> +            break;
>>>>> +        case BMC150_ACCEL_DEF_RANGE_16G:
>>>>> +            *val2 = 77057;
>>>>> +            break;
>>>>> +        default:
>>>>> +            return -EINVAL;
>>>>> +        }
>>>>> +        return IIO_VAL_INT_PLUS_MICRO;
>>>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>>>> +        mutex_lock(&data->mutex);
>>>>> +        ret = bmc150_accel_get_bw(data, val, val2);
>>>>> +        mutex_unlock(&data->mutex);
>>>>> +        return ret;
>>>>> +    default:
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
>>>>> +                  struct iio_chan_spec const *chan,
>>>>> +                  int val, int val2, long mask)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +    int ret;
>>>>> +
>>>>> +    switch (mask) {
>>>>> +    case IIO_CHAN_INFO_SAMP_FREQ:
>>>>> +        mutex_lock(&data->mutex);
>>>>> +        ret = bmc150_accel_set_bw(data, val);
>>>> The available definitely has stuff in val2.  Should you not be verifying that
>>>> as well?
>>> The val field is unique, so I thought not checking val2, for fractions. Some user spaces
>>> dropping precision when they read write, failing fraction comparisons.
>>> But I will add back.
>>>>> + mutex_unlock(&data->mutex);
>>>>> +        break;
>>>>> +    case IIO_CHAN_INFO_SCALE:
>>>>> +        if (val)
>>>>> +            return -EINVAL;
>>>>> +        mutex_lock(&data->mutex);
>>>>> +        ret = bmc150_accel_set_scale(data, val2);
>>>>> +        mutex_unlock(&data->mutex);
>>>>> +        return ret;
>>>>> +    default:
>>>>> +        ret = -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
>>>> Multiline comment syntax.  Whilst documented it's also not documented as
>>>> having these options, so please add the docs.  I wonder if we want something
>>>> more informative than on / off.  Perhaps startup_fast vs startup_slow?
>>>> Anyhow, propose the ABI addition and we'll see what people think..
>>> I don't expect this comment to be there in final version, but to raise question
>>> whether "power_mode" is correct to use. I see only one driver is using this for
>>> low_noise, low_power. No one is using for ON/OFF type control
>> True.  We've killed off a good few of these in the past, primarily because
>> doing it at a subsystem level is totally wrong.  Perhaps arguably the above
>> latency suggestion makes it more subsystem relevant than dictating by
>> 'power usage'.  Not sure...
>>>>> + * this makes lot of sense when no buffered mode available because
>>>>> + * of lake of interrupt configuration. If user mode calls to read raw
>>>> lack
>>>>> + * value with a very high frequency, instead of turn on/off for each
>>>>> + * read, keeping system on by setting power mode to "on" will give
>>>>> + * better performance.
>>>>> + */
>>>>> +static const char * const bmc150_accel_power_modes[] = {
>>>>> +    "off",
>>>>> +    "on",
>>>>> +};
>>>>> +
>>>>> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
>>>>> +                       const struct iio_chan_spec *chan)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    return data->power_state;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
>>>>> +                       const struct iio_chan_spec *chan,
>>>>> +                       unsigned int mode)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +    int ret = 0;
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +    if (mode) {
>>>>> +        if (!data->power_state)
>>>>> +            ret = bmc150_accel_set_mode(data,
>>>>> +                        BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>>> +                        0);
>>>>> +        ++data->power_state;
>>>>> +    } else {
>>>>> +        if (--data->power_state == 0)
>>>>> +            ret = bmc150_accel_set_mode(data,
>>>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>>> +                    0);
>>>>> +    }
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
>>>>> +                   struct iio_trigger *trig)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    if (data->trig != trig)
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>> Why do you need to validate this one?  Ah, the interrupt is cleared
>>>> in the buffer handler.  No need to do that.  Just have the clear
>>>> in the trigger try_reenable callback (unless I am missing something
>>>> odd in the hardware of course!)
>>> OK
>>>>> +
>>>>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
>>>>> +        "7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
>>>>> +
>>>>> +static struct attribute *bmc150_accel_attributes[] = {
>>>>> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
>>>>> +    NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group bmc150_accel_attrs_group = {
>>>>> +    .attrs = bmc150_accel_attributes,
>>>>> +};
>>>>> +
>>>>> +static const struct iio_enum bmc150_accel_power_mode_enum = {
>>>>> +    .items = bmc150_accel_power_modes,
>>>>> +    .num_items = ARRAY_SIZE(bmc150_accel_power_modes),
>>>>> +    .get = bmc150_accel_get_power_mode,
>>>>> +    .set = bmc150_accel_set_power_mode,
>>>>> +};
>>>>> +
>>>>> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
>>>>> +    IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
>>>>> +    IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
>>>> Documentation?
>>>>> +    { },
>>>>> +};
>>>>> +
>>>>> +#define BMC150_ACCEL_CHANNEL(_axis) {                    \
>>>>> +    .type = IIO_ACCEL,                        \
>>>>> +    .modified = 1,                            \
>>>>> +    .channel2 = IIO_MOD_##_axis,                    \
>>>>> +    .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),            \
>>>>> +    .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |        \
>>>>> +                BIT(IIO_CHAN_INFO_SAMP_FREQ),        \
>>>> Given you have only one type, I think conventionally we'd have samp_freq
>>>> as a shared_by_all, but this is perfectly valid under the ABI if you
>>>> prefer it like this (not documented though, so you'll want to add relevant
>>>> lines to Documentation/ABI/testing/sysfs-bus-iio.
>>>>
>>> I will check.
>>>>> +    .scan_index = AXIS_##_axis,                    \
>>>>> +    .scan_type = {                            \
>>>>> +        .sign = 's',                        \
>>>>> +        .realbits = 12,                        \
>>>>> +        .storagebits = 16,                    \
>>>>> +        .shift = 4,                        \
>>>>> +    },                                \
>>>>> +    .ext_info = bmc150_accel_ext_info,                \
>>>>> +}
>>>>> +
>>>>> +static const struct iio_chan_spec bmc150_accel_channels[] = {
>>>>> +    BMC150_ACCEL_CHANNEL(X),
>>>>> +    BMC150_ACCEL_CHANNEL(Y),
>>>>> +    BMC150_ACCEL_CHANNEL(Z),
>>>>> +    IIO_CHAN_SOFT_TIMESTAMP(3),
>>>>> +};
>>>>> +
>>>>> +static const struct iio_info bmc150_accel_info = {
>>>>> +    .attrs            = &bmc150_accel_attrs_group,
>>>>> +    .read_raw        = bmc150_accel_read_raw,
>>>>> +    .write_raw        = bmc150_accel_write_raw,
>>>>> +    .validate_trigger    = bmc150_validate_trigger,
>>>>> +    .driver_module        = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
>>>>> +{
>>>>> +    struct iio_poll_func *pf = p;
>>>>> +    struct iio_dev *indio_dev = pf->indio_dev;
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +    int bit, ret, i = 0;
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +
>>>>> +    for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>>>>> +             indio_dev->masklength) {
>>>>> +        ret = bmc150_accel_get_acc_reg(data, bit);
>>>>> +        if (ret < 0) {
>>>>> +            bmc150_accel_chip_ack_intr(data);
>>>>> +            mutex_unlock(&data->mutex);
>>>>> +            goto err;
>>>>> +        }
>>>>> +        data->buffer[i++] = ret;
>>>>> +    }
>>>>> +
>>>>> +    bmc150_accel_chip_ack_intr(data);
>>>>
>>>> Is a read of the data needed to clear this interrupt?  If not
>>>> have a try_reenable callback with the interrupt acknowledge in
>>>> it and it should be fine to use this buffer with any trigger
>>>> and any trigger with any buffer.
>>>>
>>> OK
>>>>> +
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
>>>>> +                       pf->timestamp);
>>>> buffer isn't large enough.  Sometimes I regret that we introduced the function
>>>> in the first place... Semantics are odd and that causes so many bugs
>>>> like this one.
>>> Definitely a bug.
>>>
>>>>> + iio_trigger_notify_done(indio_dev->trig);
>>>>> +
>>>>> +    return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_data_rdy_trigger_set_state(struct iio_trigger *trig,
>>>>> +                           bool state)
>>>>> +{
>>>>> +    struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +    if (state) {
>>>>> +        bmc150_accel_chip_setup_interrupt(data, true);
>>>>
>>>> The above can return an error, ideally you'd handle it and pass onwards.
>>>>> +        if (!data->power_state)
>>>>> +            bmc150_accel_set_mode(data,
>>>>> +                    BMC150_ACCEL_SLEEP_MODE_NORMAL,
>>>>> +                    0);
>>>> This can also return an error.  Please check handling of errors for these
>>>> throughout the driver as I'm not going to mention any more!
>>> OK
>>>>> +        ++data->power_state;
>>>>> +    } else {
>>>>> +        if (--data->power_state == 0)
>>>>> +            bmc150_accel_set_mode(data,
>>>>> +                    BMC150_ACCEL_SLEEP_MODE_SUSPEND,
>>>>> +                    0);
>>>>> +        bmc150_accel_chip_setup_interrupt(data, false);
>>>>> +    }
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
>>>>> +    .set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
>>>>> +    .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
>>>>> +                    struct bmc150_accel_data *data)
>>>>> +{
>>>>> +    const struct acpi_device_id *id;
>>>>> +    struct device *dev;
>>>>> +    struct gpio_desc *gpio;
>>>>> +    int ret;
>>>>> +
>>>>> +    if (!client)
>>>>> +        return -EINVAL;
>>>>> +
>>>>> +    dev = &client->dev;
>>>>> +    if (!ACPI_HANDLE(dev))
>>>>> +        return -ENODEV;
>>>>> +
>>>>> +    id = acpi_match_device(dev->driver->acpi_match_table, dev);
>>>>> +    if (!id)
>>>>> +        return -ENODEV;
>>>>> +
>>>>> +    /* data ready gpio interrupt pin */
>>>>> +    gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);
>>>>> +    if (IS_ERR(gpio)) {
>>>>> +        dev_err(dev, "acpi gpio get index failed\n");
>>>>> +        return PTR_ERR(gpio);
>>>>> +    }
>>>>> +
>>>>> +    ret = gpiod_direction_input(gpio);
>>>>> +    if (ret)
>>>>> +        return ret;
>>>>> +
>>>>> +    ret = gpiod_to_irq(gpio);
>>>>> +
>>>>> +    dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_probe(struct i2c_client *client,
>>>>> +                  const struct i2c_device_id *id)
>>>>> +{
>>>>> +    struct bmc150_accel_data *data;
>>>>> +    struct iio_dev *indio_dev;
>>>>> +    struct iio_trigger *trig = NULL;
>>>>> +    int ret;
>>>>> +
>>>>> +    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>>>>> +    if (!indio_dev)
>>>>> +        return -ENOMEM;
>>>>> +
>>>>> +    data = iio_priv(indio_dev);
>>>>> +    i2c_set_clientdata(client, indio_dev);
>>>>> +    data->client = client;
>>>>> +
>>>>> +    ret = bmc150_accel_chip_init(data);
>>>>> +    if (ret < 0)
>>>>> +        return ret;
>>>>> +
>>>>> +    mutex_init(&data->mutex);
>>>>> +
>>>>> +    indio_dev->dev.parent = &client->dev;
>>>>> +    indio_dev->channels = bmc150_accel_channels;
>>>>> +    indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
>>>>> +    indio_dev->name = BMC150_ACCEL_DRV_NAME;
>>>>> +    indio_dev->modes = INDIO_DIRECT_MODE;
>>>>> +    indio_dev->info = &bmc150_accel_info;
>>>>> +
>>>>> +    if (client->irq < 0)
>>>>> +        client->irq = bmc150_accel_acpi_gpio_probe(client, data);
>>>>> +
>>>>> +    if (client->irq >= 0) {
>>>> You could (and probably should given the devm_request_irq after this)
>>>> use devm_iio_trigger_alloc and loose all the iio_trigger_free calls.
>>> OK
>>>>> +        trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
>>>>> +                     indio_dev->id);
>>>>> +        if (!trig)
>>>>> +            return -ENOMEM;
>>>>> +
>>>>> +        data->trig_mode = true;
>>>> I'm not sure on the necesity for an extra variable to store this
>>>> given we can just use whether the trig variable != NULL for the same
>>>> thing.  I guess it might make things ever so slightly easier to read...
>>>>
>>> OK
>>>>> +
>>>>> +        ret = devm_request_irq(&client->dev, client->irq,
>>>>> +                       iio_trigger_generic_data_rdy_poll,
>>>>> +                       IRQF_TRIGGER_RISING,
>>>>> +                       BMC150_ACCEL_IRQ_NAME,
>>>>> +                       trig);
>>>>> +        if (ret) {
>>>>> +            dev_err(&client->dev, "unable to request IRQ\n");
>>>>> +            goto err_trigger_free;
>>>>> +        }
>>>>> +
>>>>> +        trig->dev.parent = &client->dev;
>>>>> +        trig->ops = &bmc150_accel_trigger_ops;
>>>>> +        iio_trigger_set_drvdata(trig, indio_dev);
>>>>> +        data->trig = trig;
>>>>> +        indio_dev->trig = trig;
>>>> This is dangerous.  Doing it like this will, IIRC leave the wrong
>>>> reference counts for the trigger.  If you really, really want to do
>>>> this then call iio_get_trigger on the trigger as well to increment
>>>> the use count.  Prefered option is to leave the binding to userspace
>>>> after the driver is probed.
>>> OK
>>>>> +
>>>>> +        ret = iio_trigger_register(trig);
>>>>> +        if (ret)
>>>>> +            goto err_trigger_free;
>>>>> +
>>>>> +        ret = iio_triggered_buffer_setup(indio_dev,
>>>>> +                         &iio_pollfunc_store_time,
>>>>> +                         bmc150_accel_trigger_handler,
>>>>> +                         NULL);
>>>>> +        if (ret < 0) {
>>>>> +            dev_err(&client->dev,
>>>>> +                "iio triggered buffer setup failed\n");
>>>>> +            goto err_trigger_unregister;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>> +    ret = iio_device_register(indio_dev);
>>>>> +    if (ret < 0) {
>>>>> +        dev_err(&client->dev, "unable to register iio device\n");
>>>>> +        goto err_buffer_cleanup;
>>>>> +    }
>>>>> +
>>>>> +    return 0;
>>>>> +
>>>>> +err_buffer_cleanup:
>>>>> +    if (data->trig_mode)
>>>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>>>> +err_trigger_unregister:
>>>>> +    if (data->trig_mode)
>>>>> +        iio_trigger_unregister(trig);
>>>>> +err_trigger_free:
>>>>> +    if (data->trig_mode)
>>>>> +        iio_trigger_free(trig);
>>>>> +
>>>>> +    return ret;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_remove(struct i2c_client *client)
>>>>> +{
>>>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(client);
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    iio_device_unregister(indio_dev);
>>>>> +
>>>>> +    if (data->trig_mode) {
>>>>> +        iio_triggered_buffer_cleanup(indio_dev);
>>>>> +        iio_trigger_unregister(data->trig);
>>>>> +        iio_trigger_free(data->trig);
>>>>> +    }
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +#ifdef CONFIG_PM_SLEEP
>>>>> +static int bmc150_accel_suspend(struct device *dev)
>>>>> +{
>>>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +    bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +static int bmc150_accel_resume(struct device *dev)
>>>>> +{
>>>>> +    struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>>>>> +    struct bmc150_accel_data *data = iio_priv(indio_dev);
>>>>> +
>>>>> +    mutex_lock(&data->mutex);
>>>>> +    if (data->power_state)
>>>>> +        bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
>>>>> +    mutex_unlock(&data->mutex);
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +
>>>>> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
>>>>> +             bmc150_accel_resume);
>>>>> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
>>>>> +#else
>>>>> +#define BMC150_ACCEL_PM_OPS NULL
>>>>> +#endif
>>>>> +
>>>>> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
>>>>> +    {"BSBA0150", 0},
>>>>> +    {"BMC150A", 0},
>>>>> +    { },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
>>>>> +
>>>>> +static const struct i2c_device_id bmc150_accel_id[] = {
>>>>> +    {"bmc150_accel", 0},
>>>>> +    {}
>>>>> +};
>>>>> +
>>>>> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
>>>>> +
>>>>> +static struct i2c_driver bmc150_accel_driver = {
>>>>> +    .driver = {
>>>>> +        .name    = BMC150_ACCEL_DRV_NAME,
>>>>> +        .acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
>>>>> +        .pm    = BMC150_ACCEL_PM_OPS,
>>>>> +    },
>>>>> +    .probe        = bmc150_accel_probe,
>>>>> +    .remove        = bmc150_accel_remove,
>>>>> +    .id_table    = bmc150_accel_id,
>>>>> +};
>>>>> +module_i2c_driver(bmc150_accel_driver);
>>>>> +
>>>>> +MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
>>>>> +MODULE_LICENSE("GPL v2");
>>>>> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
>>>>>
>>>>
>>>>
>>> Thanks,
>>> Srinivas
>>
>>
>
> --
> 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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-20 18:12 [PATCH] iio: accel: BMC150 accel support Srinivas Pandruvada
  2014-06-22 14:23 ` Jonathan Cameron
@ 2014-06-29 20:43 ` Peter Meerwald
  1 sibling, 0 replies; 12+ messages in thread
From: Peter Meerwald @ 2014-06-29 20:43 UTC (permalink / raw)
  To: Srinivas Pandruvada; +Cc: jic23, linux-iio


> This change implements BMC150 accelerometer driver. A BMC150 package
> consist of a compass and an accelerometer. This driver only implements
> accelerometer part.
> Spec downloaded from:
> http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-03.pdf

comments inline (nitpicking)

> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 12addf2..5704d6b 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -17,6 +17,19 @@ config BMA180
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called bma180.
>  
> +config BMC150_ACCEL
> +	tristate "Bosch BMC150 Accelerometer Driver"
> +	depends on I2C
> +	select IIO_BUFFER
> +	select IIO_TRIGGERED_BUFFER
> +	help
> +	  Say yes here to build support for the Bosch BMC150 accelerometer.
> +	  Currently this only supports the device via an i2c interface.
> +
> +	  This is a combo module with both accelerometer and magnetometer.
> +	  This driver is only implementing accelerometer part, which has
> +	  its own address and register map.
> +
>  config HID_SENSOR_ACCEL_3D
>  	depends on HID_SENSOR_HUB
>  	select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 6578ca1..a593996 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,6 +4,7 @@
>  
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_BMA180) += bma180.o
> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
>  obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>  obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>  obj-$(CONFIG_KXSD9)	+= kxsd9.o
> diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
> new file mode 100644
> index 0000000..330a3d7
> --- /dev/null
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -0,0 +1,947 @@
> +/*
> + * BMC150 3-axis accelerometer 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/module.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/acpi.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> +#define BMC150_ACCEL_DRV_NAME			"bmc150_accel"
> +#define BMC150_ACCEL_IRQ_NAME			"bmc150_accel_event"
> +
> +#define BMC150_ACCEL_REG_CHIP_ID		0x00
> +#define BMC150_ACCEL_CHIP_ID_VAL		0xFA
> +
> +#define BMC150_ACCEL_REG_PMU_LPW		0x11
> +#define BMC150_ACCEL_PMU_SLP_MASK		0xE0
> +#define BMC150_ACCEL_PMU_SLP_SHIFT		5
> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_MASK	0x17
> +#define BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT	1
> +
> +#define BMC150_ACCEL_REG_PMU_RANGE		0x0F
> +
> +#define BMC150_ACCEL_DEF_RANGE_2G		0x03
> +#define BMC150_ACCEL_DEF_RANGE_4G		0x05
> +#define BMC150_ACCEL_DEF_RANGE_8G		0x08
> +#define BMC150_ACCEL_DEF_RANGE_16G		0x0C
> +
> +/* Default BW: 125Hz */
> +#define BMC150_ACCEL_REG_PMU_BW			0x10
> +#define BMC150_ACCEL_DEF_BW			125
> +
> +#define BMC150_ACCEL_REG_INT_MAP_0		0x19
> +#define BMC150_ACCEL_INT_MAP_0_BIT_SLOPE	BIT(2)
> +
> +#define BMC150_ACCEL_REG_INT_RST_LATCH		0x21
> +#define BMC150_ACCEL_INT_MODE_LATCH_RESET	0x80
> +#define BMC150_ACCEL_INT_MODE_LATCH_INT		0x0F
> +
> +#define BMC150_ACCEL_REG_INT_EN_0		0x16
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_X		BIT(0)
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Y		BIT(1)
> +#define BMC150_ACCEL_INT_EN_BIT_SLP_Z		BIT(2)
> +
> +#define BMC150_ACCEL_REG_INT_OUT_CTRL		0x20
> +#define BMC150_ACCEL_INT_OUT_CTRL_INT1_LVL	BIT(0)
> +
> +#define BMC150_ACCEL_REG_INT_5			0x27
> +#define BMC150_ACCEL_SLOPE_DUR_MASK		0x03
> +
> +#define BMC150_ACCEL_REG_INT_6			0x28
> +#define BMC150_ACCEL_SLOPE_THRES_MASK		0xFF
> +
> +#define BMC150_ACCEL_REG_XOUT_L			0x02

only XOUT_L is used

> +#define BMC150_ACCEL_REG_XOUT_H			0x03
> +#define BMC150_ACCEL_REG_YOUT_L			0x04
> +#define BMC150_ACCEL_REG_YOUT_H			0x05
> +#define BMC150_ACCEL_REG_ZOUT_L			0x06
> +#define BMC150_ACCEL_REG_ZOUT_H			0x07
> +
> +#define BMC150_ACCEL_MAX_STARTUP_TIME_MS	100
> +
> +/* Slope duration in terms of number of samples */
> +#define BMC150_ACCEL_DEF_SLOPE_DURATION		2
> +/* in terms of multiples of g's/LSB, based on range */
> +#define BMC150_ACCEL_DEF_SLOPE_THRESHOLD	5
> +
> +/* Sleep Duration values */
> +#define BMC150_ACCEL_SLEEP_500_MICRO		0x05
> +#define BMC150_ACCEL_SLEEP_1_MS			0x06
> +#define BMC150_ACCEL_SLEEP_2_MS			0x07
> +#define BMC150_ACCEL_SLEEP_4_MS			0x08
> +#define BMC150_ACCEL_SLEEP_6_MS			0x09
> +#define BMC150_ACCEL_SLEEP_10_MS		0x0A
> +#define BMC150_ACCEL_SLEEP_25_MS		0x0B
> +#define BMC150_ACCEL_SLEEP_50_MS		0x0C
> +#define BMC150_ACCEL_SLEEP_100_MS		0x0D
> +#define BMC150_ACCEL_SLEEP_500_MS		0x0E
> +#define BMC150_ACCEL_SLEEP_1_SEC		0x0F
> +
> +/* Sleep Modes */
> +#define BMC150_ACCEL_SLEEP_MODE_NORMAL		0x00
> +#define BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND	0x01
> +#define BMC150_ACCEL_SLEEP_MODE_LPM		0x03
> +#define BMC150_ACCEL_SLEEP_MODE_SUSPEND		0x04
> +
> +struct bmc150_accel_data {
> +	struct i2c_client *client;
> +	struct iio_trigger *trig;
> +	bool	trig_mode;
> +	struct mutex mutex;
> +	s16 buffer[3];
> +	int power_state;
> +	u8 bw_bits;
> +	u32 slope_dur;
> +	u32 slope_thres;
> +	u32 range;
> +};
> +
> +enum bmc150_accel_axis {
> +	AXIS_X,
> +	AXIS_Y,
> +	AXIS_Z,
> +};
> +
> +static const struct {
> +	int val;
> +	int val2;
> +	int bw_bits;

bw_bits could/should be u8 (same as in bmc150_accel_data)

> +} bmc150_accel_samp_freq_table[] = { {7, 810000, 0x08}, {15, 630000, 0x09},
> +				     {31, 250000, 0x0A}, {62, 500000, 0x0B},
> +				     {125, 0, 0x0C}, {250, 0, 0x0D},
> +				     {500, 0, 0x0E}, {1000, 0, 0x0F} };
> +
> +static const struct {
> +	int bw_bits;
> +	int msec;
> +} bmc150_accel_sample_upd_time[] = { {0x08, 64}, {0x09, 32}, {0x0A, 16},
> +				     {0x0B, 8}, {0x0C, 4},  {0x0D, 2},
> +				     {0x0E, 1}, {0x0F, 1} };
> +
> +static const struct {
> +	int scale;
> +	int range;
> +} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
> +				 {19122, BMC150_ACCEL_DEF_RANGE_4G},
> +				 {38344, BMC150_ACCEL_DEF_RANGE_8G},
> +				 {77057, BMC150_ACCEL_DEF_RANGE_16G} };
> +
> +
> +static int bmc150_accel_convert_sleep_value(int sleep_dur_us)
> +{
> +	int ret;
> +
> +	switch (sleep_dur_us) {

maybe one more table instead of a multi-line switch?

> +	case 0:
> +		ret = 0;
> +		break;
> +	case 500:
> +		ret = BMC150_ACCEL_SLEEP_500_MICRO;
> +		break;
> +	case 1000:
> +		ret = BMC150_ACCEL_SLEEP_1_MS;
> +		break;
> +	case 2000:
> +		ret = BMC150_ACCEL_SLEEP_2_MS;
> +		break;
> +	case 4000:
> +		ret = BMC150_ACCEL_SLEEP_4_MS;
> +		break;
> +	case 6000:
> +		ret = BMC150_ACCEL_SLEEP_6_MS;
> +		break;
> +	case 10000:
> +		ret = BMC150_ACCEL_SLEEP_10_MS;
> +		break;
> +	case 25000:
> +		ret = BMC150_ACCEL_SLEEP_25_MS;
> +		break;
> +	case 50000:
> +		ret = BMC150_ACCEL_SLEEP_50_MS;
> +		break;
> +	case 100000:
> +		ret = BMC150_ACCEL_SLEEP_100_MS;
> +		break;
> +	case 500000:
> +		ret = BMC150_ACCEL_SLEEP_500_MS;
> +		break;
> +	case 1000000:
> +		ret = BMC150_ACCEL_SLEEP_1_SEC;
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_set_mode(struct bmc150_accel_data *data, int mode,
> +				 int dur_us)
> +{
> +	int ret;
> +	u8 lpw_bits = 0;

init of lpw_bits not needed

> +	int dur;
> +
> +	dur = bmc150_accel_convert_sleep_value(dur_us);
> +	if (dur < 0)
> +		return dur;
> +
> +	lpw_bits = mode << BMC150_ACCEL_PMU_SLP_SHIFT;
> +	lpw_bits |= (dur << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
> +
> +	dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
> +
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_convert_freq_to_bit(int val)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> +		if (bmc150_accel_samp_freq_table[i].val == val)
> +			return bmc150_accel_samp_freq_table[i].bw_bits;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int bmc150_accel_set_bw(struct bmc150_accel_data *data, int val)
> +{
> +	int ret;
> +	int bw_bits;

u8

> +
> +	bw_bits = bmc150_accel_convert_freq_to_bit(val);
> +	if (bw_bits < 0)
> +		return bw_bits;
> +
> +	ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_PMU_BW,
> +					bw_bits);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing pmu_bw\n");

reg_pmu_bw or pmu_bw? to make it consistent with above error message

> +		return ret;
> +	}
> +
> +	data->bw_bits = bw_bits;
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_chip_init(struct bmc150_accel_data *data)
> +{
> +	int ret;
> +
> +	ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_CHIP_ID);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +			"Error:BMC150_ACCEL_REG_CHIP_ID\n");

maybe "Error reading reg_chip_id"

> +		return ret;
> +	}
> +
> +	dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
> +	if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
> +		dev_err(&data->client->dev, "invalid chip %x\n", ret);

error message start with uppercase elsewhere

> +		return -ENODEV;
> +	}
> +
> +	/* Set Bandwidth */
> +	ret = bmc150_accel_set_bw(data, BMC150_ACCEL_DEF_BW);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Set Default Range */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_PMU_RANGE,
> +					BMC150_ACCEL_DEF_RANGE_4G);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +					"Error writing pmu_range\n");
> +		return ret;
> +	}
> +	data->range = BMC150_ACCEL_DEF_RANGE_4G;
> +
> +	data->slope_dur = BMC150_ACCEL_DEF_SLOPE_DURATION;
> +	data->slope_thres = BMC150_ACCEL_DEF_SLOPE_THRESHOLD;
> +
> +	ret = bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);

return bmc150_accel_set_mode()

> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_chip_setup_interrupt(struct bmc150_accel_data *data,
> +					  bool status)
> +{
> +	int ret;
> +
> +	/* Enable/Disable INT1 mapping */
> +	ret = i2c_smbus_read_byte_data(data->client,
> +				       BMC150_ACCEL_REG_INT_MAP_0);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error read reg_int_map0\n");
> +		return ret;
> +	}
> +	if (status)
> +		ret |= BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
> +	else
> +		ret &= ~BMC150_ACCEL_INT_MAP_0_BIT_SLOPE;
> +
> +
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_MAP_0,
> +					ret);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error write reg_int_map0\n");
> +		return ret;
> +	}
> +
> +	/* Set latched mode interrupt and clear any latched interrupt */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_RST_LATCH,
> +					BMC150_ACCEL_INT_MODE_LATCH_INT |
> +					BMC150_ACCEL_INT_MODE_LATCH_RESET);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error write reg_rst_latch\n");

reg_int_rst_latch

> +		return ret;
> +	}
> +
> +	/* Enable/Disable slope interrupts */
> +	if (status) {
> +		/* Set slope duration (no of samples) */
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_5,
> +						data->slope_dur);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error write eg_int_5\n");

reg_int_5

> +			return ret;
> +		}
> +
> +		/* Set slope thresholds */
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_6,
> +						data->slope_thres);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error write reg_int_6\n");
> +			return ret;
> +		}
> +
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_EN_0,
> +						BMC150_ACCEL_INT_EN_BIT_SLP_X |
> +						BMC150_ACCEL_INT_EN_BIT_SLP_Y |
> +						BMC150_ACCEL_INT_EN_BIT_SLP_Z);
> +		if (ret < 0) {
> +			dev_err(&data->client->dev, "Error wr reg_int_en0\n");
> +			return ret;
> +		}

remove ret < 0 check, can use the check below

> +
> +	} else
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						BMC150_ACCEL_REG_INT_EN_0,
> +						0);
> +
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_int_en0\n");
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_chip_ack_intr(struct bmc150_accel_data *data)
> +{
> +	int ret;
> +
> +	/* Set latched mode interrupt and clear any latched interrupt */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					BMC150_ACCEL_REG_INT_RST_LATCH,
> +					BMC150_ACCEL_INT_MODE_LATCH_INT |
> +					BMC150_ACCEL_INT_MODE_LATCH_RESET);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev, "Error writing reg_rst_latch\n");

reg_int_rst_latch

> +		return ret;
> +	}
> +
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_get_bw(struct bmc150_accel_data *data, int *val,
> +			       int *val2)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> +		if (bmc150_accel_samp_freq_table[i].bw_bits == data->bw_bits) {
> +			*val = bmc150_accel_samp_freq_table[i].val;
> +			*val2 = bmc150_accel_samp_freq_table[i].val2;
> +			return IIO_VAL_INT_PLUS_MICRO;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int bmc150_accel_get_acc_reg(struct bmc150_accel_data *data, int axis)
> +{
> +	u8 reg = BMC150_ACCEL_REG_XOUT_L + axis * 2;

use enum bmc150_accel_axis for axis?

> +	int ret;
> +
> +	ret = i2c_smbus_read_word_data(data->client, reg);
> +	if (ret < 0) {
> +		dev_err(&data->client->dev,
> +			"failed to read accel_%c registers\n", 'x' + axis);

"Failed to read..."

> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
> +{
> +	int i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_sample_upd_time); ++i) {
> +		if (bmc150_accel_sample_upd_time[i].bw_bits == data->bw_bits)
> +			return bmc150_accel_sample_upd_time[i].msec;
> +
> +	}
> +
> +	return BMC150_ACCEL_MAX_STARTUP_TIME_MS;
> +}
> +
> +static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
> +{
> +	int ret, i;
> +
> +	for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
> +		if (bmc150_accel_scale_table[i].scale == val) {
> +			ret = i2c_smbus_write_byte_data(
> +					data->client,
> +					BMC150_ACCEL_REG_PMU_RANGE,
> +					bmc150_accel_scale_table[i].range);
> +			if (ret < 0) {
> +				dev_err(&data->client->dev,
> +					"Error writing pmu_range\n");
> +				return ret;
> +			}
> +			data->range = bmc150_accel_scale_table[i].range;
> +			return 0;
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int bmc150_accel_read_raw(struct iio_dev *indio_dev,
> +				 struct iio_chan_spec const *chan,
> +				 int *val, int *val2, long mask)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&data->mutex);
> +		if (iio_buffer_enabled(indio_dev))
> +			ret = -EBUSY;

I think it would be cleaner to return -EBUSY here instead of below

> +		else {
> +			int sleep_val;
> +			if (!data->power_state) {
> +				ret = bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +						0);
> +				if (ret < 0) {
> +					mutex_unlock(&data->mutex);
> +					return ret;
> +				}
> +				sleep_val =
> +					bmc150_accel_get_startup_times(data);
> +				if (sleep_val < 20)
> +					usleep_range(sleep_val * 1000, 20000);
> +				else
> +					msleep_interruptible(sleep_val);
> +			}
> +			++data->power_state;
> +			ret = bmc150_accel_get_acc_reg(data, chan->scan_index);
> +			if (--data->power_state == 0)
> +				bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +						0);
> +				/* Nothing can be done if above call fails */
> +		}
> +		mutex_unlock(&data->mutex);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = sign_extend32(ret >> 4, 11);
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 0;
> +		switch (data->range) {
> +		case BMC150_ACCEL_DEF_RANGE_2G:
> +			*val = 9610;

val2 maybe?

> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_4G:
> +			*val2 = 19122;
> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_8G:
> +			*val2 = 38344;
> +			break;
> +		case BMC150_ACCEL_DEF_RANGE_16G:
> +			*val2 = 77057;
> +			break;
> +		default:
> +			return -EINVAL;
> +		}
> +		return IIO_VAL_INT_PLUS_MICRO;
> +	case IIO_CHAN_INFO_SAMP_FREQ:
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_get_bw(data, val, val2);
> +		mutex_unlock(&data->mutex);
> +		return ret;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int bmc150_accel_write_raw(struct iio_dev *indio_dev,
> +				  struct iio_chan_spec const *chan,
> +				  int val, int val2, long mask)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_SAMP_FREQ:
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_set_bw(data, val);
> +		mutex_unlock(&data->mutex);
> +		break;
> +	case IIO_CHAN_INFO_SCALE:
> +		if (val)
> +			return -EINVAL;
> +		mutex_lock(&data->mutex);
> +		ret = bmc150_accel_set_scale(data, val2);
> +		mutex_unlock(&data->mutex);
> +		return ret;
> +	default:
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +/* power_mode ABI is a documented ABI for accelerometers, utiliziing
> + * this makes lot of sense when no buffered mode available because
> + * of lake of interrupt configuration. If user mode calls to read raw
> + * value with a very high frequency, instead of turn on/off for each
> + * read, keeping system on by setting power mode to "on" will give
> + * better performance.
> + */
> +static const char * const bmc150_accel_power_modes[] = {
> +	"off",
> +	"on",
> +};
> +
> +static int bmc150_accel_get_power_mode(struct iio_dev *indio_dev,
> +				       const struct iio_chan_spec *chan)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	return data->power_state;
> +}
> +
> +static int bmc150_accel_set_power_mode(struct iio_dev *indio_dev,
> +				       const struct iio_chan_spec *chan,
> +				       unsigned int mode)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int ret = 0;
> +
> +	mutex_lock(&data->mutex);
> +	if (mode) {
> +		if (!data->power_state)
> +			ret = bmc150_accel_set_mode(data,
> +						BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +						0);
> +		++data->power_state;

power_state should not be incremented if set_mode() fails

> +	} else {
> +		if (--data->power_state == 0)
> +			ret = bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +					0);
> +	}
> +	mutex_unlock(&data->mutex);
> +
> +	return ret;
> +}
> +
> +static int bmc150_validate_trigger(struct iio_dev *indio_dev,
> +				   struct iio_trigger *trig)
> +{
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	if (data->trig != trig)
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
> +		"7.810000 15.630000 31.250000 62.500000 125 250 500 1000");
> +
> +static struct attribute *bmc150_accel_attributes[] = {
> +	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
> +	NULL,
> +};
> +
> +static const struct attribute_group bmc150_accel_attrs_group = {
> +	.attrs = bmc150_accel_attributes,
> +};
> +
> +static const struct iio_enum bmc150_accel_power_mode_enum = {
> +	.items = bmc150_accel_power_modes,
> +	.num_items = ARRAY_SIZE(bmc150_accel_power_modes),
> +	.get = bmc150_accel_get_power_mode,
> +	.set = bmc150_accel_set_power_mode,
> +};
> +
> +static const struct iio_chan_spec_ext_info bmc150_accel_ext_info[] = {
> +	IIO_ENUM("power_mode", true, &bmc150_accel_power_mode_enum),
> +	IIO_ENUM_AVAILABLE("power_mode", &bmc150_accel_power_mode_enum),
> +	{ },
> +};
> +
> +#define BMC150_ACCEL_CHANNEL(_axis) {					\
> +	.type = IIO_ACCEL,						\
> +	.modified = 1,							\
> +	.channel2 = IIO_MOD_##_axis,					\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),			\
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |		\
> +				BIT(IIO_CHAN_INFO_SAMP_FREQ),		\
> +	.scan_index = AXIS_##_axis,					\
> +	.scan_type = {							\
> +		.sign = 's',						\
> +		.realbits = 12,						\
> +		.storagebits = 16,					\
> +		.shift = 4,						\
> +	},								\
> +	.ext_info = bmc150_accel_ext_info,				\
> +}
> +
> +static const struct iio_chan_spec bmc150_accel_channels[] = {
> +	BMC150_ACCEL_CHANNEL(X),
> +	BMC150_ACCEL_CHANNEL(Y),
> +	BMC150_ACCEL_CHANNEL(Z),
> +	IIO_CHAN_SOFT_TIMESTAMP(3),
> +};
> +
> +static const struct iio_info bmc150_accel_info = {
> +	.attrs			= &bmc150_accel_attrs_group,
> +	.read_raw		= bmc150_accel_read_raw,
> +	.write_raw		= bmc150_accel_write_raw,
> +	.validate_trigger	= bmc150_validate_trigger,
> +	.driver_module		= THIS_MODULE,
> +};
> +
> +static irqreturn_t bmc150_accel_trigger_handler(int irq, void *p)
> +{
> +	struct iio_poll_func *pf = p;
> +	struct iio_dev *indio_dev = pf->indio_dev;
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +	int bit, ret, i = 0;
> +
> +	mutex_lock(&data->mutex);
> +
> +	for_each_set_bit(bit, indio_dev->buffer->scan_mask,
> +			 indio_dev->masklength) {
> +		ret = bmc150_accel_get_acc_reg(data, bit);
> +		if (ret < 0) {
> +			bmc150_accel_chip_ack_intr(data);
> +			mutex_unlock(&data->mutex);
> +			goto err;
> +		}
> +		data->buffer[i++] = ret;
> +	}
> +
> +	bmc150_accel_chip_ack_intr(data);
> +
> +	mutex_unlock(&data->mutex);
> +
> +	iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> +					   pf->timestamp);
> +err:
> +	iio_trigger_notify_done(indio_dev->trig);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int bmc150_accel_data_rdy_trigger_set_state(struct iio_trigger *trig,
> +						   bool state)
> +{
> +	struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	if (state) {
> +		bmc150_accel_chip_setup_interrupt(data, true);
> +		if (!data->power_state)
> +			bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_NORMAL,
> +					0);

return value of set_mode() is ignored, power_state should not be 
incremented in case of error

> +		++data->power_state;
> +	} else {
> +		if (--data->power_state == 0)
> +			bmc150_accel_set_mode(data,
> +					BMC150_ACCEL_SLEEP_MODE_SUSPEND,
> +					0);
> +		bmc150_accel_chip_setup_interrupt(data, false);
> +	}
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static const struct iio_trigger_ops bmc150_accel_trigger_ops = {
> +	.set_trigger_state = bmc150_accel_data_rdy_trigger_set_state,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int bmc150_accel_acpi_gpio_probe(struct i2c_client *client,
> +					struct bmc150_accel_data *data)
> +{
> +	const struct acpi_device_id *id;
> +	struct device *dev;
> +	struct gpio_desc *gpio;
> +	int ret;
> +
> +	if (!client)
> +		return -EINVAL;
> +
> +	dev = &client->dev;
> +	if (!ACPI_HANDLE(dev))
> +		return -ENODEV;
> +
> +	id = acpi_match_device(dev->driver->acpi_match_table, dev);
> +	if (!id)
> +		return -ENODEV;
> +
> +	/* data ready gpio interrupt pin */
> +	gpio = devm_gpiod_get_index(dev, "bmc150_accel_int", 0);

maybe use a #define for the GPIO name?

> +	if (IS_ERR(gpio)) {
> +		dev_err(dev, "acpi gpio get index failed\n");
> +		return PTR_ERR(gpio);
> +	}
> +
> +	ret = gpiod_direction_input(gpio);
> +	if (ret)
> +		return ret;
> +
> +	ret = gpiod_to_irq(gpio);
> +
> +	dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_probe(struct i2c_client *client,
> +			      const struct i2c_device_id *id)
> +{
> +	struct bmc150_accel_data *data;
> +	struct iio_dev *indio_dev;
> +	struct iio_trigger *trig = NULL;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	data = iio_priv(indio_dev);
> +	i2c_set_clientdata(client, indio_dev);
> +	data->client = client;
> +
> +	ret = bmc150_accel_chip_init(data);
> +	if (ret < 0)
> +		return ret;
> +
> +	mutex_init(&data->mutex);
> +
> +	indio_dev->dev.parent = &client->dev;
> +	indio_dev->channels = bmc150_accel_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(bmc150_accel_channels);
> +	indio_dev->name = BMC150_ACCEL_DRV_NAME;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->info = &bmc150_accel_info;
> +
> +	if (client->irq < 0)
> +		client->irq = bmc150_accel_acpi_gpio_probe(client, data);
> +
> +	if (client->irq >= 0) {
> +		trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
> +					 indio_dev->id);
> +		if (!trig)
> +			return -ENOMEM;
> +
> +		data->trig_mode = true;
> +
> +		ret = devm_request_irq(&client->dev, client->irq,
> +				       iio_trigger_generic_data_rdy_poll,
> +				       IRQF_TRIGGER_RISING,
> +				       BMC150_ACCEL_IRQ_NAME,
> +				       trig);
> +		if (ret) {
> +			dev_err(&client->dev, "unable to request IRQ\n");
> +			goto err_trigger_free;
> +		}
> +
> +		trig->dev.parent = &client->dev;
> +		trig->ops = &bmc150_accel_trigger_ops;
> +		iio_trigger_set_drvdata(trig, indio_dev);
> +		data->trig = trig;
> +		indio_dev->trig = trig;
> +
> +		ret = iio_trigger_register(trig);
> +		if (ret)
> +			goto err_trigger_free;
> +
> +		ret = iio_triggered_buffer_setup(indio_dev,
> +						 &iio_pollfunc_store_time,
> +						 bmc150_accel_trigger_handler,
> +						 NULL);
> +		if (ret < 0) {
> +			dev_err(&client->dev,
> +				"iio triggered buffer setup failed\n");
> +			goto err_trigger_unregister;
> +		}
> +	}
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret < 0) {
> +		dev_err(&client->dev, "unable to register iio device\n");
> +		goto err_buffer_cleanup;
> +	}
> +
> +	return 0;
> +
> +err_buffer_cleanup:
> +	if (data->trig_mode)
> +		iio_triggered_buffer_cleanup(indio_dev);
> +err_trigger_unregister:
> +	if (data->trig_mode)
> +		iio_trigger_unregister(trig);
> +err_trigger_free:
> +	if (data->trig_mode)
> +		iio_trigger_free(trig);
> +
> +	return ret;
> +}
> +
> +static int bmc150_accel_remove(struct i2c_client *client)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(client);
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	iio_device_unregister(indio_dev);
> +
> +	if (data->trig_mode) {
> +		iio_triggered_buffer_cleanup(indio_dev);
> +		iio_trigger_unregister(data->trig);
> +		iio_trigger_free(data->trig);
> +	}
> +
> +	mutex_lock(&data->mutex);
> +	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_DEEP_SUSPEND, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int bmc150_accel_suspend(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_SUSPEND, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static int bmc150_accel_resume(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
> +	struct bmc150_accel_data *data = iio_priv(indio_dev);
> +
> +	mutex_lock(&data->mutex);
> +	if (data->power_state)
> +		bmc150_accel_set_mode(data, BMC150_ACCEL_SLEEP_MODE_NORMAL, 0);
> +	mutex_unlock(&data->mutex);
> +
> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(bmc150_accel_pm_ops, bmc150_accel_suspend,
> +			 bmc150_accel_resume);
> +#define BMC150_ACCEL_PM_OPS (&bmc150_accel_pm_ops)
> +#else
> +#define BMC150_ACCEL_PM_OPS NULL
> +#endif
> +
> +static const struct acpi_device_id bmc150_accel_acpi_match[] = {
> +	{"BSBA0150", 0},
> +	{"BMC150A", 0},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, bmc150_accel_acpi_match);
> +
> +static const struct i2c_device_id bmc150_accel_id[] = {
> +	{"bmc150_accel", 0},
> +	{}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
> +
> +static struct i2c_driver bmc150_accel_driver = {
> +	.driver = {
> +		.name	= BMC150_ACCEL_DRV_NAME,
> +		.acpi_match_table = ACPI_PTR(bmc150_accel_acpi_match),
> +		.pm	= BMC150_ACCEL_PM_OPS,
> +	},
> +	.probe		= bmc150_accel_probe,
> +	.remove		= bmc150_accel_remove,
> +	.id_table	= bmc150_accel_id,
> +};
> +module_i2c_driver(bmc150_accel_driver);
> +
> +MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("BMC150 accelerometer driver");
> 

-- 

Peter Meerwald
+43-664-2444418 (mobile)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-06-29 14:42         ` Jonathan Cameron
@ 2014-07-07 14:36           ` Mark Brown
  2014-07-07 16:13             ` Jonathan Cameron
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Brown @ 2014-07-07 14:36 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Srinivas Pandruvada, linux-iio

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Sun, Jun 29, 2014 at 03:42:55PM +0100, Jonathan Cameron wrote:
> On 29/06/14 15:27, Srinivas Pandruvada wrote:

Please don't use my Linaro address for upstream things, use my
kernel.org one (which is the one I always use for mail and is in
MAINTAINERS).

I'm also having a bit of an issue reading the mail due to it not being
word wrapped.

> If we are dependent on regulators to leave certain states, do we have access to how long
> they take to start up?  What about bringing buses up...

> Cc'd Mark Brown on the basis he knows all sorts of hideous corners of the kernel way
> better than me ;)

With regulators the delays are handled transparently in the framework -
by the time the functions return the operation should have commpleted.
If there is a need to have a non-blocking interface we'll have to add
this.  The delays can be queried with _time() functions.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-07-07 14:36           ` Mark Brown
@ 2014-07-07 16:13             ` Jonathan Cameron
  2014-07-08 13:23               ` Mark Brown
  0 siblings, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2014-07-07 16:13 UTC (permalink / raw)
  To: Mark Brown; +Cc: Srinivas Pandruvada, linux-iio

On 07/07/14 15:36, Mark Brown wrote:
> On Sun, Jun 29, 2014 at 03:42:55PM +0100, Jonathan Cameron wrote:
>> On 29/06/14 15:27, Srinivas Pandruvada wrote:
>
> Please don't use my Linaro address for upstream things, use my
> kernel.org one (which is the one I always use for mail and is in
> MAINTAINERS).
Will do.
>
> I'm also having a bit of an issue reading the mail due to it not being
> word wrapped.
It does indeed seem to have gotten wrapped at a random, somewhat
longer than normal length... Oops.
>
>> If we are dependent on regulators to leave certain states, do we have access to how long
>> they take to start up?  What about bringing buses up...
>
>> Cc'd Mark Brown on the basis he knows all sorts of hideous corners of the kernel way
>> better than me ;)
>
> With regulators the delays are handled transparently in the framework -
> by the time the functions return the operation should have commpleted.
> If there is a need to have a non-blocking interface we'll have to add
> this.  The delays can be queried with _time() functions.
We are looking at a somewhat tangential question here...

What we have is a device that has various power saving levels.  As
the basic interest of IIO is grabbing data, in a sense it is the
time taken to return from a given level and grab some data that
acts as the controlling variable on how low a power state the
device should go into.

Hence rather than picking a given power state (deep sleep or similar)
we want the control to be on capture latency.  Hence userspace
can specify the 'worst case' latency it will accept and the
device will hence enter the lowest power state, between samples,
that it can without failing to meet the requirement.

What I was wondering is whether there is anything similar
elsewhere that you know of? For example, could we query a
regulator driver to ask it how long it will take to start up
a given output?

This extension beyond the device it self to it's power supplies
and for example bus is more of an idle thought than an actual
plan at this stage.

J  


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-07-07 16:13             ` Jonathan Cameron
@ 2014-07-08 13:23               ` Mark Brown
  2014-07-08 15:27                 ` Jonathan Cameron
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Brown @ 2014-07-08 13:23 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Srinivas Pandruvada, linux-iio

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Mon, Jul 07, 2014 at 05:13:56PM +0100, Jonathan Cameron wrote:
> On 07/07/14 15:36, Mark Brown wrote:

> >With regulators the delays are handled transparently in the framework -
> >by the time the functions return the operation should have commpleted.
> >If there is a need to have a non-blocking interface we'll have to add
> >this.  The delays can be queried with _time() functions.

> We are looking at a somewhat tangential question here...

I don't think so...

> Hence rather than picking a given power state (deep sleep or similar)
> we want the control to be on capture latency.  Hence userspace
> can specify the 'worst case' latency it will accept and the
> device will hence enter the lowest power state, between samples,
> that it can without failing to meet the requirement.
> 
> What I was wondering is whether there is anything similar
> elsewhere that you know of? For example, could we query a
> regulator driver to ask it how long it will take to start up
> a given output?

...hence my comment that "The delays can be queried with _time()
functions - you don't need to implement the delays but you can find out
what they will be.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-07-08 13:23               ` Mark Brown
@ 2014-07-08 15:27                 ` Jonathan Cameron
  2014-07-08 18:03                   ` Jonathan Cameron
  0 siblings, 1 reply; 12+ messages in thread
From: Jonathan Cameron @ 2014-07-08 15:27 UTC (permalink / raw)
  To: Mark Brown; +Cc: Srinivas Pandruvada, linux-iio



On July 8, 2014 2:23:55 PM GMT+01:00, Mark Brown <broonie@kernel.org> wrote:
>On Mon, Jul 07, 2014 at 05:13:56PM +0100, Jonathan Cameron wrote:
>> On 07/07/14 15:36, Mark Brown wrote:
>
>> >With regulators the delays are handled transparently in the
>framework -
>> >by the time the functions return the operation should have
>commpleted.
>> >If there is a need to have a non-blocking interface we'll have to
>add
>> >this.  The delays can be queried with _time() functions.
>
>> We are looking at a somewhat tangential question here...
>
>I don't think so...
>
>> Hence rather than picking a given power state (deep sleep or similar)
>> we want the control to be on capture latency.  Hence userspace
>> can specify the 'worst case' latency it will accept and the
>> device will hence enter the lowest power state, between samples,
>> that it can without failing to meet the requirement.
>> 
>> What I was wondering is whether there is anything similar
>> elsewhere that you know of? For example, could we query a
>> regulator driver to ask it how long it will take to start up
>> a given output?
>
>...hence my comment that "The delays can be queried with _time()
>functions - you don't need to implement the delays but you can find out
>what they will be.
Ah sounds like I miss interpreted your response! 
Will look into the _time stuff.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iio: accel: BMC150 accel support
  2014-07-08 15:27                 ` Jonathan Cameron
@ 2014-07-08 18:03                   ` Jonathan Cameron
  0 siblings, 0 replies; 12+ messages in thread
From: Jonathan Cameron @ 2014-07-08 18:03 UTC (permalink / raw)
  To: Mark Brown; +Cc: Srinivas Pandruvada, linux-iio

On 08/07/14 16:27, Jonathan Cameron wrote:
>
>
> On July 8, 2014 2:23:55 PM GMT+01:00, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jul 07, 2014 at 05:13:56PM +0100, Jonathan Cameron wrote:
>>> On 07/07/14 15:36, Mark Brown wrote:
>>
>>>> With regulators the delays are handled transparently in the
>> framework -
>>>> by the time the functions return the operation should have
>> commpleted.
>>>> If there is a need to have a non-blocking interface we'll have to
>> add
>>>> this.  The delays can be queried with _time() functions.
>>
>>> We are looking at a somewhat tangential question here...
>>
>> I don't think so...
>>
>>> Hence rather than picking a given power state (deep sleep or similar)
>>> we want the control to be on capture latency.  Hence userspace
>>> can specify the 'worst case' latency it will accept and the
>>> device will hence enter the lowest power state, between samples,
>>> that it can without failing to meet the requirement.
>>>
>>> What I was wondering is whether there is anything similar
>>> elsewhere that you know of? For example, could we query a
>>> regulator driver to ask it how long it will take to start up
>>> a given output?
>>
>> ...hence my comment that "The delays can be queried with _time()
>> functions - you don't need to implement the delays but you can find out
>> what they will be.
> Ah sounds like I miss interpreted your response!
> Will look into the _time stuff.
>
Right, this will certainly act as a starting point, though will
be a little bit interesting to make it all work together.

Anyhow, no idea when or if anyone will have time to look at the
levels beyond the sensor drivers themselves.

Thanks Mark,

Jonathan

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2014-07-08 18:01 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-20 18:12 [PATCH] iio: accel: BMC150 accel support Srinivas Pandruvada
2014-06-22 14:23 ` Jonathan Cameron
2014-06-23  1:22   ` Srinivas Pandruvada
2014-06-29 11:12     ` Jonathan Cameron
2014-06-29 14:27       ` Srinivas Pandruvada
2014-06-29 14:42         ` Jonathan Cameron
2014-07-07 14:36           ` Mark Brown
2014-07-07 16:13             ` Jonathan Cameron
2014-07-08 13:23               ` Mark Brown
2014-07-08 15:27                 ` Jonathan Cameron
2014-07-08 18:03                   ` Jonathan Cameron
2014-06-29 20:43 ` Peter Meerwald

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.