public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Steven Toth <stoth@kernellabs.com>,
	Linux-Media <linux-media@vger.kernel.org>
Subject: Re: CX24116 i2c patch
Date: Thu, 05 May 2011 13:55:05 -0300	[thread overview]
Message-ID: <4DC2D669.9020000@redhat.com> (raw)
In-Reply-To: <BANLkTimiA1k-pbwuri1vAFgsfSwkdTJWAA@mail.gmail.com>

Em 05-05-2011 12:25, Devin Heitmueller escreveu:
> On Thu, May 5, 2011 at 8:28 AM, Steven Toth <stoth@kernellabs.com> wrote:
>> Mauro,
>>
>>> Subject: [media] cx24116: add config option to split firmware download
>>> Author:  Antti Palosaari <crope@iki.fi>
>>> Date:    Wed Apr 27 21:03:07 2011 -0300
>>>
>>> It is very rare I2C adapter hardware which can provide 32kB I2C write
>>> as one write. Add .i2c_wr_max option to set desired max packet size.
>>> Split transaction to smaller pieces according to that option.
>>
>> This is none-sense. I'm naking this patch, please unqueue, regress or whatever.
>>
>> The entire point of the i2c message send is that the i2c drivers know
>> nothing about the host i2c implementation, and they should not need
>> to. I2C SEND and RECEIVE are abstract and require no knowledge of the
>> hardware. This is dangerous and generates non-atomic register writes.
>> You cannot guarantee that another thread isn't reading/writing to
>> other registers in the part - breaking the driver.
>>
>> Please fix the host controller to split the i2c messages accordingly
>> (and thus keeping the entire transaction atomic).
>>
>> This is the second time I've seen the 'fix' to a problem by patching
>> the i2c driver. Fix the i2c bridge else we'll see this behavior
>> spreading to multiple i2c driver. It's just wrong.
> 
> I tend to agree with Steven on this one.  That said, these sorts of
> things usually get introduced in cases where the i2c master is not
> well enough understood to know how to split the transactions and still
> preserve the repeat start (common with reverse engineered drivers).
> It can also occur in cases where there really is a hardware limitation
> that prevents the caller from making multiple requests to the chip
> while not sending the stop bit (although this is less common).
> 
> Do we know this to be the case with the anysee bridge?  Is this a
> reverse engineered device?  Is there documentation/datasheets to
> reference?

> 
> Do we know if this is an issue with the i2c master driver not being
> fully baked, or if it's a hardware limitation?

I can't tell you how Antti is working, but, since this is a USB device,
and cx24116 is trying to send a 32KB message via one single I2C transfer,
I can tell you for sure that that this won't work.

USB control messages can have, at maximum, 80 bytes of data on it. So,
the message needs to be broken into 80-byte payloads (assuming that
Anysee accepts the maximum size).

Mauro.


  reply	other threads:[~2011-05-05 16:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 12:28 CX24116 i2c patch Steven Toth
2011-05-05 13:15 ` Mauro Carvalho Chehab
2011-05-05 15:09   ` Jean Delvare
2011-05-05 16:18     ` Mauro Carvalho Chehab
2011-05-16 15:33       ` Jean Delvare
2011-05-05 15:34   ` Devin Heitmueller
2011-05-05 16:38     ` Mauro Carvalho Chehab
2011-05-05 15:25 ` Devin Heitmueller
2011-05-05 16:55   ` Mauro Carvalho Chehab [this message]
2011-05-05 22:03     ` Antti Palosaari

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=4DC2D669.9020000@redhat.com \
    --to=mchehab@redhat.com \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.org \
    --cc=stoth@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