U-Boot i2c bus num 1 is broken on Nokia N900

[Heiko Schocher]

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