* Tony Lindgren <tony@xxxxxxxxxxx> [180112 01:20]: > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [180112 00:45]: > > On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [180112 00:18]: > > > > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > > > > > > Hi all, > > > > > > > > > > I'm seeing a considerable idle power consumption regression in > > > > > Linux next, with power consumption for my idle test system going > > > > > to 17.5mW compared to the usual 8mW on my test device. > > > > > > > > > > Git bisect points to merge commit e130bc1d00a4 ("Merge branch > > > > > 'akpm-current/current'") being the first bad commit. > > > > > > > > > > I have also verified that commit 70286688e5ad ("ipc/mqueue.c: > > > > > have RT tasks queue in by priority in wq_add()") is good, and > > > > > commit e2d7fe89e8ae ("Merge remote-tracking branch > > > > > 'init_task/init_task'") is good. > > > > > > > > Do you mean that everything up to and including 70286688e5ad > > > > ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is > > > > good? > > > > > > Yes I'm not seeing the regression in your branch at commit > > > 70286688e5ad. I'm seeing it only with the merge commit > > > e130bc1d00a4. > > > > > > > That's weird. All I'm seeing between 70286688e5ad and end-of-mm is: ... > Well there are some changes in merge commit e130bc1d00a4.. So it seems that the Makefile changes in Linux next merge commit e130bc1d00a4 cause changes with CONFIG_CC_STACKPROTECTOR_AUTO=y. With next-20180112 out now, that's now commit 3823b7cc7a5e ("Merge branch 'akpm-current/current'"). Not sure if that's a bug or not.. Anyways, I reran my "bisect boot wait-idle measure" test with CONFIG_CC_STACKPROTECTOR_STRONG=y selected to rule out the AUTO option, and bisect now points to a different commit that makes more sense for my test case. It's commit 3bb0f7c31b1a ("ASoC: don't use snd_soc_write/read on twl4030"). And that is for the PMIC on my test system, so adding Kuninori and Mark to the thread :) Kuninori, it seems that commit 3bb0f7c31b1a causes higher power consumption on an idle system on omap3 using twl4030. Reverting 3bb0f7c31b1a makes things behave again. My guess is that twl4030_read does not do the same as snd_soc_read in the driver? Regards, Tony -- 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