linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Do you always need a client driver to access a I2C device?
@ 2010-02-24 19:11 Steve
       [not found] ` <4B8579C4.7080502-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Steve @ 2010-02-24 19:11 UTC (permalink / raw)
  To: linux-i2c-u79uwXL29TY76Z2rM5mHXA

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Do you always need a client driver to access a I2C device?
       [not found] ` <4B8579C4.7080502-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
@ 2010-03-04 15:06   ` Jean Delvare
  0 siblings, 0 replies; 2+ messages in thread
From: Jean Delvare @ 2010-03-04 15:06 UTC (permalink / raw)
  To: Steve; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA

Hi Steve,

On Wed, 24 Feb 2010 19:11:00 +0000, Steve wrote:
> 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.

This is the most popular way, and in most cases the most practical too,
but is not mandatory.

> 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().

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.

> 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 is appropriate, if you keep in mind the associated limitations
(see below.)

> 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.

> 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.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-03-04 15:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-24 19:11 Do you always need a client driver to access a I2C device? Steve
     [not found] ` <4B8579C4.7080502-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2010-03-04 15:06   ` Jean Delvare

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).