From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lubomir Popov Date: Thu, 07 Nov 2013 10:15:59 +0200 Subject: [U-Boot] A question about unconfigured pads check in omap24xx_i2c In-Reply-To: <527B4998.7010204@denx.de> References: <527A322B.6070703@compulab.co.il> <527A41E6.3070904@mm-sol.com> <527B21C7.6070203@denx.de> <527B47EA.2080905@mm-sol.com> <527B4998.7010204@denx.de> Message-ID: <527B4C3F.50709@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 Heiko, On 07-Nov-13 10:04, Heiko Schocher wrote: > Hello Lubomir, > > Am 07.11.2013 08:57, schrieb Lubomir Popov: >> Hi Heiko, >> >> On 07-Nov-13 7:14, Heiko Schocher wrote: >>> Hello Lubomir, >>> >>> Am 06.11.2013 14:19, schrieb Lubomir Popov: >>>> 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. >>> >>> Thanks for this explanation! Maybe we can document this somewhere in >>> the code? >>> >>> bye, >>> Heiko >> You are right, it would be good to document it. Unfortunately I have not >> been on the U-Boot wave for some months now due to very heavy engagement >> with other stuff; have even unsubscribed from the list. I think however >> that in order to give definite statements and improve the driver, a new >> round of experiments has to be made to cover the two major types of >> design >> flaws (software and/or hardware): incorrect pad configuration, and >> missing >> pullups (internal or external). I wrote this driver more that 6 >> months ago >> with the goal to have something working properly (the then existing >> one was, >> mildly put, not good), and this detection is just a bonus side effect. >> >> In summary, the professional approach would require some more effort, >> which >> I'm not sure when I could afford. Otherwise, if just an explanation >> for the >> current algo is to be given, no problem - I can just add some comments. > > I vote for the professional approach ;-) But if you have no time, and > can just send a comment for the current state (maybe with a short > summary, > what should be done) I am fine with this too! OK, shall see to the easy way first - just add some comments, sometime next week. But, no promises ;-) Lubo