[U-Boot] I2C: OMAP: spurious i2c probe addresses

[Michael Jones <michael.jones@matrix-vision.de>]

On 05/26/2011 11:23 AM, Nick Thompson wrote:
> On 26/05/11 08:03, Michael Jones wrote:
>> On 05/25/2011 05:38 PM, Michael Jones wrote:
>>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
>>> bus.  I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
>>> devices when probing an i2c bus".  It detects more devices indeed, such
>>> as some that don't even exist. Even better than that, it detects
>>> different devices every time.  It looks like just false positives, the
>>> existent devices seem to always be found among the ghost devices.
>>>
>>> Here's the behavior I see:
>>> --------------------------
>>> # i2c probe
>>> Valid chip addresses: 05 18 30 49 50 51 5E 7A
>>> # i2c probe
>>> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C
>>> # i2c probe
>>> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F
>>> # i2c probe
>>> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D
>>> # i2c probe
>>> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79
>>> # i2c probe
>>> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C
>>>
>>>
>>> Here's what it looks like after reverting the commit:
>>> ------------------------------------------
>>> # i2c probe
>>> Valid chip addresses: 18 30 50 51
>>> # i2c probe
>>> Valid chip addresses: 18 30 50 51
>>> # i2c probe
>>> Valid chip addresses: 18 30 50 51
>>> # i2c probe
>>> Valid chip addresses: 18 30 50 51
>>>
>>>
>>> -Michael
>>
>> Sorry- relevant point here: I have a device with a 2-byte subaddress,
>> which I suspect is the culprit here.  As Nick mentioned in his commit
>> message, such devices are unsupported by the current OMAP i2c driver.
>> I'm in the process of adding support for 2-byte subaddresses to the
>> driver.  In light of the above, I now realize that such changes will
>> probably have to involve i2c_probe() as well.
>>
>> -Michael
> 

Hi Nick,

> Hi Michael,
> 
> What do you mean by sub-address? The address within the device or an
> extended chip address?

I mean the address within the device.

> 
> The change I made aborts the write after sending the 7 bit chip
> address and 1 write bit, so a device's internal address shouldn't be
> relevant.

Mmm, OK.  I only jumped to that conclusion because your comment in the
commit message mentions that the driver only supports devices with
single-byte subaddresses.

> 
> Extended chip addressing devices would not be supported as it stands.
> I can imagine NACK may not be occur for a device waiting for more
> chip address bits, though I would have thought it wouldn't drive the bus
> low until the full address is received.

Curious.  It sounds like you would've expected it to work with my device.

> 
> Can you tell us what device this is? Even better a link to the data
> sheet.

It's a 128 Kbit EEPROM.
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdf 

> 
> Does your bus have only one master (the OMAP)? There could be an issue
> if bus arbitration failures occur.

OMAP is the only master.

> 
> I guess your bus pull-ups are strong enough to assert the NAK...?
> If not, you probably you would have seen other issues before now.

Right- I assume this is not the problem because I haven't had other
issues before now.

> 
> Nick.

I am going to focus on getting proper reads and writes working
with my device before looking into this myself.  If you have
suggestions in the meantime, I'm all ears.  Otherwise I'll be
in touch when I get around to looking at probe again.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner