From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Mon, 2 Nov 2020 08:13:36 +0100 Subject: U-Boot i2c bus num 1 is broken on Nokia N900 In-Reply-To: References: <20200331224254.nzaotf5abj6w7n65@pali> <3c7dda52-10b3-e8c3-a382-785c80f124e7@wizzup.org> <20200402184231.jzhy36qfbi4drnli@pali> <20200425104217.pzp5zkhhft5a2he5@pali> <20200425115045.w45tb62cnwtq5umk@pali> <20200425121132.vnlurfxti6y433pq@pali> <20200425235459.bcoskmnux45x4iqs@pali> <948158e4-1c2c-9895-3c04-2a53198402f9@denx.de> <20201026214858.rowljynsc7vh2bjk@pali> <4fb91240-2a17-05ba-acdc-6c184ddfb250@gmail.com> <851f9300-ee31-ff3b-5944-a196bb9c0004@denx.de> Message-ID: <50c404e3-d2c5-4c7d-d942-8cf39780da74@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 Ivaylo, Am 31.10.2020 um 12:47 schrieb Ivaylo Dimitrov: > > > On 30.10.20 ?. 9:24 ?., Heiko Schocher wrote: >> Hello Ivaylo, >> >> Am 30.10.2020 um 08:00 schrieb Ivaylo Dimitrov: >>> Hi, >>> >>> On 29.10.20 ?. 11:32 ?., Heiko Schocher wrote: >>>> Hello Ivaylo, >>>> >>>> Am 29.10.2020 um 08:51 schrieb Ivaylo Dimitrov: >>>>> Hi, >>>>> >>>>> On 28.10.20 ?. 7:42 ?., Heiko Schocher wrote: >>>>>> Hello Pali, >>>>>> >>>>>> sorry for late response ... >>>>>> >>>>>> Am 26.10.2020 um 22:48 schrieb Pali Roh?r: [snip] >>>>>> Hannes may you can check if this is the case for you? >>>>>> >>>>>> why does nobody claimed that this message pops up in the last 5 years? >>>>>> >>> >>> I can confirm I see it on the 2 devices I tested here. >>> >>> What is worse, is that writing on bus 1 does not fail every time. I increased I2C_TIMEOUT to >>> 100000 (the value from the TRM) and it seems now after power-cycle, write succeeds almost every >>> time, however, after a reset command from u-boot, it usually fails. And with that increased >>> timeout,when it fails I see: >>> >>> Check if pads/pull-ups of bus are properly configured >>> i2c_read (addr phase): pads on bus probably not configured (status=0x10) >>> >>> message 5 times during the failing write. >>> >>> How we end up there, is a mystery to me. >> >> Yes... >> >> Ok, on page 2671 is described when this ARDY event is triggered, so >> if we wait for it, we must first check, if the prerequisite is met... >> >> Hmm.. the ARDY bit is also for interrupt mode described, see page 2778 >> Figure 18-31 ... so I think it is correct to check it ... but >> I do not see, why we should wait for it in a loop and print >> an error if bit does not come up >> >> But I have no time to dig into this ... >> > > Looks like slave device is misbehaving after a reset command. We changed the write to not reset the > slave, but instead to disable the LED engine and it seems there are no more timeouts/errors. > However, I guess it still makes sense some more complicated logic to be implemented there (like, if > we write only one byte, do not wait for ARDY), as I doubt lp5523 is the only device that misbehaves > on reset. Uff... Ok, I cannot do/help here, as lack of time (and may hardware). Hmm... may you try unblocking sequence instead? Do you have time to look here deeper? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de