From: "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
To: "Tirdea, Irina" <irina.tirdea@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"jic23@kernel.org" <jic23@kernel.org>,
"Reus, Adriana" <adriana.reus@intel.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
Date: Fri, 20 Feb 2015 14:58:51 +0000 [thread overview]
Message-ID: <1424444331.2916.2.camel@spandruv-mobl2> (raw)
In-Reply-To: <1F3AC3675D538145B1661F571FE1805F19A20D9C@irsmsx105.ger.corp.intel.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5391 bytes --]
On Fri, 2015-02-20 at 12:02 +0000, Tirdea, Irina wrote:
>
> > -----Original Message-----
> > From: Peter Meerwald [mailto:pmeerw@pmeerw.net]
> > Sent: 16 February, 2015 21:26
> > To: Tirdea, Irina
> > Cc: Jonathan Cameron; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; 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@intel.com>
> > > Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
> > > Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> > > ---
> > > 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.
>
> > > };
> > >
> > > 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!
>
I don't think changing to IIO_LE is good idea as when i2c_read_bock..
then the scan type will be CPU. So better to fix endianness in this
function.
> > > + }
> > > + 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)
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2015-02-20 14:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 18:21 [PATCH 0/2] kxcjk-1013 driver optimizations Irina Tirdea
2015-02-16 18:21 ` [PATCH 1/2] iio: accel: kxcjk-1013: use available_scan_masks Irina Tirdea
2015-02-16 18:21 ` [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler Irina Tirdea
2015-02-16 19:26 ` Peter Meerwald
2015-02-20 12:02 ` Tirdea, Irina
2015-02-20 14:58 ` Pandruvada, Srinivas [this message]
2015-02-20 15:23 ` Peter Meerwald
2015-02-20 15:27 ` Pandruvada, Srinivas
2015-02-21 18:29 ` Jonathan Cameron
2015-02-24 17:25 ` Tirdea, Irina
2015-02-16 19:14 ` [PATCH 0/2] kxcjk-1013 driver optimizations Peter Meerwald
2015-02-20 12:03 ` Tirdea, Irina
2015-02-21 18:26 ` Jonathan Cameron
2015-02-24 17:22 ` Tirdea, Irina
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=1424444331.2916.2.camel@spandruv-mobl2 \
--to=srinivas.pandruvada@intel.com \
--cc=adriana.reus@intel.com \
--cc=irina.tirdea@intel.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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
all inboxes | Powered by JetHome®