linux-kernel - Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1440172701.4081.1.camel@intel.com>
Date:	Fri, 21 Aug 2015 15:59:05 +0000
From:	"Pandruvada, Srinivas" <srinivas.pandruvada@...el.com>
To:	"wsa@...-dreams.de" <wsa@...-dreams.de>,
	"mpa@...gutronix.de" <mpa@...gutronix.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pmeerw@...erw.net" <pmeerw@...erw.net>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"jic23@...nel.org" <jic23@...nel.org>,
	"Tirdea, Irina" <irina.tirdea@...el.com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in
 trigger handler

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@...el.com>
> > > > Acked-by: Jonathan Cameron <jic23@...nel.org>
> > > > Acked-by: Srinivas Pandruvada <
> > > > srinivas.pandruvada@...ux.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
>