Re: [PATCH v2 2/3] drm/vc4: hdmi: Disable Wifi Frequencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 29.10.20 um 14:40 schrieb Maxime Ripard:
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 <maxime@xxxxxxxxxx>

---

Changes from v1:
   - Change the name of the property
   - Test for a range instead of an exact frequency
---
  drivers/gpu/drm/vc4/vc4_hdmi.c | 21 +++++++++++++++++++++
  drivers/gpu/drm/vc4/vc4_hdmi.h |  8 ++++++++
  2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 506c12454086..0d72e519aec4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -760,6 +760,9 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
  {
  }
+#define WIFI_2_4GHz_CH1_MIN_FREQ 2400000000ULL
+#define WIFI_2_4GHz_CH1_MAX_FREQ	2422000000ULL
+
  static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
  					 struct drm_crtc_state *crtc_state,
  					 struct drm_connector_state *conn_state)
@@ -767,12 +770,27 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
  	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 tmds_rate;
if (vc4_hdmi->variant->unsupported_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 first
+	 * WiFi channel (between 2.4GHz and 2.422GHz with 22MHz
+	 * bandwidth). Slightly lower the frequency to bring it out of
+	 * the WiFi range.
+	 */
+	tmds_rate = pixel_rate * 10;
+	if (vc4_hdmi->disable_wifi_frequencies &&
+	    (tmds_rate >= WIFI_2_4GHz_CH1_MIN_FREQ &&
+	     tmds_rate <= WIFI_2_4GHz_CH1_MAX_FREQ)) {
+		mode->clock = 238560;
+		pixel_rate = mode->clock * 1000;
+	}
+
  	if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
  		return -EINVAL;
@@ -1717,6 +1735,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, "wifi-2.4ghz-coexistence");
+
  	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 6815e93b1a48..3843be830601 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -142,6 +142,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.

The final sentence sounds like a question. Maybe just write 'Take evasive actions if...'

Assuming that the display mode still works

Acked-by: Thomas Zimmermann <tzimmermann@xxxxxxx>

+	 */
+	bool disable_wifi_frequencies;
+
  	struct cec_adapter *cec_adap;
  	struct cec_msg cec_rx_msg;
  	bool cec_tx_ok;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Attachment: OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux