Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [141124 11:41]:
> 
> 24 нояб. 2014 г., в 22:08, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> написал(а):
> 
> > This patch recently hit linux-next (as commit 903c3859f77f) and boot
> > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards
> > was bisected down to this commit.
> > 
> > Kevin
> > 
> > [1] http://status.armcloud.us/boot/?next-20141124&omap
> 
> 
> Could someone advice with debugging on OMAP3530?

Just try to boot it with your patch? :)
 
> I'd like to apply one one more commit to see events during boot and
> see actual signals on wire (during of timeout)?

If you post a patch, I can test boot with it. Looks like the failing
ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx.

But the test function should not loop forever in any case I take?

So I doubt we just want to change the test for for a higher rev number
for  OMAP_I2C_REV_ON_3430_3530.
 
> Otherwise, commit must dropped (or rewritten such way it is disabled by default).
> 
> 
> 24 нояб. 2014 г., в 22:13, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> написал(а):
> 
> > OK, giving Alexander some time for a fix. If it can't be found, I'll
> > revert this patch. Thanks!
> 
> What deadline?

I'd say by Tuesday as we have multiple automated test systems failing
as soon as people update their trees. And when they are failing, we
may miss other breakage happening in linux next.

Regards,

Tony