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@xxxxxxxxx> > > > Acked-by: Jonathan Cameron <jic23@xxxxxxxxxx> > > > Acked-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx> > > 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? Thanks, Wolfram
Attachment:
signature.asc
Description: Digital signature
