[U-Boot] [PATCH v3 04/23] i2c: Add TPS6586X driver

[Simon Glass]

+Jimmy, who wrote the original pmu code

Hi Stephen,

On Mon, Apr 9, 2012 at 2:57 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 04/09/2012 03:25 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Apr 9, 2012 at 2:01 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 04/02/2012 05:18 PM, Simon Glass wrote:
>>>> This power management chip supports battery charging and a large number
>>>> of power supplies. This initial driver only provides the ability to adjust
>>>> the two synchronous buck converters SM0 and SM1 in a stepwise manner.
>>>>
>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>
>>>> +#define MAX_I2C_RETRY        3
>>>> +int tps6586x_read(int reg)
>>> ...
>>>> +     for (i = 0; i < MAX_I2C_RETRY; ++i) {
>>>> +             if (!i2c_read(I2C_ADDRESS, reg, 1, &data, 1)) {
>>>> +                     retval = (int)data;
>>>> +                     goto exit;
>>>> +             }
>>>> +
>>>> +             /* i2c access failed, retry */
>>>> +             udelay(100);
>>>> +     }
>>>
>>> Why do we need this retry logic; the kernel driver doesn't appear to
>>> have this.
>>
>> We apparently have found the device to be flaky on i2c sometimes,
>> which is why this is here.
>
> Is it the device itself, or bad board layout/...? Do we need something
> similar in the kernel?

I am not sure - Jimmy do you know?

>
> In general though, if we're having problems communicating with the PMIC,
> we're pretty screwed; how do we know whether failed transactions simply
> fail (e.g. no ACK), or send bogus data to the PMIC (e.g. set some random
> register so that something gets programmed to be over-voltage)? A better
> solution might be a full system reset when you fail to communicate with
> the PMIC.

I believe the problem is that there is no ACK - it would be pretty bad
if it ACKed but didn't work :-)

Regards,
Simon