Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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 here. Functional mode bits are unimplemented in the SYSTEST register on omap3530. "10:5 Reserved Write 0s for future compatibility. Read returns 0." That was the reason. My fault. Thank you for giving right directions. Thanks Kevin for running test, so I could debug the reason. Regards, Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* 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 without pull-ups? It could be. Boards that use external i2c pulls should have all the internal pulls disabled as the pulls get connected in parallel and the total resistance decreases. And then the i2c signals may not be up to the spec. Note that there are internal pulls in the i2c controller, and in the i2c padconf registers. > All beagles doesn't have internal pull-ups on i2c.1 since u-boot 2011.x. The pulls should be enabled based on the board and possibly based on the board revision. > Here is the bug in the u-boot related to beagle: > http://git.denx.de/?p=u-boot.git;a=commit;h=04e2a13336f0e507ef416bbede3be92b79c46594 > > Yes, I made fix, but keep that in mind. > > For example one of the boards (omap3-beagle): > http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ > http://status.armcloud.us/boot/omap3-beagle,legacy/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ > http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-multi_v7_defconfig/ > > has following warning message in the u-boot log: > > U-Boot 2014.07 (Aug 21 2014 - 11:03:05) > > > > OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > > OMAP3 Beagle board + LPDDR/NAND > > > > Beagle Rev C1/C2/C3 > > Timed out in wait_for_event: status=1000 > > Check if pads/pull-ups of bus 1 are properly configured > > Also beagle schematic has following log entry for A3: > 4. Added optional pullup resistors on I2C2_SCL and I2C_SDA into the layout. > > Is the fault beagle is pre A3 revision? Seems to be C1/C2/C3 based on the above logs? > I can't tell anything about second one board (omap3-overo-tobi), because I > could not get it schematic. > > And how you have i2c.1 working without pull-ups I don't know. I checked on the LDP and it seems to have external pulls for i2c. I also tested n900 without your fix, and it's failing too. On n900 there are external pulls and all the internal pulls should be disabled. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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-ups on i2c.1 since u-boot 2011.x. Here is the bug in the u-boot related to beagle: http://git.denx.de/?p=u-boot.git;a=commit;h=04e2a13336f0e507ef416bbede3be92b79c46594 Yes, I made fix, but keep that in mind. For example one of the boards (omap3-beagle): http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ http://status.armcloud.us/boot/omap3-beagle,legacy/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-multi_v7_defconfig/ has following warning message in the u-boot log: > U-Boot 2014.07 (Aug 21 2014 - 11:03:05) > > OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > OMAP3 Beagle board + LPDDR/NAND > > Beagle Rev C1/C2/C3 > Timed out in wait_for_event: status=1000 > Check if pads/pull-ups of bus 1 are properly configured Also beagle schematic has following log entry for A3: 4. Added optional pullup resistors on I2C2_SCL and I2C_SDA into the layout. Is the fault beagle is pre A3 revision? I can't tell anything about second one board (omap3-overo-tobi), because I could not get it schematic. And how you have i2c.1 working without pull-ups I don't know. Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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=141686120720069&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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 message: "[3.046691] omap_i2c 4807.i2c: timeout waiting for bus ready" > So I doubt we just want to change the test for for a higher rev number > for OMAP_I2C_REV_ON_3430_3530. Yes, I'll do it within 15 minutes. And later, if it possible, I'd try to see what happens. Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* 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 > > > > [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 написал(а): > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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&omap Could someone advice with debugging on OMAP3530? I'd like to apply one one more commit to see events during boot and see actual signals on wire (during of timeout)? Otherwise, commit must dropped (or rewritten such way it is disabled by default). 24 нояб. 2014 г., в 22:13, Wolfram Sang написал(а): > OK, giving Alexander some time for a fix. If it can't be found, I'll > revert this patch. Thanks! What deadline? Alexander. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* 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, 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 controller timeout. More over, in some cases IP could > > > > interrupt another master's transfer and corrupt data on wire. > > > > > > > > The commit implement method allowing to prevent IP from entering into > > > > "controller timeout" state and from "data corruption" state. > > > > > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > > > > > Tested on Beagleboard XM C. > > > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > > > > > Signed-off-by: Alexander Kochetkov > > > > Tested-by: Felipe Balbi > > > > Reviewed-by: Felipe Balbi > > > > > > 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 > > > > btw, based on Kevin's boot test, only OMAP3530 is failing. > > OK, giving Alexander some time for a fix. If it can't be found, I'll > revert this patch. Thanks! I can confirm reverting it fixes things for me as well thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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 > > > 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 controller timeout. More over, in some cases IP could > > > interrupt another master's transfer and corrupt data on wire. > > > > > > The commit implement method allowing to prevent IP from entering into > > > "controller timeout" state and from "data corruption" state. > > > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > > > Tested on Beagleboard XM C. > > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > > > Signed-off-by: Alexander Kochetkov > > > Tested-by: Felipe Balbi > > > Reviewed-by: Felipe Balbi > > > > 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 > > btw, based on Kevin's boot test, only OMAP3530 is failing. OK, giving Alexander some time for a fix. If it can't be found, I'll revert this patch. Thanks! signature.asc Description: Digital signature
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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 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 controller timeout. More over, in some cases IP could > > interrupt another master's transfer and corrupt data on wire. > > > > The commit implement method allowing to prevent IP from entering into > > "controller timeout" state and from "data corruption" state. > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > Tested on Beagleboard XM C. > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > Signed-off-by: Alexander Kochetkov > > Tested-by: Felipe Balbi > > Reviewed-by: Felipe Balbi > > 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 btw, based on Kevin's boot test, only OMAP3530 is failing. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
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 started when BB=0 and bus is busy wouldn't be completed by IP > and results in controller timeout. More over, in some cases IP could > interrupt another master's transfer and corrupt data on wire. > > The commit implement method allowing to prevent IP from entering into > "controller timeout" state and from "data corruption" state. > > The one drawback is the need to wait for 10ms before the first transfer. > > Tested on Beagleboard XM C. > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > Signed-off-by: Alexander Kochetkov > Tested-by: Felipe Balbi > Reviewed-by: Felipe Balbi 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 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
