From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from zone0.gcu-squad.org ([212.85.147.21]:38944 "EHLO services.gcu-squad.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754800Ab1KIKwP (ORCPT ); Wed, 9 Nov 2011 05:52:15 -0500 Date: Wed, 9 Nov 2011 11:52:04 +0100 From: Jean Delvare To: Antti Palosaari Cc: Mauro Carvalho Chehab , linux-media , Michael Krufky Subject: Re: [RFC 1/2] dvb-core: add generic helper function for I2C register Message-ID: <20111109115204.401a8aa5@endymion.delvare> In-Reply-To: <4EBA58E0.8080704@iki.fi> References: <4EB9C13A.2060707@iki.fi> <4EBA4E3D.80105@redhat.com> <4EBA58E0.8080704@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: On Wed, 09 Nov 2011 12:41:36 +0200, Antti Palosaari wrote: > On 11/09/2011 11:56 AM, Mauro Carvalho Chehab wrote: > > Due to the way I2C locks are bound, doing something like the above and something like: > > > > struct i2c_msg msg[2] = { > > { > > .addr = i2c_cfg->addr, > > .flags = 0, > > .buf = buf, > > }, > > { > > .addr = i2c_cfg->addr, > > .flags = 0, > > .buf = buf2, > > } > > > > }; > > > > ret = i2c_transfer(i2c_cfg->adapter, msg, 2); > > > > Produces a different result. In the latter case, I2C core avoids having any other > > transaction in the middle of the 2 messages. > > In my understanding adding more messages than one means those should be > handled as one I2C transaction using REPEATED START. > I see one big problem here, it is our adapters. I think again, for the > experience I have, most of our I2C-adapters can do only 3 different > types of I2C xfers; > * I2C write > * I2C write + I2C read (combined with REPEATED START) > * I2C read (I suspect many adapters does not support that) > That means, I2C REPEATED writes are not possible. Also, some adapters _or slaves_ won't support more than one repeated start in a given transaction, so splitting block reads in continuous chunks won't always work either. Which makes some sense if you think about it: if both the slave and the controller supported larger blocks then there would be no need to split the transfer into multiple messages in the first place. -- Jean Delvare