There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
chip and some resolutions, most notably 1440p at 60Hz.
In such a case, we can either reject entirely the mode, or lower slightly
the pixel frequency to remove the overlap. Let's go for the latter.
Signed-off-by: Maxime Ripard <max...@cerno.tech>
---
.../bindings/display/brcm,bcm2711-hdmi.yaml | 6 ++++++
drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +++++++++++++-
drivers/gpu/drm/vc4/vc4_hdmi.h | 8 ++++++++
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a76729d26c..63e7fe999c0a 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -76,6 +76,12 @@ properties:
resets:
maxItems: 1
+ raspberrypi,disable-wifi-frequencies:
+ type: boolean
+ description: >
+ Should the pixel frequencies in the WiFi frequencies range be
+ avoided?
+
required:
- compatible
- reg
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index acfb4e235214..74da7c00ecd0 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -877,13 +877,22 @@ static int vc4_hdmi_encoder_atomic_check(struct
drm_encoder *encoder,
struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
- unsigned long long pixel_rate = mode->clock * 1000;
+ unsigned long long pixel_rate;
if (vc4_hdmi->variant->broken_odd_h_timings &&
((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
(mode->hsync_end % 2) || (mode->htotal % 2)))
return -EINVAL;
+ /*
+ * The 1440p@60 pixel rate is in the same range than the WiFi
+ * channels. Slightly lower the frequency to bring it out of the
+ * WiFi range.
+ */
+ if (vc4_hdmi->disable_wifi_frequencies && mode->clock == 241500)
+ mode->clock = 238560;
+
+ pixel_rate = mode->clock * 1000;
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
pixel_rate *= 2;
@@ -1837,6 +1846,9 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
vc4_hdmi->hpd_active_low = hpd_gpio_flags & OF_GPIO_ACTIVE_LOW;
}
+ vc4_hdmi->disable_wifi_frequencies =
+ of_property_read_bool(dev->of_node,
"raspberrypi,disable-wifi-frequencies");
+
pm_runtime_enable(dev);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 40e51ece8efe..6618ee758890 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -143,6 +143,14 @@ struct vc4_hdmi {
int hpd_gpio;
bool hpd_active_low;
+ /*
+ * On some systems (like the RPi4), some modes are in the same
+ * frequency range than the WiFi channels (1440p@60Hz for
+ * example). Should we take evasive actions because that system
+ * has a wifi adapter.
+ */
+ bool disable_wifi_frequencies;
+
struct cec_adapter *cec_adap;
struct cec_msg cec_rx_msg;
bool cec_tx_ok;
--
2.26.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
