All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Michael Turquette <mturquette@baylibre.com>,
	Ray Jui <rjui@broadcom.com>,
	Broadcom internal kernel review list 
	<bcm-kernel-feedback-list@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Stephen Boyd <sboyd@kernel.org>,
	Scott Branden <sbranden@broadcom.com>,
	Maxime Ripard <mripard@kernel.org>, Emma Anholt <emma@anholt.net>
Cc: Maxime Ripard <maxime@cerno.tech>,
	linux-arm-kernel@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org,
	Dom Cobley <popcornmix@gmail.com>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v1 7/7] drm/vc4: Make sure we don't end up with a core clock too high
Date: Mon, 15 Aug 2022 17:31:29 +0200	[thread overview]
Message-ID: <20220815-rpi-fix-4k-60-v1-7-c52bd642f7c6@cerno.tech> (raw)
In-Reply-To: <20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech>

Following the clock rate range improvements to the clock framework,
trying to set a disjoint range on a clock will now result in an error.

Thus, we can't set a minimum rate higher than the maximum reported by
the firmware, or clk_set_min_rate() will fail.

Thus we need to clamp the rate we are about to ask for to the maximum
rate possible on that clock.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index b45dcdfd7306..4794e7235bb0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -22,6 +22,8 @@
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_vblank.h>
 
+#include <soc/bcm2835/raspberrypi-clocks.h>
+
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
@@ -354,6 +356,7 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	struct vc4_hvs_state *new_hvs_state;
 	struct drm_crtc *crtc;
 	struct vc4_hvs_state *old_hvs_state;
+	unsigned long max_clock_rate;
 	unsigned int channel;
 	int i;
 
@@ -394,11 +397,12 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 		old_hvs_state->fifo_state[channel].pending_commit = NULL;
 	}
 
+	max_clock_rate = rpi_firmware_clk_get_max_rate(hvs->core_clk);
 	if (vc4->is_vc5) {
 		unsigned long state_rate = max(old_hvs_state->core_clock_rate,
 					       new_hvs_state->core_clock_rate);
-		unsigned long core_rate = max_t(unsigned long,
-						500000000, state_rate);
+		unsigned long core_rate = clamp_t(unsigned long, state_rate,
+						  500000000, max_clock_rate);
 
 		drm_dbg(dev, "Raising the core clock at %lu Hz\n", core_rate);
 
@@ -432,14 +436,17 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	drm_atomic_helper_cleanup_planes(dev, state);
 
 	if (vc4->is_vc5) {
-		drm_dbg(dev, "Running the core clock at %lu Hz\n",
-			new_hvs_state->core_clock_rate);
+		unsigned long core_rate = min_t(unsigned long,
+					       max_clock_rate,
+					       new_hvs_state->core_clock_rate);
+
+		drm_dbg(dev, "Running the core clock at %lu Hz\n", core_rate);
 
 		/*
 		 * Request a clock rate based on the current HVS
 		 * requirements.
 		 */
-		WARN_ON(clk_set_min_rate(hvs->core_clk, new_hvs_state->core_clock_rate));
+		WARN_ON(clk_set_min_rate(hvs->core_clk, core_rate));
 
 		drm_dbg(dev, "Core clock actual rate: %lu Hz\n",
 			clk_get_rate(hvs->core_clk));

-- 
b4 0.10.0-dev-a76f5

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Michael Turquette <mturquette@baylibre.com>,
	Ray Jui <rjui@broadcom.com>,
	Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>,
	 Florian Fainelli <f.fainelli@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Stephen Boyd <sboyd@kernel.org>,
	Scott Branden <sbranden@broadcom.com>,
	Maxime Ripard <mripard@kernel.org>, Emma Anholt <emma@anholt.net>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Maxime Ripard <maxime@cerno.tech>,
	Dom Cobley <popcornmix@gmail.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org
Subject: [PATCH v1 7/7] drm/vc4: Make sure we don't end up with a core clock too high
Date: Mon, 15 Aug 2022 17:31:29 +0200	[thread overview]
Message-ID: <20220815-rpi-fix-4k-60-v1-7-c52bd642f7c6@cerno.tech> (raw)
In-Reply-To: <20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech>

Following the clock rate range improvements to the clock framework,
trying to set a disjoint range on a clock will now result in an error.

Thus, we can't set a minimum rate higher than the maximum reported by
the firmware, or clk_set_min_rate() will fail.

Thus we need to clamp the rate we are about to ask for to the maximum
rate possible on that clock.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index b45dcdfd7306..4794e7235bb0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -22,6 +22,8 @@
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_vblank.h>
 
+#include <soc/bcm2835/raspberrypi-clocks.h>
+
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
@@ -354,6 +356,7 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	struct vc4_hvs_state *new_hvs_state;
 	struct drm_crtc *crtc;
 	struct vc4_hvs_state *old_hvs_state;
+	unsigned long max_clock_rate;
 	unsigned int channel;
 	int i;
 
@@ -394,11 +397,12 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 		old_hvs_state->fifo_state[channel].pending_commit = NULL;
 	}
 
+	max_clock_rate = rpi_firmware_clk_get_max_rate(hvs->core_clk);
 	if (vc4->is_vc5) {
 		unsigned long state_rate = max(old_hvs_state->core_clock_rate,
 					       new_hvs_state->core_clock_rate);
-		unsigned long core_rate = max_t(unsigned long,
-						500000000, state_rate);
+		unsigned long core_rate = clamp_t(unsigned long, state_rate,
+						  500000000, max_clock_rate);
 
 		drm_dbg(dev, "Raising the core clock at %lu Hz\n", core_rate);
 
@@ -432,14 +436,17 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	drm_atomic_helper_cleanup_planes(dev, state);
 
 	if (vc4->is_vc5) {
-		drm_dbg(dev, "Running the core clock at %lu Hz\n",
-			new_hvs_state->core_clock_rate);
+		unsigned long core_rate = min_t(unsigned long,
+					       max_clock_rate,
+					       new_hvs_state->core_clock_rate);
+
+		drm_dbg(dev, "Running the core clock at %lu Hz\n", core_rate);
 
 		/*
 		 * Request a clock rate based on the current HVS
 		 * requirements.
 		 */
-		WARN_ON(clk_set_min_rate(hvs->core_clk, new_hvs_state->core_clock_rate));
+		WARN_ON(clk_set_min_rate(hvs->core_clk, core_rate));
 
 		drm_dbg(dev, "Core clock actual rate: %lu Hz\n",
 			clk_get_rate(hvs->core_clk));

-- 
b4 0.10.0-dev-a76f5

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Michael Turquette <mturquette@baylibre.com>,
	Ray Jui <rjui@broadcom.com>,
	Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Stephen Boyd <sboyd@kernel.org>,
	Scott Branden <sbranden@broadcom.com>,
	Maxime Ripard <mripard@kernel.org>, Emma Anholt <emma@anholt.net>
Cc: Maxime Ripard <maxime@cerno.tech>,
	linux-arm-kernel@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org,
	Dom Cobley <popcornmix@gmail.com>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v1 7/7] drm/vc4: Make sure we don't end up with a core clock too high
Date: Mon, 15 Aug 2022 17:31:29 +0200	[thread overview]
Message-ID: <20220815-rpi-fix-4k-60-v1-7-c52bd642f7c6@cerno.tech> (raw)
In-Reply-To: <20220815-rpi-fix-4k-60-v1-0-c52bd642f7c6@cerno.tech>

Following the clock rate range improvements to the clock framework,
trying to set a disjoint range on a clock will now result in an error.

Thus, we can't set a minimum rate higher than the maximum reported by
the firmware, or clk_set_min_rate() will fail.

Thus we need to clamp the rate we are about to ask for to the maximum
rate possible on that clock.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index b45dcdfd7306..4794e7235bb0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -22,6 +22,8 @@
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_vblank.h>
 
+#include <soc/bcm2835/raspberrypi-clocks.h>
+
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
@@ -354,6 +356,7 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	struct vc4_hvs_state *new_hvs_state;
 	struct drm_crtc *crtc;
 	struct vc4_hvs_state *old_hvs_state;
+	unsigned long max_clock_rate;
 	unsigned int channel;
 	int i;
 
@@ -394,11 +397,12 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 		old_hvs_state->fifo_state[channel].pending_commit = NULL;
 	}
 
+	max_clock_rate = rpi_firmware_clk_get_max_rate(hvs->core_clk);
 	if (vc4->is_vc5) {
 		unsigned long state_rate = max(old_hvs_state->core_clock_rate,
 					       new_hvs_state->core_clock_rate);
-		unsigned long core_rate = max_t(unsigned long,
-						500000000, state_rate);
+		unsigned long core_rate = clamp_t(unsigned long, state_rate,
+						  500000000, max_clock_rate);
 
 		drm_dbg(dev, "Raising the core clock at %lu Hz\n", core_rate);
 
@@ -432,14 +436,17 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state)
 	drm_atomic_helper_cleanup_planes(dev, state);
 
 	if (vc4->is_vc5) {
-		drm_dbg(dev, "Running the core clock at %lu Hz\n",
-			new_hvs_state->core_clock_rate);
+		unsigned long core_rate = min_t(unsigned long,
+					       max_clock_rate,
+					       new_hvs_state->core_clock_rate);
+
+		drm_dbg(dev, "Running the core clock at %lu Hz\n", core_rate);
 
 		/*
 		 * Request a clock rate based on the current HVS
 		 * requirements.
 		 */
-		WARN_ON(clk_set_min_rate(hvs->core_clk, new_hvs_state->core_clock_rate));
+		WARN_ON(clk_set_min_rate(hvs->core_clk, core_rate));
 
 		drm_dbg(dev, "Core clock actual rate: %lu Hz\n",
 			clk_get_rate(hvs->core_clk));

-- 
b4 0.10.0-dev-a76f5

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-08-15 15:32 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15 15:31 [PATCH v1 0/7] drm/vc4: Fix the core clock behaviour Maxime Ripard
2022-08-15 15:31 ` Maxime Ripard
2022-08-15 15:31 ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 1/7] clk: bcm: rpi: Create helper to retrieve private data Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 2/7] clk: bcm: rpi: Add a function to retrieve the maximum Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-09-14 15:50   ` Stephen Boyd
2022-09-14 15:50     ` Stephen Boyd
2022-09-14 15:50     ` Stephen Boyd
2022-09-14 16:15     ` Maxime Ripard
2022-09-14 16:15       ` Maxime Ripard
2022-09-14 16:15       ` Maxime Ripard
2022-09-14 18:07       ` Stephen Boyd
2022-09-14 18:07         ` Stephen Boyd
2022-09-14 18:07         ` Stephen Boyd
2022-09-14 17:45     ` Stefan Wahren
2022-09-14 17:45       ` Stefan Wahren
2022-09-14 17:45       ` Stefan Wahren
2022-09-14 18:05       ` Stephen Boyd
2022-09-14 18:05         ` Stephen Boyd
2022-09-14 18:05         ` Stephen Boyd
2022-09-14 18:09         ` Stefan Wahren
2022-09-14 18:09           ` Stefan Wahren
2022-09-14 18:09           ` Stefan Wahren
2022-09-14 18:14           ` Stephen Boyd
2022-09-14 18:14             ` Stephen Boyd
2022-09-14 18:14             ` Stephen Boyd
2022-09-14 18:26             ` Stefan Wahren
2022-09-14 18:26               ` Stefan Wahren
2022-09-14 18:26               ` Stefan Wahren
2022-09-15  7:54               ` Maxime Ripard
2022-09-15  7:54                 ` Maxime Ripard
2022-09-15  7:54                 ` Maxime Ripard
2022-09-15 11:30                 ` Stefan Wahren
2022-09-15 11:30                   ` Stefan Wahren
2022-09-15 11:30                   ` Stefan Wahren
2022-09-15 11:38                   ` Maxime Ripard
2022-09-15 11:38                     ` Maxime Ripard
2022-09-15 11:38                     ` Maxime Ripard
2022-09-14 18:20           ` Stephen Boyd
2022-09-14 18:20             ` Stephen Boyd
2022-09-14 18:20             ` Stephen Boyd
2022-09-15  6:15             ` Stefan Wahren
2022-09-15  6:15               ` Stefan Wahren
2022-09-15  6:15               ` Stefan Wahren
2022-09-15  9:55             ` Maxime Ripard
2022-09-15  9:55               ` Maxime Ripard
2022-09-15  9:55               ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 3/7] clk: bcm: rpi: Add a function to retrieve the minimum Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 4/7] drm/vc4: hdmi: Fix hdmi_enable_4kp60 detection Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 5/7] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31 ` [PATCH v1 6/7] drm/vc4: hdmi: Add more checks for 4k resolutions Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-15 15:31 ` Maxime Ripard [this message]
2022-08-15 15:31   ` [PATCH v1 7/7] drm/vc4: Make sure we don't end up with a core clock too high Maxime Ripard
2022-08-15 15:31   ` Maxime Ripard
2022-08-29 15:11 ` [PATCH v1 0/7] drm/vc4: Fix the core clock behaviour Maxime Ripard
2022-08-29 15:11   ` Maxime Ripard
2022-08-29 15:11   ` Maxime Ripard

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=20220815-rpi-fix-4k-60-v1-7-c52bd642f7c6@cerno.tech \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mripard@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=popcornmix@gmail.com \
    --cc=rjui@broadcom.com \
    --cc=sboyd@kernel.org \
    --cc=sbranden@broadcom.com \
    /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.