All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.