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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131127/f96b1cfb/attachment.pgp>