RE: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
From: Tirdea, Irina
Date: Tue Feb 24 2015 - 12:26:11 EST
> -----Original Message-----
> From: Jonathan Cameron [mailto:jic23@xxxxxxxxxx]
> Sent: 21 February, 2015 20:30
> To: Tirdea, Irina; Peter Meerwald
> Cc: linux-iio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Pandruvada, Srinivas; Reus, Adriana
> Subject: Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
>
> On 20/02/15 12:02, Tirdea, Irina wrote:
> >
> >
> >> -----Original Message-----
> >> From: Peter Meerwald [mailto:pmeerw@xxxxxxxxxx]
> >> Sent: 16 February, 2015 21:26
> >> To: Tirdea, Irina
> >> Cc: Jonathan Cameron; linux-iio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Pandruvada, Srinivas; Reus, Adriana
> >> Subject: Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
> >>
> >>
> >>> Reading all axis values in one i2c transfer reduces the delays
> >>> introduced by the i2c bus. In case i2c block read is not supported,
> >>> fallback to reading each axis as a separate word.
> >>
> >> see comments inline below
> >>
> > Thanks for the review, Peter!
> >
> >>> Signed-off-by: Adriana Reus <adriana.reus@xxxxxxxxx>
> >>> Signed-off-by: Irina Tirdea <irina.tirdea@xxxxxxxxx>
> >>> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
> >>> ---
> >>> drivers/iio/accel/kxcjk-1013.c | 44 +++++++++++++++++++++++++++++++++---------
> >>> 1 file changed, 35 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> >>> index 5f27787..bfa2899 100644
> >>> --- a/drivers/iio/accel/kxcjk-1013.c
> >>> +++ b/drivers/iio/accel/kxcjk-1013.c
> >>> @@ -109,6 +109,8 @@ struct kxcjk1013_data {
> >>> int64_t timestamp;
> >>> enum kx_chipset chipset;
> >>> bool is_smo8500_device;
> >>> + s32 (*read_block_data)(const struct i2c_client *client, u8 command,
> >>> + u8 length, u8 *values);
> >>
> >> probably this could/should be done in the i2c layer or we end up adding a
> >> similar function in every driver?
> >>
> > Actually this is exactly what I did: adding this code in a couple of drivers :)
> > You are right, this belongs to the i2c core. Will move it there.
> A good idea. Might be possible to make this a transparent fallback so no
> special handling is needed in drivers at all (e.g. emulate the block read using
> the biggest read that is available) - taking care about the endian fun and
> games that results.
>
> Propose it to Wolfram and the i2c list and see what people think of it.
>
I'll do the block emulation code first and send it on the i2c list (still checking some endianness issues).
Once I'll have a response for the i2c part, I'll resend these patchsets with the required fixes.
Thanks,
Irina
> Jonathan
> >
> >>> };
> >>>
> >>> enum kxcjk1013_axis {
> >>> @@ -216,6 +218,23 @@ static const struct {
> >>> {800, 0, 0x06},
> >>> {1600, 0, 0x06} };
> >>>
> >>> +static s32 kxcjk1013_read_block_data(const struct i2c_client *client,
> >>> + u8 command, u8 length, u8 *values)
> >>> +{
> >>> + s32 data;
> >>> + u8 i;
> >>> +
> >>> + for (i = 0; i < length; i += 2) {
> >>> + data = i2c_smbus_read_word_data(client, command + i);
> >>> + if (data < 0)
> >>> + return data;
> >>> +
> >>> + values[i] = data & 0xFF;
> >>> + values[i+1] = data >> 8;
> >>
> >> this is incorrect; it forces the data to be little endian, however, the
> >> endianness (as specified in the driver's .scan_type) is IIO_CPU -- the
> >> code breaks for big-endian CPUs
> >>
> >> since _read_i2c_block_data() can't do endianness conversion (and the chip
> >> does i2c endianness, i.e. little-endian), the .scan_type should become
> >> IIO_LE and above code is correct again but still ugly :)
> >>
> >> bottom line: change .scan_type to IIO_LE
> >>
> > Good point. Changing the endianess to IIO_LE is correct for either kxcjk1013_read_block_data or i2c_smbus_read_i2c_block_data.
> > Will fix this in the next version. Thanks for catching this!
> >
> >>> + }
> >>> + return i;
> >>> +}
> >>> +
> >>> static int kxcjk1013_set_mode(struct kxcjk1013_data *data,
> >>> enum kxcjk1013_mode mode)
> >>> {
> >>> @@ -955,18 +974,14 @@ 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);
> >>> - int bit, ret, i = 0;
> >>> + int ret;
> >>>
> >>> mutex_lock(&data->mutex);
> >>> - for (bit = 0; bit < AXIS_MAX; bit++) {
> >>> - ret = kxcjk1013_get_acc_reg(data, bit);
> >>> - if (ret < 0) {
> >>> - mutex_unlock(&data->mutex);
> >>> - goto err;
> >>> - }
> >>> - data->buffer[i++] = ret;
> >>> - }
> >>> + ret = data->read_block_data(data->client, KXCJK1013_REG_XOUT_L,
> >>> + AXIS_MAX * 2, (u8 *) data->buffer);
> >>> mutex_unlock(&data->mutex);
> >>> + if (ret < 0)
> >>> + goto err;
> >>>
> >>> iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> >>> data->timestamp);
> >>> @@ -1196,6 +1211,11 @@ static int kxcjk1013_probe(struct i2c_client *client,
> >>> const char *name;
> >>> int ret;
> >>>
> >>> + if (!i2c_check_functionality(client->adapter,
> >>> + I2C_FUNC_SMBUS_BYTE_DATA |
> >>> + I2C_FUNC_SMBUS_READ_WORD_DATA))
> >>> + return -ENODEV;
> >>> +
> >>> indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> >>> if (!indio_dev)
> >>> return -ENOMEM;
> >>> @@ -1204,6 +1224,12 @@ static int kxcjk1013_probe(struct i2c_client *client,
> >>> i2c_set_clientdata(client, indio_dev);
> >>> data->client = client;
> >>>
> >>> + if (i2c_check_functionality(client->adapter,
> >>> + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> >>> + data->read_block_data = i2c_smbus_read_i2c_block_data;
> >>> + else
> >>> + data->read_block_data = kxcjk1013_read_block_data;
> >>> +
> >>> pdata = dev_get_platdata(&client->dev);
> >>> if (pdata)
> >>> data->active_high_intr = pdata->active_high_intr;
> >>>
> >>
> >> --
> >>
> >> Peter Meerwald
> >> +43-664-2444418 (mobile)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/