I noticed that with my hikey board, on resume from suspend I'm getting the following WARNING: [ 54.334054] ------------[ cut here ]------------ [ 54.334077] WARNING: CPU: 0 PID: 2217 at drivers/clk/clk.c:594 clk_core_disable+0x20/0x78 [ 54.334080] [ 54.334090] CPU: 0 PID: 2217 Comm: system_server Not tainted 4.9.0-00046-gee9ec2c #2067 [ 54.334094] Hardware name: HiKey Development Board (DT) [ 54.334099] task: ffffffc074863200 task.stack: ffffffc061d1c000 [ 54.334105] PC is at clk_core_disable+0x20/0x78 [ 54.334111] LR is at clk_core_disable_lock+0x20/0x38 [ 54.334116] pc : [<ffffff80084ab728>] lr : [<ffffff80084ab848>] pstate: 800001c5 [ 54.334119] sp : ffffffc061d1faf0 [ 54.334128] x29: ffffffc061d1faf0 x28: 0000000000000000 [ 54.334136] x27: 0000000000000002 x26: ffffff8008d47000 [ 54.334143] x25: ffffff8008596000 x24: ffffff8008d15498 [ 54.334151] x23: ffffff8008db9000 x22: ffffffc075074870 [ 54.334158] x21: 0000000000000002 x20: ffffffc005f09500 [ 54.334165] x19: 0000000000000140 x18: 0000000000000001 [ 54.334172] x17: 0000000000000000 x16: 0000000000000000 [ 54.334180] x15: ffffffc005f43dc0 x14: 0000000000010000 [ 54.334187] x13: ffffff8008d906f8 x12: ffffff8008d15790 [ 54.334196] x11: ffffff8008d15000 x10: ffffff8008d8d000 [ 54.334204] x9 : 0000000000000000 x8 : ffffffc077f26218 [ 54.334212] x7 : 0000000000000000 x6 : 0000000000000000 [ 54.334220] x5 : ffffffc077f2b090 x4 : ffffffc061d1fa80 [ 54.334228] x3 : ffffff80084ab62c x2 : ffffff80084ab62c [ 54.334236] x1 : 0000000000000000 x0 : ffffffc005f09500 [ 54.334239] [ 54.334243] ---[ end trace 6474a624fb2fd658 ]--- [ 54.334248] Call trace: [ 54.334254] Exception stack(0xffffffc061d1f920 to 0xffffffc061d1fa50) [ 54.334262] f920: 0000000000000140 0000008000000000 ffffffc061d1faf0 ffffff80084ab728 [ 54.334269] f940: ffffff8008ccc090 ffffffc074863200 0000000000000000 6f6674616c703d4d [ 54.334276] f960: ffffffc061d1f970 ffffff8008087990 ffffffc061d1f9b0 ffffff8008450c6c [ 54.334283] f980: ffffff8008cc8000 ffffffc061d1fa90 ffffff8008ccc090 ffffffc074863200 [ 54.334290] f9a0: ffffff8008db6170 ffffffc061d1fa08 ffffffc061d1f9c0 ffffff8008087990 [ 54.334297] f9c0: ffffffc005f09500 0000000000000000 ffffff80084ab62c ffffff80084ab62c [ 54.334303] f9e0: ffffffc061d1fa80 ffffffc077f2b090 0000000000000000 0000000000000000 [ 54.334310] fa00: ffffffc077f26218 0000000000000000 ffffff8008d8d000 ffffff8008d15000 [ 54.334317] fa20: ffffff8008d15790 ffffff8008d906f8 0000000000010000 ffffffc005f43dc0 [ 54.334322] fa40: 0000000000000000 0000000000000000 [ 54.334328] [<ffffff80084ab728>] clk_core_disable+0x20/0x78 [ 54.334336] [<ffffff80084ad26c>] clk_disable+0x1c/0x30 [ 54.334349] [<ffffff80086d926c>] i2c_dw_plat_prepare_clk.isra.0+0x44/0x80 [ 54.334356] [<ffffff80086d930c>] dw_i2c_plat_suspend+0x24/0x38 [ 54.334367] [<ffffff800858ad54>] platform_pm_suspend+0x24/0x58 [ 54.334377] [<ffffff8008595558>] dpm_run_callback.isra.7+0x20/0x68 [ 54.334385] [<ffffff8008595fb4>] __device_suspend+0x10c/0x298 [ 54.334393] [<ffffff8008597154>] dpm_suspend+0x10c/0x228 [ 54.334401] [<ffffff8008597540>] dpm_suspend_start+0x68/0x78 [ 54.334412] [<ffffff80080fa058>] suspend_devices_and_enter+0xb8/0x458 [ 54.334419] [<ffffff80080fa5e4>] pm_suspend+0x1ec/0x248 [ 54.334426] [<ffffff80080f924c>] state_store+0x94/0xa8 [ 54.334434] [<ffffff80084366dc>] kobj_attr_store+0x14/0x28 [ 54.334444] [<ffffff8008249a28>] sysfs_kf_write+0x48/0x58 [ 54.334451] [<ffffff8008248d20>] kernfs_fop_write+0xb0/0x1d8 [ 54.334461] [<ffffff80081cd714>] __vfs_write+0x1c/0x100 [ 54.334469] [<ffffff80081cd9a0>] vfs_write+0xa0/0x1b8 [ 54.334477] [<ffffff80081cdb9c>] SyS_write+0x44/0xa0 [ 54.334485] [<ffffff8008082ef0>] el0_svc_naked+0x24/0x28 Doing some further debugging, it seems the problem is that the device is being runtime suspended, and then at suspend time, we're calling the same logic, calling i2c_dw_plat_prepare_clk, which causes the clk count warning. Removing the runtime pm ops: - SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL) +// SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL) seems to avoid the warning, but clearly isn't ideal. :) Should there be some logic keep track of the suspend state for the dw_i2c_dev device so we don't try to suspend (or resume) it twice? Or is there something else I'm missing to keep this from happening? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
