Comment 6 for bug 645324

The underlying problem seems to be that TI extended the size of their revision register on the OMAP4430 version of the i2c peripheral unit, without maintaining the position of the revision LSB.

So, prior to OMAP4430, there was one 16-bit word at offset +0 defining the revision. On OMAP4430, there are two words and it seems the word with the same logical meaning as the one at +0 before, is now at +4.

This leads to a situation where the code can't probe just from the peripheral unit ID, because then it won't know beforehand which register(s) it is in.

In the existing driver, they go outside the peripheral unit's own ID and just in that one place to decide the register map, they use cpu_is_omap44xx() to decide if they will choose "old style" register map or "new style". The fact is, this DOES make the correct choice, because otherwise 3530 I2C would be broken since the OMAP4430 register layout is totally different.

That seems to lead to the conclusion that you can find 0x40 in the +0 register on OMAP3530 AND 0x40 in the +4 register on OMAP4430, the idea being that the extra 16 bits of revision numbering in the +0 register then lets you tell the difference.

The bug comes from an inconsistent test to use the new registers or not, by CPU type to select the register map and then by reported peripheral unit revision to decide whether to use them or not.

The attached patchset solves this and has been sent upstream.