public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Malcolm Priestley <tvboxspy@gmail.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Antti Palosaari <crope@iki.fi>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	linux-media <linux-media@vger.kernel.org>,
	Michael Krufky <mkrufky@kernellabs.com>
Subject: Re: [RFC 1/2] dvb-core: add generic helper function for I2C register
Date: Wed, 09 Nov 2011 20:41:27 +0000	[thread overview]
Message-ID: <4EBAE577.5090603@gmail.com> (raw)
In-Reply-To: <20111109115204.401a8aa5@endymion.delvare>

On 09/11/11 10:52, Jean Delvare wrote:
> 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.
>

Yes, I can immediately think of the stv0288 which can receive up to 108 
bytes continuous write of its register map, but using the lme2510c 
controller won't write more than 16, probably beyond the limit of the 
firmwares buffer.

I think mostly, you are at the mercy of the controller firmware and not 
really the host i2c controller abilities.

Regards

Malcolm

  reply	other threads:[~2011-11-09 20:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-08 23:54 [RFC 1/2] dvb-core: add generic helper function for I2C register Antti Palosaari
2011-11-09  4:48 ` Michael Krufky
2011-11-09  9:56 ` Mauro Carvalho Chehab
2011-11-09 10:37   ` Jean Delvare
2011-11-09 11:00     ` Antti Palosaari
2011-11-09 12:02     ` Mauro Carvalho Chehab
2011-11-10  8:26       ` Jean Delvare
2011-11-09 15:51     ` Antti Palosaari
2011-11-09 10:41   ` Antti Palosaari
2011-11-09 10:52     ` Jean Delvare
2011-11-09 20:41       ` Malcolm Priestley [this message]
2011-11-14 13:52 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EBAE577.5090603@gmail.com \
    --to=tvboxspy@gmail.com \
    --cc=crope@iki.fi \
    --cc=khali@linux-fr.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mkrufky@kernellabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox