Do you always need a client driver to access a I2C device?
Hi,
I am modifying an embedded kernel driver to use the Linux I2C sub-system rather than the RTOS I2C calls it previously used. The driver just needs to make a very small number of I2C read/writes to a device on the I2C bus at a fixed address and does not need to expose any methods to user-space via /dev or sysfs. An algorithm and adapter driver are provided for the SoC that controls the board, but there are no client drivers.
I have been reading the Documentation/i2d doc and looking at some of the existing drivers. I only need to read/write a few bytes to the device but from the doc, examples and i2c api it appeared I would need to write a client driver for the device to obtain the i2c_client ptr I needed to do that. Along with the appropriate board_info for the devices on the board.
However I noticed that the DTV demodulator drivers, e.g. drivers/media/dvb/frontends/au8522.c, appear to be doing it simply using a i2c_adapter ptr and i2c_transfer().
For my simple needs, access fixed embedded device, no need for user space access, is the i2c_adapter ptr a simple and "appropriate" way to go or am I missing something that makes it more complex than it seems? This assumes its straight forward to get the adapter ptr from the SoC adapter driver of course. Perhaps I should be doing a client driver instead after all?
I think I have spent too long looking through the sub-system infrastructure source and have ended up confusing myself somewhat. I just want to make sure I am on the correct path before continuing with my reading and investigating. The kernel version is 2.6.27.39.
Thanks
Steve
Hi Steve,
Quoted 8 lines · Steve
I am modifying an embedded kernel driver to use the Linux I2C sub-system rather than the RTOS I2C calls it previously used. The driver just needs to make a very small number of I2C read/writes to a device on the I2C bus at a fixed address and does not need to expose any methods to user-space via /dev or sysfs. An algorithm and adapter driver are provided for the SoC that controls the board, but there are no client drivers.
Quoted 5 lines
I have been reading the
Documentation/i2ddoc and looking at some of the existing drivers. I only need to read/write a few bytes to the device but from the doc, examples and i2c api it appeared I would need to write a client driver for the device to obtain thei2c_clientptr I needed to do that. Along with the appropriateboard_infofor the devices on the board.
This is the most popular way, and in most cases the most practical too, but is not mandatory.
Quoted 3 lines
However I noticed that the DTV demodulator drivers, e.g.
drivers/media/dvb/frontends/au8522.c, appear to be doing it simply using ai2c_adapterptr andi2c_transfer().
Correct. This approach in DVB predates the relatively recent rework of the i2c device binding model. If it had to be designed from scratch today, I suspect they would use i2c clients, but back then, the i2c binding model was too unappealing to them.
Quoted 3 lines
For my simple needs, access fixed embedded device, no need for user space access, is the
i2c_adapterptr a simple and "appropriate" way to go or am I missing something that makes it more complex than it seems?
This is appropriate, if you keep in mind the associated limitations (see below.)
Quoted 3 lines
This assumes its straight forward to get the adapter ptr from the SoC adapter driver of course. Perhaps I should be doing a client driver instead after all?
In general, SoC adapters have a fixed number (they are registered using i2c_add_numbered_adapter()), so you can easily get a handle using i2c_get_adapter(n). Don't forget to call i2c_put_adapter(adapter) when you're done.
Quoted 4 lines
I think I have spent too long looking through the sub-system infrastructure source and have ended up confusing myself somewhat. I just want to make sure I am on the correct path before continuing with my reading and investigating. The kernel version is 2.6.27.39.
Accessing the device without a client is definitely an option. You only have to consider the following two issues which are inherent to this approach:
* There is no exclusive access guaranteed if you do not instantiate and use an i2c client for a specific device address. Other parts of the kernel. Other parts of the kernel, as well as user-space, will be able to access your device too, and you'll never know.
* The access API without a client is fairly limited, basically you have to rely on i2c_transfer() for raw I2C access or the heavy-weight i2c_smbus_xfer() for SMBus access (required if the underlying controller can't do raw I2C.) These functions are less convenient that the i2c_master_*() and i2c_smbus_*() functions which operate on i2c clients for simple transactions.
Still, it can be done if such is your desire.
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/wishlist.html