From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Thu, 07 Nov 2013 09:04:40 +0100 Subject: [U-Boot] A question about unconfigured pads check in omap24xx_i2c In-Reply-To: <527B47EA.2080905@mm-sol.com> References: <527A322B.6070703@compulab.co.il> <527A41E6.3070904@mm-sol.com> <527B21C7.6070203@denx.de> <527B47EA.2080905@mm-sol.com> Message-ID: <527B4998.7010204@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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! Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany