* [U-Boot] I2C: OMAP: spurious i2c probe addresses
2011-05-26 7:03 ` Michael Jones
@ 2011-05-26 7:14 ` Heiko Schocher
2011-05-26 7:25 ` Andre Schwarz
2011-05-26 9:23 ` Nick Thompson
2 siblings, 0 replies; 7+ messages in thread
From: Heiko Schocher @ 2011-05-26 7:14 UTC (permalink / raw)
To: u-boot
Hello Michael,
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.
Ah, good point. Thanks! (I just looked at this commit, and couldn;t
find, why it does such a mess) ... waiting for a patch, which adds
2-byte subaddress support ;-)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] I2C: OMAP: spurious i2c probe addresses
2011-05-26 7:03 ` Michael Jones
2011-05-26 7:14 ` Heiko Schocher
@ 2011-05-26 7:25 ` Andre Schwarz
2011-05-26 9:23 ` Nick Thompson
2 siblings, 0 replies; 7+ messages in thread
From: Andre Schwarz @ 2011-05-26 7:25 UTC (permalink / raw)
To: u-boot
Michael,
> 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.
Using CONFIG_SYS_I2C_NOPROBES for the extended adressing devices should
do the trick.
Regards,
Andr?
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] I2C: OMAP: spurious i2c probe addresses
2011-05-26 7:03 ` Michael Jones
2011-05-26 7:14 ` Heiko Schocher
2011-05-26 7:25 ` Andre Schwarz
@ 2011-05-26 9:23 ` Nick Thompson
2011-05-26 11:38 ` Michael Jones
2 siblings, 1 reply; 7+ messages in thread
From: Nick Thompson @ 2011-05-26 9:23 UTC (permalink / raw)
To: u-boot
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 Michael,
What do you mean by sub-address? The address within the device or an
extended chip address?
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.
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.
Can you tell us what device this is? Even better a link to the data
sheet.
Does your bus have only one master (the OMAP)? There could be an issue
if bus arbitration failures occur.
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.
Nick.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] I2C: OMAP: spurious i2c probe addresses
2011-05-26 9:23 ` Nick Thompson
@ 2011-05-26 11:38 ` Michael Jones
2011-05-26 12:35 ` Nick Thompson
0 siblings, 1 reply; 7+ messages in thread
From: Michael Jones @ 2011-05-26 11:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] I2C: OMAP: spurious i2c probe addresses
2011-05-26 11:38 ` Michael Jones
@ 2011-05-26 12:35 ` Nick Thompson
0 siblings, 0 replies; 7+ messages in thread
From: Nick Thompson @ 2011-05-26 12:35 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 7+ messages in thread