From: Samuel Holland <samuel@sholland.org> To: MyungJoo Ham <myungjoo.ham@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com>, Chanwoo Choi <cw00.choi@samsung.com>, Maxime Ripard <mripard@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Rob Herring <robh+dt@kernel.org> Cc: Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Samuel Holland <samuel@sholland.org> Subject: [PATCH 02/10] PM / devfreq: Do not require devices to have OPPs Date: Tue, 28 Sep 2021 23:42:46 -0500 [thread overview] Message-ID: <20210929044254.38301-3-samuel@sholland.org> (raw) In-Reply-To: <20210929044254.38301-1-samuel@sholland.org> Since commit ea572f816032 ("PM / devfreq: Change return type of devfreq_set_freq_table()"), all devfreq devices are required to have a valid freq_table. If freq_table is not provided by the driver, it will be filled in by set_freq_table() from the OPPs; if that fails, devfreq_add_device() will return an error. However, since commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device"), devfreq devices are _also_ required to have an OPP table, even if they provide freq_table. devfreq_add_device() requires dev_pm_opp_find_freq_ceil() and dev_pm_opp_find_freq_floor() to return successfully, specifically to initialize scaling_min/max_freq. Not all drivers need an OPP table. For example, a driver where all frequencies are determined dynamically could work by filling out only freq_table. But with the current code it must call dev_pm_opp_add() on every freq_table entry to probe successfully. The offending properties, scaling_min/max_freq, are only necessary if a device has OPPs; if no OPPs exist at all, OPPs cannot be dynamically enabled or disabled, so those values have no effect. Thus it is trivial to restore support for devices with freq_table only and not OPPs -- move those initializations behind the check for a valid OPP table. Since get_freq_range() uses scaling_max_freq in a min() expression, it must be initialized to the maximum possible value. scaling_min_freq is initialized as well for consistency. Fixes: ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") Signed-off-by: Samuel Holland <samuel@sholland.org> --- drivers/devfreq/devfreq.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 7a8b022ba456..426e31e6c448 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -835,24 +835,28 @@ struct devfreq *devfreq_add_device(struct device *dev, mutex_lock(&devfreq->lock); } - devfreq->scaling_min_freq = find_available_min_freq(devfreq); - if (!devfreq->scaling_min_freq) { - mutex_unlock(&devfreq->lock); - err = -EINVAL; - goto err_dev; - } - - devfreq->scaling_max_freq = find_available_max_freq(devfreq); - if (!devfreq->scaling_max_freq) { - mutex_unlock(&devfreq->lock); - err = -EINVAL; - goto err_dev; - } - - devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev); devfreq->opp_table = dev_pm_opp_get_opp_table(dev); - if (IS_ERR(devfreq->opp_table)) + if (IS_ERR(devfreq->opp_table)) { devfreq->opp_table = NULL; + devfreq->scaling_min_freq = 0; + devfreq->scaling_max_freq = ULONG_MAX; + } else { + devfreq->scaling_min_freq = find_available_min_freq(devfreq); + if (!devfreq->scaling_min_freq) { + mutex_unlock(&devfreq->lock); + err = -EINVAL; + goto err_dev; + } + + devfreq->scaling_max_freq = find_available_max_freq(devfreq); + if (!devfreq->scaling_max_freq) { + mutex_unlock(&devfreq->lock); + err = -EINVAL; + goto err_dev; + } + + devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev); + } atomic_set(&devfreq->suspend_count, 0); -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: Samuel Holland <samuel@sholland.org> To: MyungJoo Ham <myungjoo.ham@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com>, Chanwoo Choi <cw00.choi@samsung.com>, Maxime Ripard <mripard@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Rob Herring <robh+dt@kernel.org> Cc: Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Samuel Holland <samuel@sholland.org> Subject: [PATCH 02/10] PM / devfreq: Do not require devices to have OPPs Date: Tue, 28 Sep 2021 23:42:46 -0500 [thread overview] Message-ID: <20210929044254.38301-3-samuel@sholland.org> (raw) In-Reply-To: <20210929044254.38301-1-samuel@sholland.org> Since commit ea572f816032 ("PM / devfreq: Change return type of devfreq_set_freq_table()"), all devfreq devices are required to have a valid freq_table. If freq_table is not provided by the driver, it will be filled in by set_freq_table() from the OPPs; if that fails, devfreq_add_device() will return an error. However, since commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device"), devfreq devices are _also_ required to have an OPP table, even if they provide freq_table. devfreq_add_device() requires dev_pm_opp_find_freq_ceil() and dev_pm_opp_find_freq_floor() to return successfully, specifically to initialize scaling_min/max_freq. Not all drivers need an OPP table. For example, a driver where all frequencies are determined dynamically could work by filling out only freq_table. But with the current code it must call dev_pm_opp_add() on every freq_table entry to probe successfully. The offending properties, scaling_min/max_freq, are only necessary if a device has OPPs; if no OPPs exist at all, OPPs cannot be dynamically enabled or disabled, so those values have no effect. Thus it is trivial to restore support for devices with freq_table only and not OPPs -- move those initializations behind the check for a valid OPP table. Since get_freq_range() uses scaling_max_freq in a min() expression, it must be initialized to the maximum possible value. scaling_min_freq is initialized as well for consistency. Fixes: ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") Signed-off-by: Samuel Holland <samuel@sholland.org> --- drivers/devfreq/devfreq.c | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 7a8b022ba456..426e31e6c448 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -835,24 +835,28 @@ struct devfreq *devfreq_add_device(struct device *dev, mutex_lock(&devfreq->lock); } - devfreq->scaling_min_freq = find_available_min_freq(devfreq); - if (!devfreq->scaling_min_freq) { - mutex_unlock(&devfreq->lock); - err = -EINVAL; - goto err_dev; - } - - devfreq->scaling_max_freq = find_available_max_freq(devfreq); - if (!devfreq->scaling_max_freq) { - mutex_unlock(&devfreq->lock); - err = -EINVAL; - goto err_dev; - } - - devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev); devfreq->opp_table = dev_pm_opp_get_opp_table(dev); - if (IS_ERR(devfreq->opp_table)) + if (IS_ERR(devfreq->opp_table)) { devfreq->opp_table = NULL; + devfreq->scaling_min_freq = 0; + devfreq->scaling_max_freq = ULONG_MAX; + } else { + devfreq->scaling_min_freq = find_available_min_freq(devfreq); + if (!devfreq->scaling_min_freq) { + mutex_unlock(&devfreq->lock); + err = -EINVAL; + goto err_dev; + } + + devfreq->scaling_max_freq = find_available_max_freq(devfreq); + if (!devfreq->scaling_max_freq) { + mutex_unlock(&devfreq->lock); + err = -EINVAL; + goto err_dev; + } + + devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev); + } atomic_set(&devfreq->suspend_count, 0); -- 2.31.1 _______________________________________________ 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:[~2021-09-29 4:42 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-29 4:42 [PATCH 00/10] DRAM devfreq support for Allwinner A64/H5 Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 01/10] PM / devfreq: strengthen check for freq_table Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-30 3:58 ` Chanwoo Choi 2021-09-30 3:58 ` Chanwoo Choi 2021-09-29 4:42 ` Samuel Holland [this message] 2021-09-29 4:42 ` [PATCH 02/10] PM / devfreq: Do not require devices to have OPPs Samuel Holland 2021-09-30 4:19 ` Chanwoo Choi 2021-09-30 4:19 ` Chanwoo Choi 2021-09-30 11:37 ` Samuel Holland 2021-09-30 11:37 ` Samuel Holland 2021-10-01 1:59 ` Chanwoo Choi 2021-10-01 1:59 ` Chanwoo Choi 2021-10-01 1:45 ` Samuel Holland 2021-10-01 1:45 ` Samuel Holland 2021-10-01 2:14 ` Chanwoo Choi 2021-10-01 2:14 ` Chanwoo Choi 2021-09-29 4:42 ` [PATCH 03/10] PM / devfreq: Drop code for descending freq_table Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 04/10] PM / devfreq: Add a recommended frequency helper Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 05/10] dt-bindings: clock: sunxi: Export CLK_DRAM for devfreq Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 06/10] dt-bindings: arm: sunxi: Expand MBUS binding Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 13:46 ` Rob Herring 2021-09-29 13:46 ` Rob Herring 2021-09-29 4:42 ` [PATCH 07/10] dt-bindings: arm: sunxi: Add H5 MBUS compatible Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 08/10] ARM: dts: sunxi: h3/h5: Update MBUS node Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 09/10] arm64: dts: allwinner: a64: " Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-29 4:42 ` [PATCH 10/10] PM / devfreq: Add a driver for the sun8i/sun50i MBUS Samuel Holland 2021-09-29 4:42 ` Samuel Holland 2021-09-30 4:35 ` Chanwoo Choi 2021-09-30 4:35 ` Chanwoo Choi
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=20210929044254.38301-3-samuel@sholland.org \ --to=samuel@sholland.org \ --cc=cw00.choi@samsung.com \ --cc=devicetree@vger.kernel.org \ --cc=jernej.skrabec@gmail.com \ --cc=kyungmin.park@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-sunxi@lists.linux.dev \ --cc=mripard@kernel.org \ --cc=mturquette@baylibre.com \ --cc=myungjoo.ham@samsung.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=wens@csie.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.