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

[Nick Thompson <nick.thompson@ge.com>]

On 26/05/11 12:38, Michael Jones wrote:
> 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.

That appears to true. The Davinci driver supports two byte addresses. You
might be able to use that as a template for your changes.

> 
>>
>> 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.

Yes.

I've made a similar change to Davinci's probe and it works with a 25x256
(Spansion) device (and more stubborn Analog Devices DACs and ADCs, as well
as temperature and current sensors). The probe always returns the same
results, much like our OMAP boards.

> 
>>
>> 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.

Okay.

> 
>>
>> 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.

Hmm, I'm a bit stumped then. I'm still playing with I2C on Davinci,
so more ideas may come out of that.

The bus pull-ups on our boards are 2k-ohm to 3v3 rail, if it helps.

> 
>>
>> 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.

Okay, let me know how you get on.

> 
> -Michael

Nick.