openwrt/target/linux/bcm27xx/patches-5.15/950-0868-drm-vc4-hdmi-Rework-hdmi_enable_4kp60-detection.patch
John Audia d6d8851d12 kernel: bump 5.15 to 5.15.100
Manually rebased:
        bcm27xx/patches-5.15/950-0421-Support-RPi-DPI-interface-in-mode6-for-18-bit-color.patch
        bcm27xx/patches-5.15/950-0706-media-i2c-imx219-Scale-the-pixel-clock-rate-for-the-.patch
        ramips/patches-5.15/810-uvc-add-iPassion-iP2970-support.patch

Removed upstreamed:
        bcm27xx/patches-5.15/950-0707-drm-vc4-For-DPI-MEDIA_BUS_FMT_RGB565_1X16-is-mode-1-.patch[1]
        bcm27xx/patches-5.15/950-0596-drm-vc4-dpi-Add-option-for-inverting-pixel-clock-and.patch[2]
        ipq807x/0006-v5.16-arm64-dts-qcom-Fix-IPQ8074-PCIe-PHY-nodes.patch [3]
        ipq807x/0034-v6.1-arm64-dts-qcom-ipq8074-fix-PCIe-PHY-serdes-size.patch [4]
        ipq807x/0103-arm64-dts-qcom-ipq8074-fix-Gen2-PCIe-QMP-PHY.patch [5]
        ipq807x/0104-arm64-dts-qcom-ipq8074-fix-Gen3-PCIe-QMP-PHY.patch [6]
        ipq807x/0105-arm64-dts-qcom-ipq8074-correct-Gen2-PCIe-ranges.patch [7]
        ipq807x/0108-arm64-dts-qcom-ipq8074-fix-Gen3-PCIe-node.patch [8]
        ipq807x/0109-arm64-dts-qcom-ipq8074-correct-PCIe-QMP-PHY-output-c.patch [9]
        ipq807x/0132-arm64-dts-qcom-ipq8074-correct-USB3-QMP-PHY-s-clock-.patch [10]

All other patches automatically rebased.

1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.99&id=d2991e6b30020e286f2dd9d3b4f43548c547caa6
2. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/vc4/vc4_dpi.c?h=v5.15.100&id=8e04aaffb6de5f1ae61de7b671c1531172ccf429
3. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=a55a645aa303a3f7ec37db69822d5420657626da
4. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=d9df682bcea57fa25f37bbf17eae56fa05662635
5. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=7e6eeb5fb3aa9e5feffdb6e137dcc06f5f6410e1
6. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=e88204931d9a60634cd50bbc679f045439c4b91d
7.  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=1563af0f28afd3b6d64ac79a2aecced3969c90bf
8. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=feb8c71f015d416f1afe90e1f62cf51e47376c67
9. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=69c7a270357a7d50ffd3471b14c60250041200e3
10. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v5.15.99&id=dd3d021ae5471d98adf81f1e897431c8657d0a18

Build system: x86_64
Build-tested: bcm2711/RPi4B, ramips/tplink_archer-a6-v3
Run-tested: bcm2711/RPi4B, ramips/tplink_archer-a6-v3

Signed-off-by: John Audia <therealgraysky@proton.me>
Tested-by: Robert Marko <robimarko@gmail.com> #ipq807x/Dynalink WRX36
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> #ipq807x/ax3600, x86_64/FW-7543B, ath79/tl-wdr3600, ipq806x/g10, ipq806x/nbg6817
2023-03-18 12:52:17 +01:00

135 lines
4.7 KiB
Diff

From 62dd8774e71d9af9b0f3cabdeacbb80d24313504 Mon Sep 17 00:00:00 2001
From: Maxime Ripard <maxime@cerno.tech>
Date: Thu, 24 Mar 2022 11:57:57 +0100
Subject: [PATCH] drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection
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 instead try to set a minimum on that clock for the rate we'd like
to reach. If the maximum reported by the firmware is below the minimum
we're trying to set, the clock framework will return an error which we
then can use to infer whether the parameter is set or not.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
drivers/gpu/drm/vc4/vc4_drv.h | 8 ++++++++
drivers/gpu/drm/vc4/vc4_hdmi.c | 14 ++++----------
drivers/gpu/drm/vc4/vc4_hdmi.h | 8 --------
drivers/gpu/drm/vc4/vc4_hvs.c | 6 ++++++
4 files changed, 18 insertions(+), 18 deletions(-)
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -341,6 +341,14 @@ struct vc4_hvs {
/* HVS version 5 flag, therefore requires updated dlist structures */
bool hvs5;
+
+ /*
+ * Even if HDMI0 on the RPi4 can output modes requiring a pixel
+ * rate higher than 297MHz, it needs some adjustments in the
+ * config.txt file to be able to do so and thus won't always be
+ * available.
+ */
+ bool vc5_hdmi_enable_scrambling;
};
struct vc4_plane {
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -292,6 +292,7 @@ static int vc4_hdmi_connector_get_modes(
{
struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
struct vc4_hdmi_encoder *vc4_encoder = &vc4_hdmi->encoder;
+ struct vc4_dev *vc4 = to_vc4_dev(connector->dev);
int ret = 0;
struct edid *edid;
@@ -310,7 +311,7 @@ static int vc4_hdmi_connector_get_modes(
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
- if (vc4_hdmi->disable_4kp60) {
+ if (!vc4->hvs->vc5_hdmi_enable_scrambling) {
struct drm_device *drm = connector->dev;
struct drm_display_mode *mode;
@@ -1673,11 +1674,12 @@ vc4_hdmi_encoder_clock_valid(const struc
{
const struct drm_connector *connector = &vc4_hdmi->connector;
const struct drm_display_info *info = &connector->display_info;
+ struct vc4_dev *vc4 = to_vc4_dev(connector->dev);
if (clock > vc4_hdmi->variant->max_pixel_clock)
return MODE_CLOCK_HIGH;
- if (vc4_hdmi->disable_4kp60 && clock > HDMI_14_MAX_TMDS_CLK)
+ if (!vc4->hvs->vc5_hdmi_enable_scrambling && clock > HDMI_14_MAX_TMDS_CLK)
return MODE_CLOCK_HIGH;
if (info->max_tmds_clock && clock > (info->max_tmds_clock * 1000))
@@ -3158,14 +3160,6 @@ static int vc4_hdmi_bind(struct device *
vc4_hdmi->disable_wifi_frequencies =
of_property_read_bool(dev->of_node, "wifi-2.4ghz-coexistence");
- 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);
-
- if (max_rate < 550000000)
- vc4_hdmi->disable_4kp60 = true;
- }
-
/*
* If we boot without any cable connected to the HDMI connector,
* the firmware will skip the HSM initialization and leave it
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -169,14 +169,6 @@ struct vc4_hdmi {
*/
bool disable_wifi_frequencies;
- /*
- * Even if HDMI0 on the RPi4 can output modes requiring a pixel
- * rate higher than 297MHz, it needs some adjustments in the
- * config.txt file to be able to do so and thus won't always be
- * available.
- */
- bool disable_4kp60;
-
struct cec_adapter *cec_adap;
struct cec_msg cec_rx_msg;
bool cec_tx_ok;
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -897,12 +897,18 @@ static int vc4_hvs_bind(struct device *d
hvs->regset.nregs = ARRAY_SIZE(hvs_regs);
if (hvs->hvs5) {
+ unsigned long max_rate;
+
hvs->core_clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(hvs->core_clk)) {
dev_err(&pdev->dev, "Couldn't get core clock\n");
return PTR_ERR(hvs->core_clk);
}
+ max_rate = clk_get_max_rate(hvs->core_clk);
+ if (max_rate >= 550000000)
+ hvs->vc5_hdmi_enable_scrambling = true;
+
ret = clk_prepare_enable(hvs->core_clk);
if (ret) {
dev_err(&pdev->dev, "Couldn't enable the core clock\n");