From: Maxime Ripard <maxime@cerno.tech>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Tim Gover <tim.gover@raspberrypi.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
David Airlie <airlied@linux.ie>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
dri-devel@lists.freedesktop.org, Eric Anholt <eric@anholt.net>,
Rob Herring <robh+dt@kernel.org>,
bcm-kernel-feedback-list@broadcom.com,
linux-rpi-kernel@lists.infradead.org,
Daniel Vetter <daniel.vetter@intel.com>,
Frank Rowand <frowand.list@gmail.com>,
Phil Elwell <phil@raspberrypi.com>,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/3] drm/vc4: hdmi: Disable Wifi Frequencies
Date: Thu, 19 Nov 2020 15:50:27 +0100 [thread overview]
Message-ID: <20201119145027.o2vdcwjbwm6ve6sb@gilmour> (raw)
In-Reply-To: <a5af9bc2-b2f0-9a03-f436-8b18d9af7b89@suse.de>
[-- 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
next prev parent reply other threads:[~2020-11-19 15:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 13:40 [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence Maxime Ripard
2020-10-29 13:40 ` [PATCH v2 2/3] drm/vc4: hdmi: Disable Wifi Frequencies Maxime Ripard
2020-11-19 9:20 ` Thomas Zimmermann
2020-11-19 14:50 ` Maxime Ripard [this message]
2020-10-29 13:40 ` [PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies Maxime Ripard
2020-11-20 16:45 ` Nicolas Saenz Julienne
2020-10-29 17:43 ` [PATCH v2 1/3] dt-bindings: display: Add a property to deal with WiFi coexistence Nicolas Saenz Julienne
2020-10-29 18:07 ` Maxime Ripard
2020-10-29 18:16 ` Nicolas Saenz Julienne
2020-11-04 21:40 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201119145027.o2vdcwjbwm6ve6sb@gilmour \
--to=maxime@cerno.tech \
--cc=airlied@linux.ie \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=daniel.vetter@intel.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=frowand.list@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mark.rutland@arm.com \
--cc=nsaenzjulienne@suse.de \
--cc=phil@raspberrypi.com \
--cc=robh+dt@kernel.org \
--cc=tim.gover@raspberrypi.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox