Em 27-10-2010 13:48, Devin Heitmueller escreveu:> On Wed, Oct 27, 2010 at 11:41 AM, Mauro Carvalho Chehab> > Have you looked at the code for how the Conexant guys got the xc5000> firmware load to work (which uses 64 bytes at a time). I suspect what> *really* needs to happen is that needs to be made generic so that the> stop bit is properly set (which would allow a single i2c transaction> to span across multiple USB control messages).> > Note that the xc5000 hack is actually two changes merged together -> one uses a GPIO mode in certain cases to handle clock stretching> properly (which probably has to stay there for now), and the other> allows for larger i2c transactions. I am referring to the latter> change.> > If we fix the cx231xx i2c master, then we can go back to the original> 18271 config, which avoids the risk of regression for other devices.

The original code is broken, as it doesn't properly honour a max size of 8.Even if we do some optimization at cx231xx, we still need to fix the tda18271code, as it is trying to use more than 8 bytes on some writes.

Also, as you noticed, the way cx231xx sends large firmwares to xc5000 is a hack:it requires to identify that the I2C device is a xc5000 and do an specialtreatment for it.

We may actually move all those small_i2c logic to the bridge drivers, addingthose hacks inside the I2C adapter part, but this means that they'll need to have some complex-logic that are dependent on what device is connected to it,damaging the benefits that the I2C bus abstraction brings.

Instead of polluting bridge drivers with I2C-device specific code, the properway seems to use parameters to adjust the maximum size, eventually flaggingthe broken messages in a way that the I2C adapter won't sent a stop transactionin the middle of a larger initialization like this one.