Re: CX24116 i2c patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 5, 2011 at 8:28 AM, Steven Toth <stoth@xxxxxxxxxxxxxx> wrote:
> Mauro,
>
>> Subject: [media] cx24116: add config option to split firmware download
>> Author:  Antti Palosaari <crope@xxxxxx>
>> 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?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux