On Thu, May 5, 2011 at 9:15 AM, Mauro Carvalho Chehab
<mche...@redhat.com> wrote:
> So, the I2C adapter xfer code will end by being something like:
>
> switch(i2c_device) {
>        case FOO:
>                use_split_code_foo();
>                break;
>        case BAR:
>                use_splic_code_bar();
>                break;
>        ...
> }
>
>
> (if you want to see one example of the above, take a look at 
> drivers/media/video/cx231xx/cx231xx-i2c.c).

The cx231xx is actually an example of a poor implementation rather
than a deficiency in the chip.  The device does support sending
arbitrarily long sequences, but because of a lack of support for i2c
clock stretching they hacked in their own GPIO based bitbang
implementation which only gets used in certain cases.  If somebody
wanted to clean it up I believe it could be done much more cleanly.
That said, it hasn't happened because the code as-is "works" and in
reality I don't think there are any shipping products which use
cx231xx and xc5000 (they are all Conexant reference designs).

If somebody really wants to clean this up, they should have a board
profile field which indicates whether to create an i2c adapter which
uses the onboard i2c controller, or alternatively to setup an i2c
adapter which uses the real Linux i2c-bitbang implementation.  That
would make the implementation much easier to understand as well as
eliminating all the crap code which makes decisions based on the
destination i2c address.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to