5Ghz WiFi blocked by vc4.ko on kernel 5.10.12 on RPi4B 8GB

[Dave Stevenson]

Hi Ryutaroh

On Thu, 11 Feb 2021 at 05:52, Ryutaroh Matsumoto
<ryutaroh at ict.e.titech.ac.jp> wrote:
>
> Hi Maxime, thank you for your response.
>
> > And does fkms (or the simplefb driver at 1440p) show the same behaviour?
>
> I do not think we can use fkms by the plain upstream kernel
> (am I right?).
>
> I found that giving
>
> hdmi_enable_4kp60=1
> disable_fw_kms_setup=1
> disable_overscan=1
>
> to config.txt makes simple framebuffer to use 3840x2160 with my display
> (refresh rate unknown). With that setup, I can use 5GHz wifi but cannot use
> 2.4GHz wifi. Without hdmi_enable_4kp60=1, the output resolution is much
> lower, but usablity of WiFi remains the same.
>
> With vc4.ko, neither 2.4GHz or 5GHz passes ping packegs.
>
> In all cases, WiFi association to SSIDs can be established.
>
> Since 5GHz WiFi can only be used with module_blacklist=vc4,
> I have been blacklisting vc4.ko for a while...
>
> I am seeing the above with Debian kernel 5.10.12.

I'm not aware of an inherent problem with HDMI or vc4.ko interfering
with the Wifi. The exception is 2560x1440 at 60Hz which has a TMDS clock
of 2.415GHz, so pretty much right on top of 2.4GHz Wifi channel 1.
That's what [1] works around by slightly dropping the video pixel
clock.
The quality of HDMI leads also varies quite significantly, although
that is more generally on susceptibility rather than emissions.
Is this only on one Pi4, or multiple?

tvservice -s will tell you the mode that the firmware is running the
HDMI display at when vc4.ko isn't loaded. Normally it'll be a standard
DMT or CEA mode that you can check against CEA/CTA-861 or the DRM
variant of it at [2]. tvservice source is available at [3].
"xrandr -v" or "sudo cat /sys/kernel/debug/dri/0/state | grep mode"
would tell you the mode being used by vc4.ko. I'm expecting it to be
the same for standard resolutions.

Is this issue also seen in Raspberry Pi OS? I realise that isn't the
OS you want to run, but it's useful to isolate kernel vs distribution
issues.

[1] https://github.com/torvalds/linux/commit/9fa1d7e60ad5ad2f7859ea8912d7b0b57821a5b7#diff-3c69fdf599dc6f86651bf04984fb63fe66253d605ee1c63e1dd8b270a4556e33
[2] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_edid.c#L718
[3] https://github.com/raspberrypi/userland/

> Besides, I am also experience instability of audio device driver
> only when vc4.ko is loaded as reported at
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008007.html

Maxime is doing a sterling job of dealing with upstreaming patches to
mainline, but our focus is on our downstream vendor trees.
vc4-hdmi requires pre framed IEC958 data. ALSA can do that for you via
a plugin, but AFAIK the current upstream vc4-hdmi.conf doesn't do the
whole job. There was a fair amount of work with LibreElec to get the
config right (they're now running 7.1 high bitrate stuff as well). I
believe that is now in Raspberry Pi OS as well, but may well not be
upstreamed.

Or are you mixing and matching bcm2835-audio and the firmware driver
for the HDMI audio block with vc4.ko? That's not going to work well as
HDMI audio configuration is dependent on the video mode as well, so
they need to be controlled in tandem.

  Dave