On Thu, May 5, 2011 at 9:15 AM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
