| Message ID | 20201029134018.1948636-1-maxime@cerno.tech |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [v2,1/3] dt-bindings: display: Add a property to deal with WiFi coexistence | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/dt-meta-schema | success |
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
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
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
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>
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; >
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
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!
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
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(+)