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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
