The fkms driver loaded by dtoverlay=vc4-fkms-v3d in config setup does prevent to use SMI interface for other devices

[mcukrowski]

Describe the bug
We are working on DVB-S2X HAT which uses SMI interface for hi-speed transfer of TS packets,
but it turns out our driver can't map SMI_IO resource then fkms driver is loaded while RPI connected to TV-set.
After investigation we conclude even if our driver could share SMI_IO with fkms driver, the fkms driver clears
SMI.CS=0 register in IRQ handler which disables the SMI interface - so our HAT would not receive anymore any data !
Without fkms the OpenGL is off, which reduces usability of our system

To reproduce

• uncomment
  dtoverlay=vc4-fkms-v3d
• add following overlays to enable included smi driver by following params
  dtoverlay=smi
  dtoverlay=smi-dev
• connect TV set to HDMI and reboot the RPI

In result fkms driver fails on SMI_IO request (see part of dmesg log below)

Expected behaviour
We expect the OpenGL to be enabled together with our driver which uses SMI for data transfers.
The fkms driver should not 'grab' the SMI resource for VSync signalling, because the SMI interface
becomes unusable for other specialized activities - in our case hi-speed data transfers.

Actual behaviour
So far we are commenting out the dtoverlay=vc4-fkms-v3d setting in order to use our driver to retrieve data
through SMI, but the fkms & OpenGL is off, which reduces usability of the system.

System
Raspberry Pi 3, Raspberry Pi 4

Logs
The part of log on reproduce scenario (smi & smi-dev & fkms overlays)

[ 4.083603] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 4.142089] smi-dev-bcm2835 soc:smi_dev: initialised
[ 4.195436] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.208429] bcm2835_audio soc:audio: card created with 8 channels
[ 4.291268] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.426623] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[ 4.440682] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4.498656] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 4.519050] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.519790] usbcore: registered new interface driver brcmfmac
[ 4.560149] vc4_firmware_kms fe600000.firmwarekms: can't request region for resource [mem 0xfe600000-0xfe6000ff]
[ 4.560253] [drm:vc4_ioremap_regs [vc4]] ERROR Failed to map registers: -16
[ 4.560324] [drm:vc4_fkms_bind [vc4]] ERROR Oh dear, failed to map registers
[ 4.560346] Unable to handle kernel paging request at virtual address fffffff0
[ 4.562774] pgd = (ptrval)
[ 4.565069] [fffffff0] *pgd=80000000007003, *pmd=2ff7e003, *pte=00000000
[ 4.567463] Internal error: Oops: a07 [#1] SMP ARM
[ 4.569999] Modules linked in: brcmfmac brcmutil vc4(+) sha256_generic drm_kms_helper v3d gpu_sched drm cfg80211 drm_panel_orientation_quirks snd_bcm2835(C) snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm bcm2835_smi_dev snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops rfkill raspberrypi_hwmon hwmon snd bcm2835_codec(C) i2c_bcm2835 bcm2835_v4l2(C) bcm2835_smi v4l2_mem2mem videobuf2_dma_contig bcm2835_mmal_vchiq(C) v4l2_common videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media vc_sm_cma(C) rpivid_mem uio_pdrv_genirq uio i2c_dev ip_tables x_tables ipv6

Additional context
After investigation we understand the GPU FW sets flags in SMI.CS register and signals Vsync issuing SMI IRQ, that solution has been added on request raspberrypi/firmware#67 in 2012, I think with the commit from 2012-09-16, together with the 'fake_vsync_isr' option.

[pelwell]

Perhaps you should use the real KMS driver instead - dtoverlay=vc4-kms-v3d.

[6by9]

FKMS uses the SMI interrupt to signal vflip events from the firmware to the kernel. That's the way it is.
The SMI interface hasn't been used up until now, so it was a sensible interrupt to make use of.

You could enable just the v3d node, although then mesa may have issues as there is no render node to allocate output buffers from.
Otherwise on Pi3 you can use vc4-kms-v3d instead as pelwell suggests.
The Pi4 version on 5.4 is an early patchset with issues. The latest version has been merged to the rpi-5.9.y branch.

[petiepooo]

@pelwell Please forgive my lack of deep understanding. Is there a drawback to using the real KMS driver, or would it make sense to make that one the default instead of defaulting to the fkms driver?

[6by9]

@petiepooo KMS puts the kernel in charge of all display composition. Applications such as omxplayer, raspistill/vid, PiCamera, and a number of others use the older firmware APIs to add layers to the display, and none of that works under the real KMS driver.
Rewriting them to add similar layers whilst in X is quite involved as X doesn't allow access for adding random planes (composition is done via OpenGL). Doing so at the console is less involved, but only covers a minority of use cases.

VLC can largely replaces omxplayer and uses the newer APIs.
libcamera replaces raspistill/vid, but is still relatively new.

The default for the 64bit Raspberry Pi OS is vc4-kms-v3d as OpenMAX will not be supported with 64bit userspace, and MMAL currently has issues on such systems.