linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Daniel Vetter <daniel@ffwll.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Scott Branden <sbranden@broadcom.com>,
	Stephen Boyd <sboyd@kernel.org>, Emma Anholt <emma@anholt.net>,
	Ray Jui <rjui@broadcom.com>, Maxime Ripard <mripard@kernel.org>
Cc: linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, Dom Cobley <popcornmix@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Maxime Ripard <maxime@cerno.tech>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/7] drm/vc4: hdmi: Fix hdmi_enable_4kp60 detection
Date: Tue, 20 Sep 2022 14:50:23 +0200	[thread overview]
Message-ID: <20220815-rpi-fix-4k-60-v2-4-983276b83f62@cerno.tech> (raw)
In-Reply-To: <20220815-rpi-fix-4k-60-v2-0-983276b83f62@cerno.tech>

In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60 parameter in their config.txt file.

We were detecting this so far by calling clk_round_rate() on the core
clock with the frequency we're supposed to run at when one of those
modes is enabled. Whether or not the parameter was enabled could then be
inferred by the returned rate since the maximum clock rate reported by
the firmware was one of the side effect of setting that parameter.

However, the recent clock rework we did changed what clk_round_rate()
was returning to always return the minimum allowed, and thus this test
wasn't reliable anymore.

Let's use the new clk_get_max_rate() function to reliably determine the
maximum rate allowed on that clock and fix the 4k@60Hz output.

Fixes: e9d6cea2af1c ("clk: bcm: rpi: Run some clocks at the minimum rate allowed")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1e5f68704d7d..3b75ac6fa0db 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -46,6 +46,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/rational.h>
 #include <linux/reset.h>
+#include <soc/bcm2835/raspberrypi-clocks.h>
 #include <sound/dmaengine_pcm.h>
 #include <sound/hdmi-codec.h>
 #include <sound/pcm_drm_eld.h>
@@ -2966,7 +2967,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
 
 	if (variant->max_pixel_clock == 600000000) {
 		struct vc4_dev *vc4 = to_vc4_dev(drm);
-		long max_rate = clk_round_rate(vc4->hvs->core_clk, 550000000);
+		unsigned long max_rate = rpi_firmware_clk_get_max_rate(vc4->hvs->core_clk);
 
 		if (max_rate < 550000000)
 			vc4_hdmi->disable_4kp60 = true;

-- 
b4 0.10.0

_______________________________________________
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-09-20 12:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 12:50 [PATCH v2 0/7] drm/vc4: Fix the core clock behaviour Maxime Ripard
2022-09-20 12:50 ` [PATCH v2 1/7] firmware: raspberrypi: Introduce rpi_firmware_find_node() Maxime Ripard
2022-09-20 12:50 ` [PATCH v2 2/7] firmware: raspberrypi: Move the clock IDs to the firmware header Maxime Ripard
2022-09-20 16:01   ` Stefan Wahren
2022-09-21  9:17     ` Maxime Ripard
2022-09-20 12:50 ` [PATCH v2 3/7] firmware: raspberrypi: Provide a helper to query a clock max rate Maxime Ripard
2022-09-29  0:23   ` Stephen Boyd
2022-10-10 16:52   ` Stefan Wahren
2022-09-20 12:50 ` Maxime Ripard [this message]
2022-09-20 12:50 ` [PATCH v2 5/7] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection code Maxime Ripard
2022-09-20 12:50 ` [PATCH v2 6/7] drm/vc4: hdmi: Add more checks for 4k resolutions Maxime Ripard
2022-09-20 12:50 ` [PATCH v2 7/7] drm/vc4: Make sure we don't end up with a core clock too high Maxime Ripard
2022-10-10 11:44 ` [PATCH v2 0/7] drm/vc4: Fix the core clock behaviour Maxime Ripard
2022-10-10 19:07   ` Florian Fainelli
2022-10-13  8:59     ` 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-v2-4-983276b83f62@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).