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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
