+Jimmy, who wrote the original pmu code
Hi Stephen,
On Mon, Apr 9, 2012 at 2:57 PM, Stephen Warren <swar...@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 <swar...@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 <s...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
