From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: Calling an I2C camera sensor with SMBUS API? Date: Fri, 12 Dec 2008 08:46:48 -0800 Message-ID: <200812120846.48960.david-b@pacbell.net> References: <20081212164426.27b4f5cd@hyperion.delvare> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20081212164426.27b4f5cd-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org> Content-Disposition: inline Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jean Delvare Cc: "Aguirre Rodriguez, Sergio Alberto" , "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Hiremath, Vaibhav" List-Id: linux-i2c@vger.kernel.org On Friday 12 December 2008, Jean Delvare wrote: > > So, should this automatically discard using SMBUS api for my case, or am > > I missing something else? (like a SMBUS 16-bit expansion or so) > > You are correct, SMBus messaging implies an 8-bit command field (which > is most frequently used for register addressing.) There are no 16-bit > command variants. How about the "proc call" ... 16 bits to the slave, 16 bits back? That would be like a "read 16 bit register with 16 bit address". ISTR we had that a routine supporting that at one point (and the infrastructure for it is still there, emulation and all) but it was removed because it was still seeking its first use. > For writes, we can cheat because there is no > direction change between the address and the data, Cheat how? > but for reads > there's simply nothing we can do to work around this limitation. So, > unless your device is write-only, you indeed can't use the SMBus-level > API for 16-bit register addresses and you have to stick to the > I2C-level API. If addresses and data are both 16 bits, I only see how to do reads, not writes, within the scope of the SMBus calls. Of course, SMBus also supports byte and (small-)counted-array data too. - Dave > -- > Jean Delvare > >