[U-Boot] OMAP3 i2c issues on IGEP, u-boot 2013.10

[Lubomir Popov]

Hi Tom,

> On Wed, Nov 27, 2013 at 06:01:18PM +0200, Lubomir Popov wrote:
>> Hi Nikita,all,
>>
>> On 27-Nov-13 17:52, Nikita Kiryanov wrote:
>> >On 11/27/2013 05:28 PM, Thomas Petazzoni wrote:
>> >>Dear Nikita Kiryanov,
>> >>
>> >>On Wed, 27 Nov 2013 16:52:56 +0200, Nikita Kiryanov wrote:
>> >>
>> >>>>>Not sure to understand your question: my paragraph above mentions the
>> >>>>>IGEP board as being the platform on which I'm seeing this.
>> >>>>>So indeed, a
>> >>>>>OMAP3-based board is affected. But maybe I misunderstood
>> >>>>>your question.
>> >>>>>
>> >>>>
>> >>>>Oops, sorry, bad question :)
>> >>>>
>> >>>>Anybody knows if other OMAP3-based boards are affected for
>> >>>>this issue ?
>> >>>
>> >>>Our boards were also affected by this, and I managed to track the
>> >>>problem down to the zeroing of cnt register at the end of write, which
>> >>>was not present in the original version of the driver and appears to be
>> >>>triggering an issue that is mentioned in OMAP3 errata.
>> >>>
>> >>>I just posted a patch to address this problem. You can find it here:
>> >>>http://patchwork.ozlabs.org/patch/294593/
>> >>
>> >>Thanks for this patch. Unfortunately, I've applied it, and it doesn't
>> >>fix the problem for me. I still have those I2C issues (did 3 boots of
>> >>the IGEP boards, two of the boot failed with an endless stream of
>> >>"i2c_read (addr phase): pads on bus 0 probably not configured
>> >>(status=0x10)") message.
>> >>
>> >>Thanks,
>> >>
>> >>Thomas
>> >>
>> >
>> >The zeroing of the cnt register also happens in other places in the
>> >driver, and it is entirely possible that they should be removed for
>> >OMAP3s as well.
>> >
>> >In my patch I removed it only for i2c_write() because the original
>> >driver also zeroed the cnt register in I/O functions- except in
>> >i2c_write(), and I decided to follow the original driver's lead.
>> >
>> >What happens if you remove all the lines that zero the cnt register?
>> >
>> I think you are on the right track.
>>
>> Tom R, I guess I have been right back in spring when proposing this
>> to be a driver for OMAP4+ only.
>
> Well, the kernel driver handles omap1/2/3/4 so the problem is we aren't
> respecting (and tracking) the differences like we need to.  I do not
> want to if at all possible have an omap3 driver (since we dropped
> omap24xx and will be dropping the last omap1 shortly) and an omap4+
> driver that're pretty close, with just a few differences.

Generally you are right; the problem is that it is very hard, if ever
possible, to test some piece of software on all targets that it would
be run on, and account for every fancy silicon errata.

Regarding this particular issue, the clearing of the byte count reg is
actually not needed at the end of every transaction. I guess it is some
jic legacy from older times, and I also kept it (even excessively, it
tuns out ;-) ) for some level of backward compatibility. Shall try to
find some time next week to test the driver on all OMAP-based boards
that I can gather with this operation removed from all functions and
see what happens.

Thanks again everyone for catching and fixing this.

Regards,
Lubo