From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lubomir Popov Date: Mon, 11 Nov 2013 17:51:24 +0200 Subject: [U-Boot] A question about unconfigured pads check in omap24xx_i2c In-Reply-To: <5280BC42.5090502@compulab.co.il> References: <527A322B.6070703@compulab.co.il> <527A41E6.3070904@mm-sol.com> <527D1F1F.3090706@compulab.co.il> <3e94227ed67324f988d10e3e4bd921be.squirrel@www.mm-sol.com> <5280BC42.5090502@compulab.co.il> Message-ID: <5280FCFC.8010104@mm-sol.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Nikita, On 11-Nov-13 13:15, Nikita Kiryanov wrote: > On 11/08/2013 11:26 PM, Lubomir Popov wrote: >> Hi Nikita, >> >>> On 11/06/2013 03:19 PM, Lubomir Popov wrote: >>>> On 06-Nov-13 14:12, Nikita Kiryanov wrote: >>>>> In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to >>>>> detect unconfigured pads for the i2c bus in use. These checks are >>>>> all in the form of >>>>> >>>>> if (status == I2C_STAT_XRDY) { >>>>> printf("unconfigured pads\n"); >>>>> return -1; >>>>> } >>>>> >>>>> This check seems peculiar to me since the meaning of I2C_STAT_XRDY is >>>>> that new data is requested for transmission. Why is that >>>>> indication that >>>>> the bus is not padconf'd for I2C? >>>> Hi Nikita, >>>> >>>> This has been empirically confirmed on OMAP4 and OMAP5. When the pads >>>> are not >>>> configured, the I2C controller is actually disconnected from the bus. >>>> The clock >>>> input for its state machine has to come from the bus however due to >>>> stretching >>>> etc., although it is internally generated. So actually nothing changes >>>> within >>>> the controller after a transaction attempt is made, and it keeps its >>>> initial >>>> state with XRDY set only (ready to accept transmit data). I use >>>> this as an >>>> indicator. Not perfect, but works in most cases. >>>> >>>> Regards, >>>> Lubo >>>> >>>> >>> >>> Thanks for the quick reply. >>> The reason I stumbled across this is that this check hasn't been >>> working >>> well on our OMAP3 based devices. Some I2C transactions work fine, but >>> some of them fail this check in the address phase, especially if the >>> I2C >>> transactions happen in quick successions. >> You mean that you occasionally get this error on an otherwise properly >> configured and working bus, right? > > Yes. > >> Does this happen with particular >> slave devices only, or randomly? And is it happening in the SPL, or in >> regular U-Boot? > > It happens in U-Boot when communicating with the PMIC (TPS65930), > but like I said, it worked in the driver's previous version, on the > same module. > >> >> >>> We did not have any I2C issues >>> with the previous driver, and while this behavior is symptomatic of >>> timing issues playing around with the delays didn't help. >> Which delays did you modify? Did you try to increase >> I2C_WAIT/I2C_TIMEOUT? > > I tried to increase both I2C_WAIT and I2C_TIMEOUT, and place my own > delays as well. > >> >>> I was wondering if you might have some insights as to what may cause >>> the >>> controller to behave this way other than unconfigured pads? >> Unfortunately I don't have any hands-on experience with OMAP3 (apart >> from >> some very quick testing on a AM3359 derivative), and cannot guarantee >> that >> the I2C controller IP on OMAP3 is absolutely the same as on OMAP4/5 >> (most >> probably it isn't; shall check this on Monday). Anyway, if everything >> else >> is OK (muxmode/pad config, pull-ups, power, etc.), the only reasonable >> explanation would be that there is not enough time for the controller to >> update its status register under certain conditions, and these would be >> either a slower clock rate (that makes byte transmission time come close >> to the timeout), or clock stretching by some slaves; btw, the latter >> seems probable, judging from your words that this happens in the address >> phase, when some devices could take longer to prepare for action, and >> they >> do this by stretching the clock. That is why I'm asking if you tried to >> increase I2C_TIMEOUT. Did you do any measurements on the bus to see >> if all >> is OK and the clock rate is right, and if it gets stretched by some >> slaves? > > I believe I found the cause of the problem. In the new version of the > driver the following line was added to the exit sequence of i2c_write: > > writew(0, &i2c_base->cnt); > > Removing this line solved the problem (module has been doing I2C > transactions for the last 16 hours or so without failing), and I > believe the reason has to do with Advisory 1.2 in the DM3730 errata: > > Advisory 1.2 I2C Module Does Not Allow 0-Byte Data Requests > Revision(s) Affected 1.2, 1.1 and 1.0 > Details When configured as the master, the I2C module > does not allow 0-byte data transfers. > Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will > cause undefined behavior. > Workaround(s) There is no workaround for this issue. Do not > use 0-byte data requests. > > While the mentioned write is done at the end of i2c_write, perhaps the > driver's MO still triggers this issue. It certainly is plausible > that this line was missing from the old i2c_write exit sequence on > purpose, and not by accident (i2c_read, i2c_probe, and i2c_init all > had it in the old driver). Many thanks for catching this. Feel free to post a patch. Lubo