From: "H. Nikolaus Schaller" <hns@goldelico.com> To: Viresh Kumar <viresh.kumar@linaro.org> Cc: Andreas Kemnade <andreas@kemnade.info>, vireshk@kernel.org, nm@ti.com, ulf.hansson@linaro.org, stephan@gerhold.net, khilman@kernel.org, sboyd@kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Discussions about the Letux Kernel <letux-kernel@openphoenux.org> Subject: Re: [Letux-kernel] [REGRESSION] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER Date: Fri, 6 Nov 2020 10:27:26 +0100 [thread overview] Message-ID: <1600E1F6-2819-4858-9843-B29264F4C2E6@goldelico.com> (raw) In-Reply-To: <20201106085810.ubo3cikbg33x76lt@vireshk-i7> Hi, > Am 06.11.2020 um 09:58 schrieb Viresh Kumar <viresh.kumar@linaro.org>: > > On 06-11-20, 09:44, H. Nikolaus Schaller wrote: >> >>> Am 06.11.2020 um 05:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>: >>> >>> On 06-11-20, 00:10, Andreas Kemnade wrote: >>>> Hi, >>>> >>>> On the GTA04 (DM3730, devicetree omap3-gta04*) I get my console flooded >>>> up with the following: >>>> [ 24.517211] cpu cpu0: multiple regulators are not supported >>>> [ 24.523040] cpufreq: __target_index: Failed to change cpu frequency: -22 >>>> [ 24.537231] ------------[ cut here ]------------ >>>> [ 24.542083] WARNING: CPU: 0 PID: 5 at drivers/opp/core.c:678 dev_pm_opp_set_rate+0x23c/0x494 >>>> [ 24.551086] Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs phy_twl4030_usb omap2430 musb_hdrc overlay >>>> [ 24.563842] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G W 5.9.0-rc1-00008-g629238068eb9 #14 >>>> [ 24.573852] Hardware name: Generic OMAP36xx (Flattened Device Tree) >>>> [ 24.580413] Workqueue: events dbs_work_handler >>>> [ 24.585083] [<c010e6b4>] (unwind_backtrace) from [<c010a194>] (show_stack+0x10/0x14) >>>> [ 24.593200] [<c010a194>] (show_stack) from [<c0464ad0>] (dump_stack+0x8c/0xac) >>>> [ 24.600769] [<c0464ad0>] (dump_stack) from [<c01276a8>] (__warn+0xcc/0xe4) >>>> [ 24.608001] [<c01276a8>] (__warn) from [<c0127a3c>] (warn_slowpath_fmt+0x74/0xa0) >>>> [ 24.615844] [<c0127a3c>] (warn_slowpath_fmt) from [<c06364ac>] (dev_pm_opp_set_rate+0x23c/0x494) >>>> [ 24.625061] [<c06364ac>] (dev_pm_opp_set_rate) from [<c063ec08>] (set_target+0x2c/0x4c) >>>> [ 24.633453] [<c063ec08>] (set_target) from [<c063a950>] (__cpufreq_driver_target+0x190/0x22c) >>>> [ 24.642395] [<c063a950>] (__cpufreq_driver_target) from [<c063d4e0>] (od_dbs_update+0xcc/0x158) >>>> [ 24.651489] [<c063d4e0>] (od_dbs_update) from [<c063e090>] (dbs_work_handler+0x2c/0x54) >>>> [ 24.659881] [<c063e090>] (dbs_work_handler) from [<c013f71c>] (process_one_work+0x210/0x358) >>>> [ 24.668731] [<c013f71c>] (process_one_work) from [<c0140014>] (worker_thread+0x22c/0x2d0) >>>> [ 24.677307] [<c0140014>] (worker_thread) from [<c0144eac>] (kthread+0x140/0x14c) >>>> [ 24.685058] [<c0144eac>] (kthread) from [<c0100148>] (ret_from_fork+0x14/0x2c) >>>> [ 24.692626] Exception stack(0xde4b7fb0 to 0xde4b7ff8) >>>> [ 24.697906] 7fa0: 00000000 00000000 00000000 00000000 >>>> [ 24.706481] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>> [ 24.715057] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >>>> [ 24.722198] ---[ end trace 038b3f231fae6f81 ]--- >>>> >>>> endlessly after the $subject commit. Any hints? >>> >>> The fix for this has been in linux-next for a couple of days and it >>> made it to linus/master yesterday. >>> >>> 47efcbcb340ic opp: Fix early exit from dev_pm_opp_register_set_opp_helper() > > I think I may have accidentally pasted the wrong commit here. This is > the one which must have fixed it for you. > > commit 1f6620f87006 ("opp: Don't always remove static OPPs in _of_add_opp_table_v1()") Well, I did a cross-check and git revert 47efcbcb340 made the problem come back. Maybe both patches are good and the first one hides the missing second one. What I haven't checked is if all opps are available now. I just looked for the omap to boot. > > >> Seems to fix our problems on gta04 (OMAP3). >> Otherwise we would have found that v5.10-rc3 magically solves it :) > > I assume you just ran linus's/master, otherwise the patch I shared > earlier won't have fixed the issue :) Yes, we just test with v5.10-rc2 and wait for -rc3 to come in some days. > >> Interestingly it did not affect OMAP5. > > Based on the DT I saw for omap5, it does use OPPv1 and so it shouldn't > have worked as well. It may be worth checking why it didn't get > affected earlier. > > You can see the populated OPPs for a platform with this: > > ls /sys/kernel/debug/opp/cpu*/* > > You shall see some difference with and without this patch. Or it may > be the case that you are adding dynamic OPPs with dev_pm_opp_add() and > so even after removing the static ones, it worked (though I wasn't > able to find that in the code). Ah, now as you tell this I remember that the last test on omap5 did not have any cpufreq info output. Although it did boot to login:. So I did not see a common reason in these quite different symptoms. I am sure that with -rc3 omap3 & omap5 will be ok again and I'll take a special look at it when testing other things. BR and thanks, Nikolaus
WARNING: multiple messages have this Message-ID (diff)
From: "H. Nikolaus Schaller" <hns@goldelico.com> To: Viresh Kumar <viresh.kumar@linaro.org> Cc: nm@ti.com, ulf.hansson@linaro.org, Discussions about the Letux Kernel <letux-kernel@openphoenux.org>, stephan@gerhold.net, khilman@kernel.org, sboyd@kernel.org, vireshk@kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, Andreas Kemnade <andreas@kemnade.info>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [Letux-kernel] [REGRESSION] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER Date: Fri, 6 Nov 2020 10:27:26 +0100 [thread overview] Message-ID: <1600E1F6-2819-4858-9843-B29264F4C2E6@goldelico.com> (raw) In-Reply-To: <20201106085810.ubo3cikbg33x76lt@vireshk-i7> Hi, > Am 06.11.2020 um 09:58 schrieb Viresh Kumar <viresh.kumar@linaro.org>: > > On 06-11-20, 09:44, H. Nikolaus Schaller wrote: >> >>> Am 06.11.2020 um 05:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>: >>> >>> On 06-11-20, 00:10, Andreas Kemnade wrote: >>>> Hi, >>>> >>>> On the GTA04 (DM3730, devicetree omap3-gta04*) I get my console flooded >>>> up with the following: >>>> [ 24.517211] cpu cpu0: multiple regulators are not supported >>>> [ 24.523040] cpufreq: __target_index: Failed to change cpu frequency: -22 >>>> [ 24.537231] ------------[ cut here ]------------ >>>> [ 24.542083] WARNING: CPU: 0 PID: 5 at drivers/opp/core.c:678 dev_pm_opp_set_rate+0x23c/0x494 >>>> [ 24.551086] Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs phy_twl4030_usb omap2430 musb_hdrc overlay >>>> [ 24.563842] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G W 5.9.0-rc1-00008-g629238068eb9 #14 >>>> [ 24.573852] Hardware name: Generic OMAP36xx (Flattened Device Tree) >>>> [ 24.580413] Workqueue: events dbs_work_handler >>>> [ 24.585083] [<c010e6b4>] (unwind_backtrace) from [<c010a194>] (show_stack+0x10/0x14) >>>> [ 24.593200] [<c010a194>] (show_stack) from [<c0464ad0>] (dump_stack+0x8c/0xac) >>>> [ 24.600769] [<c0464ad0>] (dump_stack) from [<c01276a8>] (__warn+0xcc/0xe4) >>>> [ 24.608001] [<c01276a8>] (__warn) from [<c0127a3c>] (warn_slowpath_fmt+0x74/0xa0) >>>> [ 24.615844] [<c0127a3c>] (warn_slowpath_fmt) from [<c06364ac>] (dev_pm_opp_set_rate+0x23c/0x494) >>>> [ 24.625061] [<c06364ac>] (dev_pm_opp_set_rate) from [<c063ec08>] (set_target+0x2c/0x4c) >>>> [ 24.633453] [<c063ec08>] (set_target) from [<c063a950>] (__cpufreq_driver_target+0x190/0x22c) >>>> [ 24.642395] [<c063a950>] (__cpufreq_driver_target) from [<c063d4e0>] (od_dbs_update+0xcc/0x158) >>>> [ 24.651489] [<c063d4e0>] (od_dbs_update) from [<c063e090>] (dbs_work_handler+0x2c/0x54) >>>> [ 24.659881] [<c063e090>] (dbs_work_handler) from [<c013f71c>] (process_one_work+0x210/0x358) >>>> [ 24.668731] [<c013f71c>] (process_one_work) from [<c0140014>] (worker_thread+0x22c/0x2d0) >>>> [ 24.677307] [<c0140014>] (worker_thread) from [<c0144eac>] (kthread+0x140/0x14c) >>>> [ 24.685058] [<c0144eac>] (kthread) from [<c0100148>] (ret_from_fork+0x14/0x2c) >>>> [ 24.692626] Exception stack(0xde4b7fb0 to 0xde4b7ff8) >>>> [ 24.697906] 7fa0: 00000000 00000000 00000000 00000000 >>>> [ 24.706481] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >>>> [ 24.715057] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 >>>> [ 24.722198] ---[ end trace 038b3f231fae6f81 ]--- >>>> >>>> endlessly after the $subject commit. Any hints? >>> >>> The fix for this has been in linux-next for a couple of days and it >>> made it to linus/master yesterday. >>> >>> 47efcbcb340ic opp: Fix early exit from dev_pm_opp_register_set_opp_helper() > > I think I may have accidentally pasted the wrong commit here. This is > the one which must have fixed it for you. > > commit 1f6620f87006 ("opp: Don't always remove static OPPs in _of_add_opp_table_v1()") Well, I did a cross-check and git revert 47efcbcb340 made the problem come back. Maybe both patches are good and the first one hides the missing second one. What I haven't checked is if all opps are available now. I just looked for the omap to boot. > > >> Seems to fix our problems on gta04 (OMAP3). >> Otherwise we would have found that v5.10-rc3 magically solves it :) > > I assume you just ran linus's/master, otherwise the patch I shared > earlier won't have fixed the issue :) Yes, we just test with v5.10-rc2 and wait for -rc3 to come in some days. > >> Interestingly it did not affect OMAP5. > > Based on the DT I saw for omap5, it does use OPPv1 and so it shouldn't > have worked as well. It may be worth checking why it didn't get > affected earlier. > > You can see the populated OPPs for a platform with this: > > ls /sys/kernel/debug/opp/cpu*/* > > You shall see some difference with and without this patch. Or it may > be the case that you are adding dynamic OPPs with dev_pm_opp_add() and > so even after removing the static ones, it worked (though I wasn't > able to find that in the code). Ah, now as you tell this I remember that the last test on omap5 did not have any cpufreq info output. Although it did boot to login:. So I did not see a common reason in these quite different symptoms. I am sure that with -rc3 omap3 & omap5 will be ok again and I'll take a special look at it when testing other things. BR and thanks, Nikolaus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-06 9:27 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-05 23:10 [REGRESSION] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER Andreas Kemnade 2020-11-05 23:10 ` Andreas Kemnade 2020-11-06 4:14 ` Viresh Kumar 2020-11-06 4:14 ` Viresh Kumar 2020-11-06 8:44 ` [Letux-kernel] " H. Nikolaus Schaller 2020-11-06 8:44 ` H. Nikolaus Schaller 2020-11-06 8:58 ` Viresh Kumar 2020-11-06 8:58 ` Viresh Kumar 2020-11-06 9:27 ` H. Nikolaus Schaller [this message] 2020-11-06 9:27 ` H. Nikolaus Schaller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1600E1F6-2819-4858-9843-B29264F4C2E6@goldelico.com \ --to=hns@goldelico.com \ --cc=andreas@kemnade.info \ --cc=khilman@kernel.org \ --cc=letux-kernel@openphoenux.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=nm@ti.com \ --cc=rjw@rjwysocki.net \ --cc=sboyd@kernel.org \ --cc=stephan@gerhold.net \ --cc=ulf.hansson@linaro.org \ --cc=viresh.kumar@linaro.org \ --cc=vireshk@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.