From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH v1] iio: accel: kxcjk1013 3-axis accelerometer driver
Date: Tue, 10 Jun 2014 18:28:49 -0700 [thread overview]
Message-ID: <5397B0D1.4090104@linux.intel.com> (raw)
In-Reply-To: <5393618F.10400@kernel.org>
Hi Jonathan,
I am submitting new version, but still have one question.
On 06/07/2014 12:01 PM, Jonathan Cameron wrote:
> On 04/06/14 18:26, Srinivas Pandruvada wrote:
>> This patch adds IIO driver for KXCJK 1013 triaxis accelerometer sensor.
>> The specifications for this driver is downloaded from:
>> http://www.kionix.com/sites/default/files/KXCJK-1013%20Specifications%20Rev%202.pdf
>>
>>
>> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Mostly looks fine to me, though I have a few queries inline to do with
> various state
> changes when the buffer / dataready trigger is running.
> Also you probably want to provide the callback to prevent the buffer
> associating with other triggers seeing as I don't think it will ever
> work... (almost always the case with data ready interrupts).
I couldn't decode this. Do you mean try_reenable for trigger ops or
buffer set up ops preeenable/postenable?
Thanks,
Srinivas
>
> Nothing stops us running additional devices off the dataready trigger
> though
> which is why we bother to have triggers for these devices.
>
> I'd also slightly prefer some switching round of logic to make the flow
> more standard. It's a matter of personal preference really so if you feel
> strongly against it then push back!
>> ---
> Change list?
>
>> drivers/iio/accel/Kconfig | 12 +
>> drivers/iio/accel/Makefile | 1 +
>> drivers/iio/accel/kxcjk-1013.c | 729
>> +++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 742 insertions(+)
>> create mode 100644 drivers/iio/accel/kxcjk-1013.c
>>
>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>> index 1e120fa..12addf2 100644
>> --- a/drivers/iio/accel/Kconfig
>> +++ b/drivers/iio/accel/Kconfig
>> @@ -77,4 +77,16 @@ config MMA8452
>> To compile this driver as a module, choose M here: the module
>> will be called mma8452.
>>
>> +config KXCJK1013
>> + tristate "Kionix 3-Axis Accelerometer Driver"
>> + depends on I2C
>> + select IIO_BUFFER
>> + select IIO_TRIGGERED_BUFFER
>> + help
>> + Say Y here if you want to build a driver for the Kionix KXCJK-1013
>> + triaxial acceleration sensor.
>> +
>> + To compile this driver as a module, choose M here: the module will
>> + be called kxcjk-1013.
>> +
>> endmenu
>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>> index dc0e379..6578ca1 100644
>> --- a/drivers/iio/accel/Makefile
>> +++ b/drivers/iio/accel/Makefile
>> @@ -5,6 +5,7 @@
>> # When adding new entries keep the list in alphabetical order
>> obj-$(CONFIG_BMA180) += bma180.o
>> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>> +obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>> obj-$(CONFIG_KXSD9) += kxsd9.o
>> obj-$(CONFIG_MMA8452) += mma8452.o
>>
>> diff --git a/drivers/iio/accel/kxcjk-1013.c
>> b/drivers/iio/accel/kxcjk-1013.c
>> new file mode 100644
>> index 0000000..bbc3a57
>> --- /dev/null
>> +++ b/drivers/iio/accel/kxcjk-1013.c
>> @@ -0,0 +1,729 @@
>> +/*
>> + * KXCJK-1013 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/of.h>
>> +#include <linux/bitops.h>
>> +#include <linux/slab.h>
>> +#include <linux/string.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 KXCJK1013_DRV_NAME "kxcjk1013"
>> +#define KXCJK1013_IRQ_NAME "kxcjk1013_event"
>> +
>> +#define KXCJK1013_REG_XOUT_L 0x06
>> +/*
>> + * From low byte X axis register, all the other addresses of Y and Z
>> can be
>> + * obtained by just applying axis offset. The following axis defines
>> are just
>> + * provide clarity, but not used.
>> + */
>> +#define KXCJK1013_REG_XOUT_H 0x07
>> +#define KXCJK1013_REG_YOUT_L 0x08
>> +#define KXCJK1013_REG_YOUT_H 0x09
>> +#define KXCJK1013_REG_ZOUT_L 0x0A
>> +#define KXCJK1013_REG_ZOUT_H 0x0B
>> +
>> +#define KXCJK1013_REG_DCST_RESP 0x0C
>> +#define KXCJK1013_REG_WHO_AM_I 0x0F
>> +#define KXCJK1013_REG_INT_SRC1 0x16
>> +#define KXCJK1013_REG_INT_SRC2 0x17
>> +#define KXCJK1013_REG_STATUS_REG 0x18
>> +#define KXCJK1013_REG_INT_REL 0x1A
>> +#define KXCJK1013_REG_CTRL1 0x1B
>> +#define KXCJK1013_REG_CTRL2 0x1D
>> +#define KXCJK1013_REG_INT_CTRL1 0x1E
>> +#define KXCJK1013_REG_INT_CTRL2 0x1F
>> +#define KXCJK1013_REG_DATA_CTRL 0x21
>> +#define KXCJK1013_REG_WAKE_TIMER 0x29
>> +#define KXCJK1013_REG_SELF_TEST 0x3A
>> +#define KXCJK1013_REG_WAKE_THRES 0x6A
>> +
>> +#define KXCJK1013_REG_CTRL1_BIT_PC1 BIT(7)
>> +#define KXCJK1013_REG_CTRL1_BIT_RES BIT(6)
>> +#define KXCJK1013_REG_CTRL1_BIT_DRDY BIT(5)
>> +#define KXCJK1013_REG_CTRL1_BIT_GSEL1 BIT(4)
>> +#define KXCJK1013_REG_CTRL1_BIT_GSEL0 BIT(3)
>> +#define KXCJK1013_REG_CTRL1_BIT_WUFE BIT(1)
>> +#define KXCJK1013_REG_INT_REG1_BIT_IEA BIT(4)
>> +#define KXCJK1013_REG_INT_REG1_BIT_IEN BIT(5)
>> +
>> +#define KXCJK1013_DATA_MASK_12_BIT 0x0FFF
>> +#define KXCJK1013_MAX_STARTUP_TIME_US 100000
>> +
>> +struct kxcjk1013_data {
>> + struct i2c_client *client;
>> + struct iio_trigger *trig;
>> + bool trig_mode;
> Odd spacing?
>> + struct mutex mutex;
>> + s16 buffer[3];
>> + atomic_t power_state;
>> + int gpio_irq;
>> + u8 odr_bits;
>> +};
>> +
>> +enum kxcjk1013_axis {
>> + AXIS_X,
>> + AXIS_Y,
>> + AXIS_Z,
>> +};
>> +
>> +enum kxcjk1013_mode {
>> + STANDBY,
>> + OPERATION,
>> +};
>> +
>> +static const struct {
>> + int val;
>> + int val2;
>> + int odr_bits;
>> +} samp_freq_table[] = { {0, 781, 0x08}, {1, 563, 0x09},
>> + {3, 125, 0x0A}, {6, 25, 0x0B}, {12, 5, 0},
>> + {25, 0, 0x01}, {50, 0, 0x02}, {100, 0, 0x03},
>> + {200, 0, 0x04}, {400, 0, 0x05}, {800, 0, 0x06},
>> + {1600, 0, 0x07} };
>> +
>> +/* Refer to section 4 of the specification */
>> +static const struct {
>> + int odr_bits;
>> + int usec;
>> +} odr_start_up_times[] = { {0x08, 100000}, {0x09, 100000},
>> + {0x0A, 100000}, {0x0B, 100000}, { 0, 80000},
>> + {0x01, 41000}, {0x02, 21000}, {0x03, 11000},
>> + {0x04, 6400}, {0x05, 3900}, {0x06, 2700},
>> + {0x07, 2100} };
>> +
>> +static int kxcjk1013_set_mode(struct kxcjk1013_data *data,
>> + enum kxcjk1013_mode mode)
>> +{
>> + int ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client, KXCJK1013_REG_CTRL1);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + if (mode == STANDBY)
>> + ret &= ~KXCJK1013_REG_CTRL1_BIT_PC1;
>> + else
>> + ret |= KXCJK1013_REG_CTRL1_BIT_PC1;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + KXCJK1013_REG_CTRL1, ret);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing reg_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int kxcjk1013_chip_setup_polarity(struct kxcjk1013_data *data,
>> + bool active_high)
>> +{
>> + int ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client,
>> KXCJK1013_REG_INT_CTRL1);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_int_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + if (active_high)
>> + ret |= KXCJK1013_REG_INT_REG1_BIT_IEA;
>> + else
>> + ret &= ~KXCJK1013_REG_INT_REG1_BIT_IEA;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> KXCJK1013_REG_INT_CTRL1,
>> + ret);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing reg_int_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
> This is a wrapper that adds little. I'd get rid of it - particularly
> as you never handle any errors it might return anyway! I can see
> why you don't handle the errors (nothing much you can do if they
> occur) but this function gives a somewhat false sense of security :)
>> +static int kxcjk1013_chip_ack_intr(struct kxcjk1013_data *data)
>> +{
>> + int ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client, KXCJK1013_REG_INT_REL);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing reg_int_rel\n");
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int kxcjk1013_chip_init(struct kxcjk1013_data *data)
>> +{
>> + int ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client,
>> KXCJK1013_REG_WHO_AM_I);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading who_am_i\n");
>> + return ret;
>> + }
>> +
>> + dev_dbg(&data->client->dev, "KXCJK1013 Chip Id %x\n", ret);
>> +
>> + ret = kxcjk1013_set_mode(data, STANDBY);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client, KXCJK1013_REG_CTRL1);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + /* Setting range to 4G */
>> + ret |= KXCJK1013_REG_CTRL1_BIT_GSEL0;
>> + ret &= ~KXCJK1013_REG_CTRL1_BIT_GSEL1;
>> +
>> + /* Set 12 bit mode */
>> + ret |= KXCJK1013_REG_CTRL1_BIT_RES;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + KXCJK1013_REG_CTRL1, ret);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_ctrl\n");
>> + return ret;
>> + }
>> +
>> + ret = i2c_smbus_read_byte_data(data->client,
>> KXCJK1013_REG_DATA_CTRL);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_data_ctrl\n");
>> + return ret;
>> + }
>> +
>> + data->odr_bits = ret;
>> +
>> + /* Active high interrupt */
> I suppose starting with this is fine, but it should be ultimately coming
> from some form of platform data...
>> + return kxcjk1013_chip_setup_polarity(data, true);
>> +}
>> +
>> +static int kxcjk1013_chip_setup_interrupt(struct kxcjk1013_data *data,
>> + bool status)
>> +{
>> + int ret;
>> +
>> + ret = kxcjk1013_set_mode(data, STANDBY);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = i2c_smbus_read_byte_data(data->client,
>> KXCJK1013_REG_INT_CTRL1);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_int_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + if (status)
>> + ret |= KXCJK1013_REG_INT_REG1_BIT_IEN;
>> + else
>> + ret &= ~KXCJK1013_REG_INT_REG1_BIT_IEN;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> KXCJK1013_REG_INT_CTRL1,
>> + ret);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing reg_int_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + ret = i2c_smbus_read_byte_data(data->client, KXCJK1013_REG_CTRL1);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error reading reg_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + if (status)
>> + ret |= KXCJK1013_REG_CTRL1_BIT_DRDY;
>> + else
>> + ret &= ~KXCJK1013_REG_CTRL1_BIT_DRDY;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> + KXCJK1013_REG_CTRL1, ret);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing reg_ctrl1\n");
>> + return ret;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static int kxcjk1013_convert_freq_to_bit(int val, int val2)
>> +{
>> + int i;
>> +
>> + for (i = 0; ARRAY_SIZE(samp_freq_table); ++i) {
>> + if (samp_freq_table[i].val == val &&
>> + samp_freq_table[i].val2 == val2) {
>> + return samp_freq_table[i].odr_bits;
>> + }
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static int kxcjk1013_set_odr(struct kxcjk1013_data *data, int val,
>> int val2)
>> +{
>> + int ret;
>> + int odr_bits;
>> +
>> + odr_bits = kxcjk1013_convert_freq_to_bit(val, val2 / 1000);
>> + if (odr_bits < 0)
>> + return odr_bits;
>> +
> I don't immediately see anything stopping the sampling frequency from
> being changed in buffered mode. If we are in that mode, I think the
> next bit of code will stall the data stream and it is never restarted?
> It's late on a Saturday though after a nice dinner so I might be missing
> the obvious!
>> + ret = kxcjk1013_set_mode(data, STANDBY);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = i2c_smbus_write_byte_data(data->client,
>> KXCJK1013_REG_DATA_CTRL,
>> + odr_bits);
>> + if (ret < 0) {
>> + dev_err(&data->client->dev, "Error writing data_ctrl\n");
>> + return ret;
>> + }
>> +
>> + data->odr_bits = odr_bits;
>> +
>> + return 0;
>> +}
>> +
>> +static int kxcjk1013_get_odr(struct kxcjk1013_data *data, int *val,
>> int *val2)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(samp_freq_table); ++i) {
>> + if (samp_freq_table[i].odr_bits == data->odr_bits) {
>> + *val = samp_freq_table[i].val;
>> + *val2 = samp_freq_table[i].val2 * 1000;
> Silly question of the day, why not just store val2 * 1000 in
> samp_freq_table?
>> + return IIO_VAL_INT_PLUS_MICRO;
>> + }
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
> This next one is a wrapper we could do without to my mind. Doesn't
> add anything significant.
>> +static int kxcjk1013_get_acc_reg(struct kxcjk1013_data *data, int axis)
>> +{
>> + u8 reg = KXCJK1013_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 kxcjk1013_get_startup_times(struct kxcjk1013_data *data)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(odr_start_up_times); ++i) {
>> + if (odr_start_up_times[i].odr_bits == data->odr_bits)
>> + return odr_start_up_times[i].usec;
>> +
>> + }
>> +
>> + return KXCJK1013_MAX_STARTUP_TIME_US;
>> +}
>> +
>> +static int kxcjk1013_read_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan, int *val, int *val2,
>> + long mask)
>> +{
>> + struct kxcjk1013_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;
>> +
>> + ret = kxcjk1013_set_mode(data, OPERATION);
>> + if (ret < 0)
>> + return ret;
>> + atomic_inc(&data->power_state);
>> + sleep_val = kxcjk1013_get_startup_times(data);
>> + if (sleep_val < 20000)
>> + usleep_range(sleep_val, 20000);
>> + else
>> + msleep_interruptible(sleep_val/1000);
>> + ret = kxcjk1013_get_acc_reg(data, chan->scan_index);
>> + if (atomic_dec_and_test(&data->power_state))
>> + kxcjk1013_set_mode(data, STANDBY);
>> + }
>> + mutex_unlock(&data->mutex);
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + *val = sign_extend32(le16_to_cpu(ret >> 4), 11);
>> + return IIO_VAL_INT;
>> +
>> + case IIO_CHAN_INFO_SCALE:
>> + *val = 0;
>> + *val2 = 19163; /* range +-4g (4/2047*9.806650) */
>> + return IIO_VAL_INT_PLUS_MICRO;
>> +
>> + case IIO_CHAN_INFO_SAMP_FREQ:
>> + mutex_lock(&data->mutex);
>> + ret = kxcjk1013_get_odr(data, val, val2);
>> + mutex_unlock(&data->mutex);
>> + return ret;
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>> +
>> +static int kxcjk1013_write_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan, int val, int val2, long mask)
>> +{
>> + struct kxcjk1013_data *data = iio_priv(indio_dev);
>> + int ret;
>> +
>> + switch (mask) {
>> + case IIO_CHAN_INFO_SAMP_FREQ:
>> + mutex_lock(&data->mutex);
>> + ret = kxcjk1013_set_odr(data, val, val2);
>> + mutex_unlock(&data->mutex);
>> + break;
>> + default:
>> + ret = -EINVAL;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
>> + "0.781 1.563 3.125 6.25 12.5 25 50 100 200 400 800 1600");
>> +
>> +static struct attribute *kxcjk1013_attributes[] = {
>> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group kxcjk1013_attrs_group = {
>> + .attrs = kxcjk1013_attributes,
>> +};
>> +
>> +#define KXCJK1013_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, \
>> + .endianness = IIO_LE, \
>> + }, \
>> +}
>> +
>> +static const struct iio_chan_spec kxcjk1013_channels[] = {
>> + KXCJK1013_CHANNEL(X),
>> + KXCJK1013_CHANNEL(Y),
>> + KXCJK1013_CHANNEL(Z),
>> + IIO_CHAN_SOFT_TIMESTAMP(3),
>> +};
>> +
>> +static const struct iio_info kxcjk1013_info = {
>> + .attrs = &kxcjk1013_attrs_group,
>> + .read_raw = kxcjk1013_read_raw,
>> + .write_raw = kxcjk1013_write_raw,
>> + .driver_module = THIS_MODULE,
>> +};
>> +
>> +static irqreturn_t kxcjk1013_trigger_handler(int irq, void *p)
>> +{
>> + struct iio_poll_func *pf = p;
>> + struct iio_dev *indio_dev = pf->indio_dev;
>> + struct kxcjk1013_data *data = iio_priv(indio_dev);
>> + int64_t time_ns = iio_get_time_ns();
> you could use the iio_pollfunc_store_time top half interrupt handler
> to push this a little closer to the actual interrupt (don't bother if
> you would prefer not).
> (curriously whilst checking what that does I've just noticed we still
> had a time arguement to the iio_trigger_poll functions despite the fact
> the do nothing with it any more. Oops. One to clear out :)
>> + int bit, ret, i = 0;
>> +
>> + mutex_lock(&data->mutex);
>> +
>> + for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>> + indio_dev->masklength) {
>> + ret = kxcjk1013_get_acc_reg(data, bit);
>> + if (ret < 0) {
>> + kxcjk1013_chip_ack_intr(data);
>> + mutex_unlock(&data->mutex);
>> + goto err;
>> + }
>> + data->buffer[i++] = ret;
>> + }
>> +
>> + kxcjk1013_chip_ack_intr(data);
>> +
>> + mutex_unlock(&data->mutex);
>> +
>> + iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
>> time_ns);
>> +err:
>> + iio_trigger_notify_done(indio_dev->trig);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int kxcjk1013_data_rdy_trigger_set_state(struct iio_trigger
>> *trig,
>> + bool state)
>> +{
>> + struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
>> + struct kxcjk1013_data *data = iio_priv(indio_dev);
>> +
>> + if (state) {
>> + kxcjk1013_chip_setup_interrupt(data, true);
>> + kxcjk1013_set_mode(data, OPERATION);
>> + atomic_inc(&data->power_state);
>> + } else {
>> + if (!atomic_dec_and_test(&data->power_state))
>> + return 0;
>> + kxcjk1013_chip_setup_interrupt(data, false);
>> + kxcjk1013_set_mode(data, STANDBY);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static const struct iio_trigger_ops kxcjk1013_trigger_ops = {
>> + .set_trigger_state = kxcjk1013_data_rdy_trigger_set_state,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static int kxcjk1013_acpi_gpio_probe(struct i2c_client *client,
>> + struct kxcjk1013_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;
>> +
> Silly question, but does acpi not allow non gpio irqs?
> I can't see anything in this driver that requires it to be a gpio?
>> + 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, "kxcjk1013_int", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(dev, "acpi gpio get index failed\n");
>> + return PTR_ERR(gpio);
>> + }
>> +
>> + ret = gpiod_direction_input(gpio);
> I'm happy to accept that this is necessary but its uggly that we need to
> set the direction here.
>> + if (ret)
>> + return ret;
>> +
>> + ret = gpiod_to_irq(gpio);
>> + if (ret < 0)
>> + return ret;
>> +
>> + data->gpio_irq = ret;
>> +
>> + /* Update client irq if it is invalid */
>> + if (client->irq < 0)
>> + client->irq = data->gpio_irq;
> As commented below, why not check this first and not bother with the rest
> if client->irq >= 0
> Also isn't an irq of 0 always defined as bad these days? (I think this
> finally got unwound on ARM a while back).
>> +
>> + dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio),
>> + data->gpio_irq);
>> +
>> + return 0;
>> +}
>> +
>> +static int kxcjk1013_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct kxcjk1013_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 = kxcjk1013_chip_init(data);
>> + if (ret < 0)
>> + return ret;
>> +
>> + mutex_init(&data->mutex);
>> +
>> + indio_dev->dev.parent = &client->dev;
>> + indio_dev->channels = kxcjk1013_channels;
>> + indio_dev->num_channels = ARRAY_SIZE(kxcjk1013_channels);
>> + indio_dev->name = KXCJK1013_DRV_NAME;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> + indio_dev->info = &kxcjk1013_info;
>> +
>> + kxcjk1013_acpi_gpio_probe(client, data);
> No error handling for this? Perhaps checking before this if the
> irq is already defined rather than going through all the acpi calls
> then ignoring it if already present.
>
>> +
>> + if (client->irq < 0) {
>> + kxcjk1013_chip_setup_interrupt(data, false);
>> + goto skip_setup_trigger;
> Personally I'd prefer the logic reversed and avoid the goto.
> It'll add a level of indentation, but I think it'd still be a smigeon
> easier
> to follow.
>> + }
>> +
>> + 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, KXCJK1013_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 = &kxcjk1013_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, NULL,
>> + kxcjk1013_trigger_handler, NULL);
>> + if (ret < 0) {
>> + dev_err(&client->dev, "iio triggered buffer setup failed\n");
>> + goto err_trigger_unregister;
>> + }
>> +
>> +skip_setup_trigger:
>> + ret = devm_iio_device_register(&client->dev, indio_dev);
>> + if (ret < 0) {
>> + dev_err(&client->dev, "unable to register iio device\n");
>> + if (data->trig_mode)
>> + goto err_buffer_cleanup;
>> + else
>> + return ret;
> This a slightly convoluted bit of flow. I'd be tempted to just have
> all the trigger removal protected by if (data->trig_mode).
> It'll give more code and a fair bit of repition but straight forward
> flow. Usual arguement that I'd like every driver to look the same
> as it makes my life easier ;)
>> + }
>> +
>> + return 0;
>> +
>> +err_buffer_cleanup:
>> + iio_triggered_buffer_cleanup(indio_dev);
>> +err_trigger_unregister:
>> + iio_trigger_unregister(trig);
>> +err_trigger_free:
>> + iio_trigger_free(trig);
>> +
>> + return ret;
>> +}
>> +
>> +static int kxcjk1013_remove(struct i2c_client *client)
>> +{
>> + struct iio_dev *indio_dev = i2c_get_clientdata(client);
>> + struct kxcjk1013_data *data = iio_priv(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);
>> + kxcjk1013_set_mode(data, STANDBY);
>> + mutex_unlock(&data->mutex);
>> +
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int kxcjk1013_suspend(struct device *dev)
>> +{
>> + struct iio_dev *indio_dev = i2c_get_clientdata(to_i2c_client(dev));
>> + struct kxcjk1013_data *data = iio_priv(indio_dev);
>> +
>> + mutex_lock(&data->mutex);
>> + kxcjk1013_set_mode(data, STANDBY);
>> + mutex_unlock(&data->mutex);
>> +
>> + return 0;
>> +}
> Is this absense of a resume putting the state back as it was going
> to cause any unexpected behaviour? My first thought is that
> you might have a buffer associated with the trigger that seems to be
> enabled, but will never receive any data after a suspend / resume cycle.
>
>> +
>
>> +static SIMPLE_DEV_PM_OPS(kxcjk1013_pm_ops, kxcjk1013_suspend, NULL);
>> +#define KXCJK1013_PM_OPS (&kxcjk1013_pm_ops)
>> +#else
>> +#define KXCJK1013_PM_OPS NULL
>> +#endif
>> +
>> +static const struct acpi_device_id kx_acpi_match[] = {
>> + {"KXCJ1013", 0},
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(acpi, kx_acpi_match);
>> +
>> +static const struct i2c_device_id kxcjk1013_id[] = {
>> + {"kxcjk1013", 0},
>> + {}
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, kxcjk1013_id);
>> +
>> +static struct i2c_driver kxcjk1013_driver = {
>> + .driver = {
>> + .name = KXCJK1013_DRV_NAME,
>> + .acpi_match_table = ACPI_PTR(kx_acpi_match),
>> + .pm = KXCJK1013_PM_OPS,
>> + },
>> + .probe = kxcjk1013_probe,
>> + .remove = kxcjk1013_remove,
>> + .id_table = kxcjk1013_id,
>> +};
>> +module_i2c_driver(kxcjk1013_driver);
>> +
>> +MODULE_AUTHOR("Srinivas Pandruvada
>> <srinivas.pandruvada@linux.intel.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("KXCJK1013 accelerometer driver");
>>
>
>
next prev parent reply other threads:[~2014-06-11 1:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 17:26 [PATCH v1] iio: accel: kxcjk1013 3-axis accelerometer driver Srinivas Pandruvada
2014-06-07 19:01 ` Jonathan Cameron
2014-06-11 1:28 ` Srinivas Pandruvada [this message]
2014-06-11 5:22 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5397B0D1.4090104@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox