[PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
HDMI cable right in the middle of the first Wifi channel.

Add a property to our HDMI controller, that could be reused by other
similar HDMI controllers, to allow the OS to take whatever measure is
necessary to avoid that crosstalk.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Renamed the property
  - Split it into a separate patch
---
 .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a76729d26c..7ce06f9f9f8e 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
 
+  wifi-2.4ghz-coexistence:
+    type: boolean
+    description: >
+      Should the pixel frequencies in the WiFi frequencies range be
+      avoided?
+
 required:
   - compatible
   - reg
-- 
2.26.2

[PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
HDMI cable right in the middle of the first Wifi channel.

Add a property to our HDMI controller, that could be reused by other
similar HDMI controllers, to allow the OS to take whatever measure is
necessary to avoid that crosstalk.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Renamed the property
  - Split it into a separate patch
---
 .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a76729d26c..7ce06f9f9f8e 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
 
+  wifi-2.4ghz-coexistence:
+    type: boolean
+    description: >
+      Should the pixel frequencies in the WiFi frequencies range be
+      avoided?
+
 required:
   - compatible
   - reg
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
HDMI cable right in the middle of the first Wifi channel.

Add a property to our HDMI controller, that could be reused by other
similar HDMI controllers, to allow the OS to take whatever measure is
necessary to avoid that crosstalk.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Renamed the property
  - Split it into a separate patch
---
 .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a76729d26c..7ce06f9f9f8e 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
 
+  wifi-2.4ghz-coexistence:
+    type: boolean
+    description: >
+      Should the pixel frequencies in the WiFi frequencies range be
+      avoided?
+
 required:
   - compatible
   - reg
-- 
2.26.2

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

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

[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@cerno.tech>

---

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.
+	 */
+	bool disable_wifi_frequencies;
+
 	struct cec_adapter *cec_adap;
 	struct cec_msg cec_rx_msg;
 	bool cec_tx_ok;
-- 
2.26.2

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

[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@cerno.tech>

---

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.
+	 */
+	bool disable_wifi_frequencies;
+
 	struct cec_adapter *cec_adap;
 	struct cec_msg cec_rx_msg;
 	bool cec_tx_ok;
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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@cerno.tech>

---

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.
+	 */
+	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

[PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Maxime Ripard]

The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
maneuvers.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Changed the property name
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..403bacf986eb 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -181,12 +181,14 @@ &gpio {
 &hdmi0 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
 &hdmi1 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
-- 
2.26.2

[PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Maxime Ripard]

The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
maneuvers.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Changed the property name
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..403bacf986eb 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -181,12 +181,14 @@ &gpio {
 &hdmi0 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
 &hdmi1 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
-- 
2.26.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Maxime Ripard]

The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
maneuvers.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---

Changes from v1:
  - Changed the property name
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 09a1182c2936..403bacf986eb 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -181,12 +181,14 @@ &gpio {
 &hdmi0 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 0>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
 &hdmi1 {
 	clocks = <&firmware_clocks 13>, <&firmware_clocks 14>, <&dvp 1>, <&clk_27MHz>;
 	clock-names = "hdmi", "bvb", "audio", "cec";
+	wifi-2.4ghz-coexistence;
 	status = "okay";
 };
 
-- 
2.26.2

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

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Hi maxime,

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> index 03a76729d26c..7ce06f9f9f8e 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
>  
> +  wifi-2.4ghz-coexistence:

I see you already renamed the property, but I can't seem to find v1 of the
series online. Sorry if this is redundant:

I wonder if it'd make sense to prefix the property like this:
"raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
with generic properties, and also thought it was a rule. Although I may have as
well imagined it.

Other than that the series looks OK to me.

Regards,
Nicolas



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 1627 bytes --]

Hi maxime,

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> index 03a76729d26c..7ce06f9f9f8e 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
>  
> +  wifi-2.4ghz-coexistence:

I see you already renamed the property, but I can't seem to find v1 of the
series online. Sorry if this is redundant:

I wonder if it'd make sense to prefix the property like this:
"raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
with generic properties, and also thought it was a rule. Although I may have as
well imagined it.

Other than that the series looks OK to me.

Regards,
Nicolas



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 1627 bytes --]

Hi maxime,

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> index 03a76729d26c..7ce06f9f9f8e 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
>  
> +  wifi-2.4ghz-coexistence:

I see you already renamed the property, but I can't seem to find v1 of the
series online. Sorry if this is redundant:

I wonder if it'd make sense to prefix the property like this:
"raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
with generic properties, and also thought it was a rule. Although I may have as
well imagined it.

Other than that the series looks OK to me.

Regards,
Nicolas



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

Hi Nicolas,

On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> Hi maxime,
> 
> On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > HDMI cable right in the middle of the first Wifi channel.
> > 
> > Add a property to our HDMI controller, that could be reused by other
> > similar HDMI controllers, to allow the OS to take whatever measure is
> > necessary to avoid that crosstalk.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > ---
> > 
> > Changes from v1:
> >   - Renamed the property
> >   - Split it into a separate patch
> > ---
> >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > index 03a76729d26c..7ce06f9f9f8e 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
> >  
> > +  wifi-2.4ghz-coexistence:
> 
> I see you already renamed the property, but I can't seem to find v1 of the
> series online.

I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/

> Sorry if this is redundant:
> 
> I wonder if it'd make sense to prefix the property like this:
> "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> with generic properties, and also thought it was a rule. Although I may have as
> well imagined it.

Rob in the first iteration asked for the opposite :)

It used to be a vendor-specific property, and since this issue is
basically cross-platform (as long as you can support 1440p and have
WiFi), it makes sense to make this a generic property

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2152 bytes --]

Hi Nicolas,

On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> Hi maxime,
> 
> On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > HDMI cable right in the middle of the first Wifi channel.
> > 
> > Add a property to our HDMI controller, that could be reused by other
> > similar HDMI controllers, to allow the OS to take whatever measure is
> > necessary to avoid that crosstalk.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > ---
> > 
> > Changes from v1:
> >   - Renamed the property
> >   - Split it into a separate patch
> > ---
> >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > index 03a76729d26c..7ce06f9f9f8e 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
> >  
> > +  wifi-2.4ghz-coexistence:
> 
> I see you already renamed the property, but I can't seem to find v1 of the
> series online.

I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/

> Sorry if this is redundant:
> 
> I wonder if it'd make sense to prefix the property like this:
> "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> with generic properties, and also thought it was a rule. Although I may have as
> well imagined it.

Rob in the first iteration asked for the opposite :)

It used to be a vendor-specific property, and since this issue is
basically cross-platform (as long as you can support 1440p and have
WiFi), it makes sense to make this a generic property

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 2152 bytes --]

Hi Nicolas,

On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> Hi maxime,
> 
> On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > HDMI cable right in the middle of the first Wifi channel.
> > 
> > Add a property to our HDMI controller, that could be reused by other
> > similar HDMI controllers, to allow the OS to take whatever measure is
> > necessary to avoid that crosstalk.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > ---
> > 
> > Changes from v1:
> >   - Renamed the property
> >   - Split it into a separate patch
> > ---
> >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > index 03a76729d26c..7ce06f9f9f8e 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
> >  
> > +  wifi-2.4ghz-coexistence:
> 
> I see you already renamed the property, but I can't seem to find v1 of the
> series online.

I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/

> Sorry if this is redundant:
> 
> I wonder if it'd make sense to prefix the property like this:
> "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> with generic properties, and also thought it was a rule. Although I may have as
> well imagined it.

Rob in the first iteration asked for the opposite :)

It used to be a vendor-specific property, and since this issue is
basically cross-platform (as long as you can support 1440p and have
WiFi), it makes sense to make this a generic property

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

On Thu, 2020-10-29 at 19:07 +0100, Maxime Ripard wrote:
> Hi Nicolas,
> 
> On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> > Hi maxime,
> > 
> > On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > > HDMI cable right in the middle of the first Wifi channel.
> > > 
> > > Add a property to our HDMI controller, that could be reused by other
> > > similar HDMI controllers, to allow the OS to take whatever measure is
> > > necessary to avoid that crosstalk.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > 
> > > ---
> > > 
> > > Changes from v1:
> > >   - Renamed the property
> > >   - Split it into a separate patch
> > > ---
> > >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > > index 03a76729d26c..7ce06f9f9f8e 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
> > >  
> > > +  wifi-2.4ghz-coexistence:
> > 
> > I see you already renamed the property, but I can't seem to find v1 of the
> > series online.
> 
> I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
> https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/
> 
> > Sorry if this is redundant:
> > 
> > I wonder if it'd make sense to prefix the property like this:
> > "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> > with generic properties, and also thought it was a rule. Although I may have as
> > well imagined it.
> 
> Rob in the first iteration asked for the opposite :)

Fair enough, then:

Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 2213 bytes --]

On Thu, 2020-10-29 at 19:07 +0100, Maxime Ripard wrote:
> Hi Nicolas,
> 
> On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> > Hi maxime,
> > 
> > On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > > HDMI cable right in the middle of the first Wifi channel.
> > > 
> > > Add a property to our HDMI controller, that could be reused by other
> > > similar HDMI controllers, to allow the OS to take whatever measure is
> > > necessary to avoid that crosstalk.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > 
> > > ---
> > > 
> > > Changes from v1:
> > >   - Renamed the property
> > >   - Split it into a separate patch
> > > ---
> > >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > > index 03a76729d26c..7ce06f9f9f8e 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
> > >  
> > > +  wifi-2.4ghz-coexistence:
> > 
> > I see you already renamed the property, but I can't seem to find v1 of the
> > series online.
> 
> I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
> https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/
> 
> > Sorry if this is redundant:
> > 
> > I wonder if it'd make sense to prefix the property like this:
> > "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> > with generic properties, and also thought it was a rule. Although I may have as
> > well imagined it.
> 
> Rob in the first iteration asked for the opposite :)

Fair enough, then:

Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

Regards,
Nicolas


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 2213 bytes --]

On Thu, 2020-10-29 at 19:07 +0100, Maxime Ripard wrote:
> Hi Nicolas,
> 
> On Thu, Oct 29, 2020 at 06:43:27PM +0100, Nicolas Saenz Julienne wrote:
> > Hi maxime,
> > 
> > On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> > > The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> > > 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> > > HDMI cable right in the middle of the first Wifi channel.
> > > 
> > > Add a property to our HDMI controller, that could be reused by other
> > > similar HDMI controllers, to allow the OS to take whatever measure is
> > > necessary to avoid that crosstalk.
> > > 
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > > 
> > > ---
> > > 
> > > Changes from v1:
> > >   - Renamed the property
> > >   - Split it into a separate patch
> > > ---
> > >  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > > index 03a76729d26c..7ce06f9f9f8e 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
> > >  
> > > +  wifi-2.4ghz-coexistence:
> > 
> > I see you already renamed the property, but I can't seem to find v1 of the
> > series online.
> 
> I realized I didn't put you in Cc for the first version, sorry, you'll find it here:
> https://lore.kernel.org/dri-devel/20200925130744.575725-1-maxime@cerno.tech/
> 
> > Sorry if this is redundant:
> > 
> > I wonder if it'd make sense to prefix the property like this:
> > "raspberrypi,wifi-2.4ghz-coexistence." I tend to associate the lack of prefix
> > with generic properties, and also thought it was a rule. Although I may have as
> > well imagined it.
> 
> Rob in the first iteration asked for the opposite :)

Fair enough, then:

Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>

Regards,
Nicolas


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Rob Herring]

On Thu, 29 Oct 2020 14:40:16 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Rob Herring]

On Thu, 29 Oct 2020 14:40:16 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence

[Rob Herring]

On Thu, 29 Oct 2020 14:40:16 +0100, Maxime Ripard wrote:
> The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing
> 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the
> HDMI cable right in the middle of the first Wifi channel.
> 
> Add a property to our HDMI controller, that could be reused by other
> similar HDMI controllers, to allow the OS to take whatever measure is
> necessary to avoid that crosstalk.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Renamed the property
>   - Split it into a separate patch
> ---
>  .../devicetree/bindings/display/brcm,bcm2711-hdmi.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 3881 bytes --]

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@cerno.tech>
> 
> ---
> 
> 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@suse.de>

> +	 */
> +	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 #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Thomas Zimmermann]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3881 bytes --]

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@cerno.tech>
> 
> ---
> 
> 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@suse.de>

> +	 */
> +	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 #1.1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3881 bytes --]

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@cerno.tech>
> 
> ---
> 
> 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@suse.de>

> +	 */
> +	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 #1.1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

On Thu, Nov 19, 2020 at 10:20:25AM +0100, Thomas Zimmermann wrote:
> 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@cerno.tech>
> > 
> > ---
> > 
> > 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...'

This was definitely a question, I've added the question mark and applied
the two first patches

> Assuming that the display mode still works
> 
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3849 bytes --]

On Thu, Nov 19, 2020 at 10:20:25AM +0100, Thomas Zimmermann wrote:
> 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@cerno.tech>
> > 
> > ---
> > 
> > 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...'

This was definitely a question, I've added the question mark and applied
the two first patches

> Assuming that the display mode still works
> 
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>

Thanks!
Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 3849 bytes --]

On Thu, Nov 19, 2020 at 10:20:25AM +0100, Thomas Zimmermann wrote:
> 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@cerno.tech>
> > 
> > ---
> > 
> > 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...'

This was definitely a question, I've added the question mark and applied
the two first patches

> Assuming that the display mode still works
> 
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>

Thanks!
Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
> crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
> maneuvers.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Changed the property name

Applied for next. Thanks!


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 375 bytes --]

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
> crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
> maneuvers.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Changed the property name

Applied for next. Thanks!


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies

[Nicolas Saenz Julienne]

[-- Attachment #1.1: Type: text/plain, Size: 375 bytes --]

On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote:
> The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
> crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
> maneuvers.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> ---
> 
> Changes from v1:
>   - Changed the property name

Applied for next. Thanks!


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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