[U-Boot] A question about unconfigured pads check in omap24xx_i2c

[Lubomir Popov <lpopov@mm-sol.com>]

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