From: "Pandruvada, Srinivas" <srinivas.pandruvada-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org"
<wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
"mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
<mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org"
<pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org>,
"linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Tirdea,
Irina" <irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
Date: Fri, 21 Aug 2015 15:59:05 +0000 [thread overview]
Message-ID: <1440172701.4081.1.camel@intel.com> (raw)
In-Reply-To: <20150821102125.GA1656@katana>
On Fri, 2015-08-21 at 12:21 +0200, Wolfram Sang wrote:
> On Mon, Aug 17, 2015 at 11:09:43AM +0200, Markus Pargmann wrote:
> > On Sun, Aug 16, 2015 at 10:24:47AM +0100, Jonathan Cameron wrote:
> > > On 12/08/15 15:31, Irina Tirdea wrote:
> > > > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > > > enable/disable the bus at each i2c transfer and must wait for
> > > > the enable/disable to happen before sending the data.
> > > >
> > > > When reading data in the trigger handler, the bmg160 driver
> > > > does
> > > > one i2c transfer for each axis. This has an impact on the
> > > > frequency
> > > > of the gyroscope at high sample rates due to additional delays
> > > > introduced by the i2c bus at each transfer.
> > > >
> > > > Reading all axis values in one i2c transfer reduces the delays
> > > > introduced by the i2c bus. Uses
> > > > i2c_smbus_read_i2c_block_data_or_emulated
> > > > that will fallback to reading each axis as a separate word in
> > > > case i2c
> > > > block read is not supported.
> > > >
> > > > Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
> > > > Acked-by: Jonathan Cameron <jic23@kernel.org>
> > > > Acked-by: Srinivas Pandruvada <
> > > > srinivas.pandruvada@linux.intel.com>
> > > Note, that in the meantime the bmg160 driver just went all regmap
> > > on us (as part of adding SPI support - though that step hasn't
> > > happened yet). Hence we'll need a means of telling regmap about
> > > this
> > > possibility.
> >
> > Perhaps this is covered by a regmap_bulk_read()?
> >
> > The series[1] I am working on implements a i2c smbus block data
> > regmap
> > bus driver. Regmap should then automatically do a block read in
> > regmap_bulk_read.
>
> Hmm, so doesn't your series make Irina's series obsolete? It
> addresses
> the same problem only at a different layer (i2c core vs. regmap), or?
> It
> would mean that i2c client drivers which want to support byte, word,
> or
> block transfers should be converted to regmap. I assume most of the
> potential candidates are register based devices anyhow. Then, regmap
> would be the proper abstraction layer. Have I overlooked something?
>
This is the only driver converted to use regmap, because of SPI mode
support. The other drivers will still use Irina's changes.
Thanks
Srinivas
> Thanks,
>
> Wolfram
>
WARNING: multiple messages have this Message-ID (diff)
From: "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
To: "wsa@the-dreams.de" <wsa@the-dreams.de>,
"mpa@pengutronix.de" <mpa@pengutronix.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"jic23@kernel.org" <jic23@kernel.org>,
"Tirdea, Irina" <irina.tirdea@intel.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
Date: Fri, 21 Aug 2015 15:59:05 +0000 [thread overview]
Message-ID: <1440172701.4081.1.camel@intel.com> (raw)
In-Reply-To: <20150821102125.GA1656@katana>
T24gRnJpLCAyMDE1LTA4LTIxIGF0IDEyOjIxICswMjAwLCBXb2xmcmFtIFNhbmcgd3JvdGU6DQo+
IE9uIE1vbiwgQXVnIDE3LCAyMDE1IGF0IDExOjA5OjQzQU0gKzAyMDAsIE1hcmt1cyBQYXJnbWFu
biB3cm90ZToNCj4gPiBPbiBTdW4sIEF1ZyAxNiwgMjAxNSBhdCAxMDoyNDo0N0FNICswMTAwLCBK
b25hdGhhbiBDYW1lcm9uIHdyb3RlOg0KPiA+ID4gT24gMTIvMDgvMTUgMTU6MzEsIElyaW5hIFRp
cmRlYSB3cm90ZToNCj4gPiA+ID4gU29tZSBpMmMgYnVzc2VzIChlLmcuOiBTeW5vcHN5cyBEZXNp
Z25XYXJlIEkyQyBhZGFwdGVyKSBuZWVkIHRvDQo+ID4gPiA+IGVuYWJsZS9kaXNhYmxlIHRoZSBi
dXMgYXQgZWFjaCBpMmMgdHJhbnNmZXIgYW5kIG11c3Qgd2FpdCBmb3INCj4gPiA+ID4gdGhlIGVu
YWJsZS9kaXNhYmxlIHRvIGhhcHBlbiBiZWZvcmUgc2VuZGluZyB0aGUgZGF0YS4NCj4gPiA+ID4g
DQo+ID4gPiA+IFdoZW4gcmVhZGluZyBkYXRhIGluIHRoZSB0cmlnZ2VyIGhhbmRsZXIsIHRoZSBi
bWcxNjAgZHJpdmVyIA0KPiA+ID4gPiBkb2VzDQo+ID4gPiA+IG9uZSBpMmMgdHJhbnNmZXIgZm9y
IGVhY2ggYXhpcy4gVGhpcyBoYXMgYW4gaW1wYWN0IG9uIHRoZSANCj4gPiA+ID4gZnJlcXVlbmN5
DQo+ID4gPiA+IG9mIHRoZSBneXJvc2NvcGUgYXQgaGlnaCBzYW1wbGUgcmF0ZXMgZHVlIHRvIGFk
ZGl0aW9uYWwgZGVsYXlzDQo+ID4gPiA+IGludHJvZHVjZWQgYnkgdGhlIGkyYyBidXMgYXQgZWFj
aCB0cmFuc2Zlci4NCj4gPiA+ID4gDQo+ID4gPiA+IFJlYWRpbmcgYWxsIGF4aXMgdmFsdWVzIGlu
IG9uZSBpMmMgdHJhbnNmZXIgcmVkdWNlcyB0aGUgZGVsYXlzDQo+ID4gPiA+IGludHJvZHVjZWQg
YnkgdGhlIGkyYyBidXMuIFVzZXMgDQo+ID4gPiA+IGkyY19zbWJ1c19yZWFkX2kyY19ibG9ja19k
YXRhX29yX2VtdWxhdGVkDQo+ID4gPiA+IHRoYXQgd2lsbCBmYWxsYmFjayB0byByZWFkaW5nIGVh
Y2ggYXhpcyBhcyBhIHNlcGFyYXRlIHdvcmQgaW4gDQo+ID4gPiA+IGNhc2UgaTJjDQo+ID4gPiA+
IGJsb2NrIHJlYWQgaXMgbm90IHN1cHBvcnRlZC4NCj4gPiA+ID4gDQo+ID4gPiA+IFNpZ25lZC1v
ZmYtYnk6IElyaW5hIFRpcmRlYSA8aXJpbmEudGlyZGVhQGludGVsLmNvbT4NCj4gPiA+ID4gQWNr
ZWQtYnk6IEpvbmF0aGFuIENhbWVyb24gPGppYzIzQGtlcm5lbC5vcmc+DQo+ID4gPiA+IEFja2Vk
LWJ5OiBTcmluaXZhcyBQYW5kcnV2YWRhIDwNCj4gPiA+ID4gc3Jpbml2YXMucGFuZHJ1dmFkYUBs
aW51eC5pbnRlbC5jb20+DQo+ID4gPiBOb3RlLCB0aGF0IGluIHRoZSBtZWFudGltZSB0aGUgYm1n
MTYwIGRyaXZlciBqdXN0IHdlbnQgYWxsIHJlZ21hcA0KPiA+ID4gb24gdXMgKGFzIHBhcnQgb2Yg
YWRkaW5nIFNQSSBzdXBwb3J0IC0gdGhvdWdoIHRoYXQgc3RlcCBoYXNuJ3QNCj4gPiA+IGhhcHBl
bmVkIHlldCkuICBIZW5jZSB3ZSdsbCBuZWVkIGEgbWVhbnMgb2YgdGVsbGluZyByZWdtYXAgYWJv
dXQgDQo+ID4gPiB0aGlzDQo+ID4gPiBwb3NzaWJpbGl0eS4NCj4gPiANCj4gPiBQZXJoYXBzIHRo
aXMgaXMgY292ZXJlZCBieSBhIHJlZ21hcF9idWxrX3JlYWQoKT8NCj4gPiANCj4gPiBUaGUgc2Vy
aWVzWzFdIEkgYW0gd29ya2luZyBvbiBpbXBsZW1lbnRzIGEgaTJjIHNtYnVzIGJsb2NrIGRhdGEg
DQo+ID4gcmVnbWFwDQo+ID4gYnVzIGRyaXZlci4gUmVnbWFwIHNob3VsZCB0aGVuIGF1dG9tYXRp
Y2FsbHkgZG8gYSBibG9jayByZWFkIGluDQo+ID4gcmVnbWFwX2J1bGtfcmVhZC4NCj4gDQo+IEht
bSwgc28gZG9lc24ndCB5b3VyIHNlcmllcyBtYWtlIElyaW5hJ3Mgc2VyaWVzIG9ic29sZXRlPyBJ
dCANCj4gYWRkcmVzc2VzDQo+IHRoZSBzYW1lIHByb2JsZW0gb25seSBhdCBhIGRpZmZlcmVudCBs
YXllciAoaTJjIGNvcmUgdnMuIHJlZ21hcCksIG9yPyANCj4gSXQNCj4gd291bGQgbWVhbiB0aGF0
IGkyYyBjbGllbnQgZHJpdmVycyB3aGljaCB3YW50IHRvIHN1cHBvcnQgYnl0ZSwgd29yZCwgDQo+
IG9yDQo+IGJsb2NrIHRyYW5zZmVycyBzaG91bGQgYmUgY29udmVydGVkIHRvIHJlZ21hcC4gSSBh
c3N1bWUgbW9zdCBvZiB0aGUNCj4gcG90ZW50aWFsIGNhbmRpZGF0ZXMgYXJlIHJlZ2lzdGVyIGJh
c2VkIGRldmljZXMgYW55aG93LiBUaGVuLCByZWdtYXANCj4gd291bGQgYmUgdGhlIHByb3BlciBh
YnN0cmFjdGlvbiBsYXllci4gSGF2ZSBJIG92ZXJsb29rZWQgc29tZXRoaW5nPw0KPiANClRoaXMg
aXMgdGhlIG9ubHkgZHJpdmVyIGNvbnZlcnRlZCB0byB1c2UgcmVnbWFwLCBiZWNhdXNlIG9mIFNQ
SSBtb2RlDQpzdXBwb3J0LiBUaGUgb3RoZXIgZHJpdmVycyB3aWxsIHN0aWxsIHVzZSBJcmluYSdz
IGNoYW5nZXMuDQoNClRoYW5rcw0KU3Jpbml2YXMNCg0KDQo+IFRoYW5rcywNCj4gDQo+ICAgIFdv
bGZyYW0NCj4g
WARNING: multiple messages have this Message-ID (diff)
From: "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
To: "wsa@the-dreams.de" <wsa@the-dreams.de>,
"mpa@pengutronix.de" <mpa@pengutronix.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"jic23@kernel.org" <jic23@kernel.org>,
"Tirdea, Irina" <irina.tirdea@intel.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
Date: Fri, 21 Aug 2015 15:59:05 +0000 [thread overview]
Message-ID: <1440172701.4081.1.camel@intel.com> (raw)
In-Reply-To: <20150821102125.GA1656@katana>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2504 bytes --]
On Fri, 2015-08-21 at 12:21 +0200, Wolfram Sang wrote:
> On Mon, Aug 17, 2015 at 11:09:43AM +0200, Markus Pargmann wrote:
> > On Sun, Aug 16, 2015 at 10:24:47AM +0100, Jonathan Cameron wrote:
> > > On 12/08/15 15:31, Irina Tirdea wrote:
> > > > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > > > enable/disable the bus at each i2c transfer and must wait for
> > > > the enable/disable to happen before sending the data.
> > > >
> > > > When reading data in the trigger handler, the bmg160 driver
> > > > does
> > > > one i2c transfer for each axis. This has an impact on the
> > > > frequency
> > > > of the gyroscope at high sample rates due to additional delays
> > > > introduced by the i2c bus at each transfer.
> > > >
> > > > Reading all axis values in one i2c transfer reduces the delays
> > > > introduced by the i2c bus. Uses
> > > > i2c_smbus_read_i2c_block_data_or_emulated
> > > > that will fallback to reading each axis as a separate word in
> > > > case i2c
> > > > block read is not supported.
> > > >
> > > > Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
> > > > Acked-by: Jonathan Cameron <jic23@kernel.org>
> > > > Acked-by: Srinivas Pandruvada <
> > > > srinivas.pandruvada@linux.intel.com>
> > > Note, that in the meantime the bmg160 driver just went all regmap
> > > on us (as part of adding SPI support - though that step hasn't
> > > happened yet). Hence we'll need a means of telling regmap about
> > > this
> > > possibility.
> >
> > Perhaps this is covered by a regmap_bulk_read()?
> >
> > The series[1] I am working on implements a i2c smbus block data
> > regmap
> > bus driver. Regmap should then automatically do a block read in
> > regmap_bulk_read.
>
> Hmm, so doesn't your series make Irina's series obsolete? It
> addresses
> the same problem only at a different layer (i2c core vs. regmap), or?
> It
> would mean that i2c client drivers which want to support byte, word,
> or
> block transfers should be converted to regmap. I assume most of the
> potential candidates are register based devices anyhow. Then, regmap
> would be the proper abstraction layer. Have I overlooked something?
>
This is the only driver converted to use regmap, because of SPI mode
support. The other drivers will still use Irina's changes.
Thanks
Srinivas
> Thanks,
>
> Wolfram
> ÿôèº{.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-08-21 15:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 14:31 [PATCH v5 0/8] Add support for best effort block read emulation Irina Tirdea
2015-08-12 14:31 ` Irina Tirdea
[not found] ` <1439389900-10108-1-git-send-email-irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-12 14:31 ` [PATCH v5 1/8] i2c: core: " Irina Tirdea
2015-08-12 14:31 ` Irina Tirdea
[not found] ` <1439389900-10108-2-git-send-email-irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-14 18:23 ` Wolfram Sang
2015-08-14 18:23 ` Wolfram Sang
2015-08-12 14:31 ` [PATCH v5 2/8] eeprom: at24: use i2c_smbus_read_i2c_block_data_or_emulated Irina Tirdea
[not found] ` <1439389900-10108-3-git-send-email-irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-14 18:24 ` Wolfram Sang
2015-08-14 18:24 ` Wolfram Sang
2015-08-15 12:56 ` Jonathan Cameron
2015-08-15 12:56 ` Jonathan Cameron
2015-08-12 14:31 ` [PATCH v5 3/8] iio: accel: bmc150: use available_scan_masks Irina Tirdea
2015-08-12 14:31 ` [PATCH v5 4/8] iio: accel: bmc150: optimize i2c transfers in trigger handler Irina Tirdea
2015-08-12 14:31 ` [PATCH v5 5/8] iio: gyro: bmg160: use available_scan_masks Irina Tirdea
2015-08-12 14:31 ` [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler Irina Tirdea
2015-08-16 9:24 ` Jonathan Cameron
2015-08-17 9:09 ` Markus Pargmann
[not found] ` <20150817090943.GO19600-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2015-08-17 9:48 ` Tirdea, Irina
2015-08-17 9:48 ` Tirdea, Irina
2015-08-17 9:48 ` Tirdea, Irina
2015-08-21 10:21 ` Wolfram Sang
2015-08-21 10:21 ` Wolfram Sang
2015-08-21 15:59 ` Pandruvada, Srinivas [this message]
2015-08-21 15:59 ` Pandruvada, Srinivas
2015-08-21 15:59 ` Pandruvada, Srinivas
[not found] ` <1440172701.4081.1.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-22 4:02 ` Wolfram Sang
2015-08-22 4:02 ` Wolfram Sang
2015-08-22 17:29 ` Jonathan Cameron
2015-08-22 17:29 ` Jonathan Cameron
2015-08-24 11:49 ` Wolfram Sang
[not found] ` <55D056DF.5020201-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2015-08-17 9:34 ` Tirdea, Irina
2015-08-17 9:34 ` Tirdea, Irina
2015-08-12 14:31 ` [PATCH v5 7/8] iio: accel: kxcjk-1013: use available_scan_masks Irina Tirdea
2015-08-12 14:31 ` [PATCH v5 8/8] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler Irina Tirdea
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=1440172701.4081.1.camel@intel.com \
--to=srinivas.pandruvada-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=irina.tirdea-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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 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.