Hi Kevin, Paul, On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > > [...] > >> I ran some intensive stress tests on the I2C and ... unfortunately I >> could not trigger the problem. It looks like the issue is caused by >> some transient situation where the CORE and/or I2C is in a low power >> state. > > FYI... I just ran across what appears to be the same bug on 3430/n900 > during suspend/resume testing. With CPUidle enabled, this happens every > time. > > Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. The cause of the problem is that the cpuidle influences the MPU and CORE states, depending on the constraints set and the latency figures for the power domains (in arch/arm/mach-omap2/cpuidle34xx.c). Since the latency numbers have not been updated to measured (i.e. realistic) values in too-low power state is used, hence the timeout problem. Note: that does not explain why the I2C timeout issue is present without CPU_IDLE enabled, since in that case PM QoS should not have any effect on the power domains states. So yes the PM QoS I2C patch shall be reverted as long as the PM QoS support for OMAP is not merged in. For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. What to do now with those patches? As said above [3] and [4] must be held until [1] and [2] are merged in. [1] http://marc.info/?l=linux-arm-kernel&m=134744383120921&w=2 [2] http://marc.info/?l=linux-omap&m=134795835604288&w=2 [3] http://marc.info/?l=linux-omap&m=134815730108344&w=2 [4] http://marc.info/?l=linux-omap&m=134795836904299&w=2 > Kevin Thanks for testing and reporting the issue. Jean > > > # rtcwake -m mem -s 1 > Date: Fri Dec 31 17:00:34 MST 1999 > hwclock: Sat Jan 1 00:00:34 2000 0.000000 seconds > [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready > wakeup from "mem" at Sat Jan 1 00:00:36 2000 > [ 38.841949] PM: Syncing filesystems ... done. > [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. > [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. > [ 38.916412] Suspending console(s) (use no_console_suspend to debug) > [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready > [ 39.944305] twl: i2c_read failed to transfer all messages > [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 > [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 > [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready > [ 40.975555] twl: i2c_read failed to transfer all messages > [ 40.975555] VMMC2_IO_18: failed to disable > [ 40.978698] PM: suspend of devices complete after 2049.163 msecs > [ 40.984222] PM: late suspend of devices complete after 5.493 msecs > [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs > [ 40.992187] Disabling non-boot CPUs ... > [ 40.992675] Successfully put all powerdomains to target state > [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs > [ 41.002014] PM: early resume of devices complete after 3.601 msecs > [ 41.179016] PM: resume of devices complete after 176.818 msecs > [ 41.277740] Restarting tasks ... done. > real 0m 3.50s > user 0m 0.00s > sys 0m 0.10s > Date: Fri Dec 31 17:00:40 MST 1999 > hwclock: Sat Jan 1 00:00:40 2000 0.000000 seconds -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
