Hello, Tony!
24.11.2014 22:47, Tony Lindgren *:
> 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.
> So I doubt we just want to change the test for for a higher rev number
> for OMAP_I2C_REV_ON_3430_3530.
You 100% right her
* Alexander Kochetkov [141124 16:11]:
>
> 24 нояб. 2014 г., в 23:05, Alexander Kochetkov
> написал(а):
>
> > Something (u-boot, may be) leave the bus in the wrong state.
> > Really strange.
>
> Actually something wrong with i2c-pullups on i2c.1 bus on fault boards.
> May be these are boards w
24 нояб. 2014 г., в 23:05, Alexander Kochetkov написал(а):
> Something (u-boot, may be) leave the bus in the wrong state.
> Really strange.
Actually something wrong with i2c-pullups on i2c.1 bus on fault boards.
May be these are boards without pull-ups?
All beagles doesn't have internal pull-up
24 нояб. 2014 г., в 22:47, Tony Lindgren написал(а):
> 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.
Fix:
http://marc.info/?l=linux-i2c&m=141686120720
Guys, I really sorry for that :(
> Just try to boot it with your patch? :)
Yes, may be two-three times (max).
Something (u-boot, may be) leave the bus in the wrong state.
Really strange.
> But the test function should not loop forever in any case I take?
It doesn't loop forever. It finish with
* Alexander Kochetkov [141124 11:41]:
>
> 24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а):
>
> > 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
24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а):
> 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
* Wolfram Sang [141124 11:14]:
> On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote:
> > On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote:
> > > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
> > > wrote:
> > > > In a multimaster environment, after IP software reset,
On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
wrote:
> In a multimaster environment, after IP software reset, BB-bit value doesn't
> correspond to the current bus state. It may happen what BB-bit will be 0,
> while the bus is busy due to another I2C master activity.
>
> Any transfer starte
On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote:
> On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote:
> > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
> > wrote:
> > > In a multimaster environment, after IP software reset, BB-bit value
> > > doesn't
> > > correspo
On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote:
> On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
> wrote:
> > In a multimaster environment, after IP software reset, BB-bit value doesn't
> > correspond to the current bus state. It may happen what BB-bit will be 0,
> > while the
In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.
Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
and results in
12 matches
Mail list logo
