Re: [GIT PULL for 2.6.37-rc1] V4L/DVB updates

[Mauro Carvalho Chehab]

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 tda18271
code, 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 special
treatment for it.

We may actually move all those small_i2c logic to the bridge drivers, adding
those 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 proper
way seems to use parameters to adjust the maximum size, eventually flagging
the broken messages in a way that the I2C adapter won't sent a stop transaction
in the middle of a larger initialization like this one.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/