Topics

[RFC] I2C register access API


Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Hello all,

This is a proposal to add an API for reading, writing and updating
internal registers of I2C devices. This API would offer a simpler way of
communicating with I2C devices that have internal registers.

With the current I2C API, if you want to read the value of an internal
device register, you have to do an i2c_transfer call with two messages
(a write of the register address, followed by a read of the register
value).

Just looking at the sensor subsystem, all drivers define their own
register read/write functions which are more or less identical. This is
a case of code duplication that can be avoided if we add an API for
accessing registers.

I have written a patch that adds the I2C register access functions and
uploaded it to Gerrit [1]. All the new functions are implemented using
the existing I2C driver API.

What are your thoughts on this addition to the I2C API? If you think
this is a good idea, I can start updating the drivers to use the
register access function.

Thanks,
Bogdan

[1] https://gerrit.zephyrproject.org/r/#/c/1569/


Tomasz Bursztyka
 

Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)

Tomasz


Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Don't think burst write is that common, but it may be useful if a driver
wants to optimize write operations when configuring the chip.

The functions I wrote are for 8-bit registers/addresses which are the
most common cases. Some drivers can have 16-bit registers in which case
a burst write of 2 bytes can simulate a write of the 16-bit register.
One chip we wrote a driver for (SHT3xD) also has a 16-bit address, but
this is even less common than the 16-bit registers.

But I am not sure if we want to support 16-bit registers/addresses with
these functions, or leave them as exceptions (in which case the driver
will implement it's own register read/write functions).

For the case of symmetry and having the burst write function there if
future drivers will need it, I can add a i2c_reg_burst_write function as
well.

Bogdan

On Jo, 2016-04-21 at 11:44 +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)

Tomasz


Vlad Dogaru <vlad.dogaru@...>
 

On Thu, Apr 21, 2016 at 11:44:45AM +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!
Same here.

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)
The sx9500 driver makes a burst write at init to set a bunch of
configuration registers, so that's one user. Not sure about any others,
though.

Vlad


Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

On Jo, 2016-04-21 at 13:04 +0300, Vlad Dogaru wrote:
On Thu, Apr 21, 2016 at 11:44:45AM +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!
Same here.

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)
The sx9500 driver makes a burst write at init to set a bunch of
configuration registers, so that's one user. Not sure about any others,
though.
Good enough for me. Will also add burst write.

Bogdan


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Apr 21, 2016 at 09:19:56AM +0000, Davidoaia, Bogdan M wrote:
Hello all,

This is a proposal to add an API for reading, writing and updating
internal registers of I2C devices. This API would offer a simpler way of
communicating with I2C devices that have internal registers.

With the current I2C API, if you want to read the value of an internal
device register, you have to do an i2c_transfer call with two messages
(a write of the register address, followed by a read of the register
value).

Just looking at the sensor subsystem, all drivers define their own
register read/write functions which are more or less identical. This is
a case of code duplication that can be avoided if we add an API for
accessing registers.
Always in favour of removing code duplication! :)

I have written a patch that adds the I2C register access functions and
uploaded it to Gerrit [1]. All the new functions are implemented using
the existing I2C driver API.

What are your thoughts on this addition to the I2C API? If you think
this is a good idea, I can start updating the drivers to use the
register access function.

Thanks,
Bogdan

[1] https://gerrit.zephyrproject.org/r/#/c/1569/


Maureen Helm
 

-----Original Message-----
From: Vlad Dogaru [mailto:vlad.dogaru(a)intel.com]
Sent: Thursday, April 21, 2016 5:04 AM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: [RFC] I2C register access API

On Thu, Apr 21, 2016 at 11:44:45AM +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!
Same here.

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)
The sx9500 driver makes a burst write at init to set a bunch of configuration
registers, so that's one user. Not sure about any others, though.
This is pretty common for sensors. A burst read would be useful too, particularly for sensors that have internal FIFOs.