linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Mike Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-clk@vger.kernel.org
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>,
	Yassine Oudjana <y.oudjana@protonmail.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	Tony Lindgren <tony@atomide.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Maxime Ripard <maxime@cerno.tech>
Subject: [PATCH v7 02/28] clk: bcm: rpi: Add a function to retrieve the maximum
Date: Fri, 15 Jul 2022 17:59:48 +0200	[thread overview]
Message-ID: <20220715160014.2623107-3-maxime@cerno.tech> (raw)
In-Reply-To: <20220715160014.2623107-1-maxime@cerno.tech>

The RaspberryPi firmware can be configured by the end user using the
config.txt file.

Some of these options will affect the kernel capabilities, and we thus
need to be able to detect it to operate reliably.

One of such parameters is the hdmi_enable_4kp60 parameter that will
setup the clocks in a way that is suitable to reach the pixel
frequencies required by the 4k at 60Hz and higher modes.

If the user forgot to enable it, then those modes will simply not work
but are still likely to be picked up by the userspace, which is a poor
user-experience.

The kernel can't access the config.txt file directly, but one of the
effect that parameter has is that the core clock frequency maximum will
be much higher. Thus we can infer whether it was enabled or not by
querying the firmware for that maximum, and if it isn't prevent any of
the modes that wouldn't work.

The HDMI driver is already doing this, but was relying on a behaviour of
clk_round_rate() that got changed recently, and doesn't return the
result we would like anymore.

We also considered introducing a CCF function to access the maximum of a
given struct clk, but that wouldn't work if the clock is further
constrained by another user.

It was thus suggested to create a small, ad-hoc function to query the
RaspberryPi firmware for the maximum rate a given clock has.

Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c        | 28 ++++++++++++++++++++++++
 include/soc/bcm2835/raspberrypi-clocks.h | 15 +++++++++++++
 2 files changed, 43 insertions(+)
 create mode 100644 include/soc/bcm2835/raspberrypi-clocks.h

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 6c0a0fd6cd79..182e8817eac2 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 
+#include <soc/bcm2835/raspberrypi-clocks.h>
 #include <soc/bcm2835/raspberrypi-firmware.h>
 
 enum rpi_firmware_clk_id {
@@ -254,6 +255,33 @@ static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw,
 	return 0;
 }
 
+unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
+{
+	const struct raspberrypi_clk_data *data;
+	struct raspberrypi_clk *rpi;
+	struct clk_hw *hw;
+	u32 max_rate;
+	int ret;
+
+	if (!clk)
+		return 0;
+
+	hw =  __clk_get_hw(clk);
+	if (!hw)
+		return 0;
+
+	data = clk_hw_to_data(hw);
+	rpi = data->rpi;
+	ret = raspberrypi_clock_property(rpi->firmware, data,
+					 RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
+					 &max_rate);
+	if (ret)
+		return 0;
+
+	return max_rate;
+}
+EXPORT_SYMBOL_GPL(rpi_firmware_clk_get_max_rate);
+
 static const struct clk_ops raspberrypi_firmware_clk_ops = {
 	.is_prepared	= raspberrypi_fw_is_prepared,
 	.recalc_rate	= raspberrypi_fw_get_rate,
diff --git a/include/soc/bcm2835/raspberrypi-clocks.h b/include/soc/bcm2835/raspberrypi-clocks.h
new file mode 100644
index 000000000000..ff0b608b51a8
--- /dev/null
+++ b/include/soc/bcm2835/raspberrypi-clocks.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __SOC_RASPBERRY_CLOCKS_H__
+#define __SOC_RASPBERRY_CLOCKS_H__
+
+#if IS_ENABLED(CONFIG_CLK_RASPBERRYPI)
+unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk);
+#else
+static inline unsigned long rpi_firmware_clk_get_max_rate(struct clk *clk)
+{
+	return ULONG_MAX;
+}
+#endif
+
+#endif /* __SOC_RASPBERRY_CLOCKS_H__ */
-- 
2.36.1


  parent reply	other threads:[~2022-07-15 16:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 15:59 [PATCH v7 00/28] clk: More clock rate fixes and tests Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 01/28] clk: bcm: rpi: Create helper to retrieve private data Maxime Ripard
2022-07-15 15:59 ` Maxime Ripard [this message]
2022-07-15 15:59 ` [PATCH v7 03/28] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 04/28] clk: test: Switch to clk_hw_get_clk Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 05/28] clk: Drop the rate range on clk_put() Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 06/28] clk: Skip clamping when rounding if there's no boundaries Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 07/28] clk: Mention that .recalc_rate can return 0 on error Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 08/28] clk: Clarify clk_get_rate() expectations Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 09/28] clk: tests: Add test suites description Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 10/28] clk: tests: Add reference to the orphan mux bug report Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 11/28] clk: tests: Add tests for uncached clock Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 12/28] clk: tests: Add tests for single parent mux Maxime Ripard
2022-07-15 15:59 ` [PATCH v7 13/28] clk: tests: Add tests for mux with multiple parents Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 14/28] clk: tests: Add some tests for orphan " Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 15/28] clk: Take into account uncached clocks in clk_set_rate_range() Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 16/28] clk: Set req_rate on reparenting Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 17/28] clk: Change clk_core_init_rate_req prototype Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 18/28] clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its caller Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 19/28] clk: Introduce clk_hw_init_rate_request() Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 20/28] clk: Add our request boundaries in clk_core_init_rate_req Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 21/28] clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 22/28] clk: Introduce clk_core_has_parent() Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 23/28] clk: Constify clk_has_parent() Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 24/28] clk: Stop forwarding clk_rate_requests to the parent Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 25/28] clk: Zero the clk_rate_request structure Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 26/28] clk: Introduce the clk_hw_get_rate_range function Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 27/28] clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3d Maxime Ripard
2022-07-15 16:00 ` [PATCH v7 28/28] clk: tests: Add missing test case for ranges 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=20220715160014.2623107-3-maxime@cerno.tech \
    --to=maxime@cerno.tech \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=jbrunet@baylibre.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mturquette@baylibre.com \
    --cc=naresh.kamboju@linaro.org \
    --cc=narmstrong@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=tony@atomide.com \
    --cc=y.oudjana@protonmail.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).