[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL for 2.6.37-rc1] V4L/DVB updates
    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.


     \ /
      Last update: 2010-10-27 18:49    [W:0.022 / U:16.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site