alanbork
commented
3 years ago did this ever get fixed?
Closed rhildinger closed 1 year ago
alanbork
commented
3 years ago did this ever get fixed?
Bibinoo
commented
3 years ago Hi, I have the same issue unfortunatelly. I has never happened with the September 2020 firmwate but after installing the last one 3rd Dec 2020 I have this crashes as well with :
[165973.223398] WARNING: CPU: 0 PID: 1075 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
[165973.223404] Firmware transaction timeout
[165973.223410] Modules linked in: rfcomm tun fuse veth xt_conntrack nf_conntrack_netlink br_netfilter bridge binfmt_misc overlay bnep hci_uart btbcm bluetooth ecdh_generic ecc ipt_REJECT nf_reject_ipv4 xt_owner nft_counter 8021q garp stp llc nft_chain_nat xt_nat xt_tcpudp xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat nf_tables nfnetlink brcmfmac brcmutil v3d sha256_generic gpu_sched cfg80211 bcm2835_codec(C) i2c_bcm2835 rfkill sg v4l2_mem2mem raspberrypi_hwmon bcm2835_v4l2(C) vc4 bcm2835_isp(C) bcm2835_mmal_vchiq(C) cec videobuf2_dma_contig vc_sm_cma(C) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common drm_kms_helper videodev snd_bcm2835(C) mc drm drm_panel_orientation_quirks snd_soc_core rpivid_mem snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd syscopyarea sysfillrect sysimgblt fb_sys_fops backlight gpio_fan uio_pdrv_genirq uio i2c_dev ip_tables x_tables ipv6
[165973.223897] CPU: 0 PID: 1075 Comm: InputThread Tainted: G C 5.10.4-v7l+ #1387
[165973.223901] Hardware name: BCM2711
[165973.223906] Backtrace:
[165973.223918] [
I have no c;lue how to fix this. And it happens each time I run a video on Youtube. Very weird My Xsession is totally frozen and I need to reboot the RPI. Might be another solution but need to figure out ...
aromanro
commented
3 years ago Hi,
I have a similar issue, reproduced on both compute module 3 and 3+.
It's for a custom DSI panel with 4 lanes, kms vc4:
Jan 19 17:02:55 raspberrypi kernel: [ 8.491571] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
Jan 19 17:02:55 raspberrypi kernel: [ 8.501716] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.502085] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.771856] HG_LTP08_lcd_driver: loading out-of-tree module taints kernel.
Jan 19 17:02:55 raspberrypi kernel: [ 8.772984] Probing!
Jan 19 17:02:55 raspberrypi kernel: [ 8.785852] Backlight pin set to 28
Jan 19 17:02:55 raspberrypi kernel: [ 8.791585] Reset pin set to 13
Jan 19 17:02:55 raspberrypi kernel: [ 8.796824] DSI Device init for HG_LTP08!
Jan 19 17:02:55 raspberrypi kernel: [ 8.806632] Probed!
Jan 19 17:02:55 raspberrypi kernel: [ 8.822476] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present!
Jan 19 17:02:55 raspberrypi kernel: [ 8.829375] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
Jan 19 17:02:55 raspberrypi kernel: [ 8.830486] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.830797] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.833205] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.833497] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.833734] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.834047] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.834379] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.834802] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.835052] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
Jan 19 17:02:55 raspberrypi kernel: [ 8.836167] checking generic (3eaf0000 10a800) vs hw (0 ffffffff)
Jan 19 17:02:55 raspberrypi kernel: [ 8.836182] fb0: switching to vc4drmfb from simple
Jan 19 17:02:55 raspberrypi kernel: [ 8.836947] Console: switching to colour dummy device 80x30
Jan 19 17:02:55 raspberrypi kernel: [ 8.837109] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Jan 19 17:02:55 raspberrypi kernel: [ 8.837118] [drm] Driver supports precise vblank timestamp query.
Jan 19 17:02:55 raspberrypi kernel: [ 8.839186] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
Jan 19 17:02:55 raspberrypi kernel: [ 8.853832] Preparing!
Jan 19 17:02:55 raspberrypi kernel: [ 9.796500] Enabling!
Jan 19 17:02:55 raspberrypi kernel: [ 20.316460] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed out
Jan 19 17:02:55 raspberrypi kernel: [ 20.317141] Console: switching to colour frame buffer device 100x80
Jan 19 17:02:55 raspberrypi kernel: [ 30.556485] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed out
Jan 19 17:02:55 raspberrypi kernel: [ 40.796449] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:49:DSI-1] flip_done timed out
Jan 19 17:02:55 raspberrypi kernel: [ 51.036446] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:63:plane-1] flip_done timed out
Jan 19 17:02:55 raspberrypi kernel: [ 61.276438] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed out
Jan 19 17:02:55 raspberrypi kernel: [ 61.292286] vc4-drm soc:gpu: fb0: vc4drmfb frame buffer deviceThe panel worked with older kernel versions, for example with 4.19.127-v7+ kernel that comes from a Raspbian Lite image from May 2020, but with the kernel 5.4,83-v7+ that comes with the RaspberryOS image from January 2021, it does not work anymore.
Looks like the panel device driver is probed, prepared and enabled ok, then the problem appears. The screen stays blank and eventually the panel driver is disabled.
This also might be relevant:
[ 295.509042] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:49:DSI-1] flip_done timed out
[ 305.749043] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:63:plane-1] flip_done timed out
[ 305.749579] Disabled!
[ 305.778839] Unprepare!
[ 305.924329] [drm:vc4_dsi_encoder_enable [vc4]] *ERROR* Failed to runtime PM enable on DSI1
[ 315.998968] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed out
[ 328.149019] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed out
[ 338.389065] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:49:DSI-1] flip_done timed out
[ 348.629114] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:63:plane-1] flip_done timed out
[ 358.869181] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-1] flip_done timed outProbably it's originating from:
ret = pm_runtime_get_sync(dev);from
static void vc4_dsi_encoder_enable(struct drm_encoder *encoder)I have more info on this: after changing the driver code for 5.10.y (there are some changes in there that prevented compiling it), it seems to work, so probably along the way the DSI vc4 implementation was broken and in 5.10.y is fixed.
6by9
commented
3 years ago Any discussion of DSI displays on CM3 is going a long way off topic for a thread on 4k60 on Pi4.
If you are wishing to use vc4-kms-v3d then I strongly recommend you use the rpi-5.10.y branch. rpi-5.4.y had an early version of the patches that added support for the Pi4, and they did cause some regressions with Pi0-3. 5.10 is now working pretty well on all
The backtrace from rpi_firmware_transaction is just that the firmware hasn't replied within a timeout period, typically because something else has managed to crash it. The callstack is generally meaningless.
I haven't checked 4k60 myself recently, but it was working. There were a large number of tweaks to get the HDMI state machine stable, and AFAIK it is in the most recent releases.
alanbork
commented
3 years ago By release do you mean the official image downloadable from the website , or a testing version via rpi-update? I have a copy downloaded in November that's having issues with 4k60, and I'm wondering if I need a new install from scratch, or should try rpi-update.
alanbork
commented
3 years ago anybody found a solution to this? I've personally found that 3840x2160-60 works but have yet to get 4096x2160-60 to ever show a picture using the pi4, across several different cables, pi4s, and monitors/tvs. The pi tries to display it, meaning that all the config.txt settings are probably right, but the displays don't like the signal.
6by9
commented
3 years ago I'd need to check the actual register sizes. 4096 needs a 13bit register to store the width properties, whilst 3840 fits into 12bits. Checking the vc4-kms-v3d driver, it does appear to be a 13bit register (for both width and height), but it's possible the masking is incorrect in the firmware.
4k60 support is nearly resolved for vc4-kms-v3d. I will have a very quick check of the firmware to see if there is an obvious masking error, but vc4-kms-v3d is going to be the better supported solution longer term. I don't have a display that accepts 4096x2160 @ 60Hz to test with.
Please could you dump the EDID so that I can see what configuration we end up with, even if I can't see the results. Github should take zipped attachments, or base64 encode it.
alanbork
commented
3 years ago I think that question is meant for me? I dumped both edid's for a separate bug report I posted (hard crash/lockup on recent firmware for 4096x2160): https://github.com/raspberrypi/linux/issues/4271. Sorry if that's a duplicate; though it's not obviously so: The original poster's backtrace shows he was trying 3840x and failing, so he should definitely try the newest firmware to see if it works for him.
6by9
commented
3 years ago sorry it looks like you are asking for the binary not the decoded edid?
Yes please. Accessible as (normally) /sys/class/drm/card1-HDMI-A-1/edid or /sys/class/drm/card1-HDMI-A-2/edid
alanbork
commented
3 years ago tvservice dumped edids 4k tvs.zip
I already have these archives if that will work for you. if it has to be from the /sys path that will take a little longer.
6by9
commented
3 years ago Running those through edid-decode, sonyedid
----------------
Block 0, Base EDID:
EDID Structure Version & Revision: 1.3
Vendor & Product Identification:
Manufacturer: SNY
Model: 62211
Serial Number: 16843009
Made in: week 1 of 2016
Basic Display Parameters & Features:
Digital display
Maximum image size: 95 cm x 54 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Color Characteristics:
Red : 0.6250, 0.3398
Green: 0.2802, 0.5947
Blue : 0.1552, 0.0703
White: 0.2832, 0.2978
Established Timings I & II:
DMT 0x04: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz
DMT 0x09: 800x600 60.317 Hz 4:3 37.879 kHz 40.000 MHz
DMT 0x10: 1024x768 60.004 Hz 4:3 48.363 kHz 65.000 MHz
Standard Timings:
DMT 0x23: 1280x1024 60.020 Hz 5:4 63.981 kHz 108.000 MHz
DMT 0x53: 1600x900 60.000 Hz 16:9 60.000 kHz 108.000 MHz (RB)
DMT 0x15: 1152x864 75.000 Hz 4:3 67.500 kHz 108.000 MHz
DMT 0x3a: 1680x1050 59.954 Hz 16:10 65.290 kHz 146.250 MHz
Detailed Timing Descriptors:
DTD 1: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz (952 mm x 535 mm)
Hfront 88 Hsync 44 Hback 148 Hpol P
Vfront 4 Vsync 5 Vback 36 Vpol P
DTD 2: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz (952 mm x 535 mm)
Hfront 110 Hsync 40 Hback 220 Hpol P
Vfront 5 Vsync 5 Vback 20 Vpol P
Display Product Name: 'SONY TV *00'
Display Range Limits:
Monitor ranges (GTF): 48-62 Hz V, 14-70 kHz H, max dotclock 300 MHz
Extension blocks: 1
Checksum: 0x53
----------------
Block 1, CTA-861 Extension Block:
Revision: 3
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
Native detailed modes: 0
Video Data Block:
VIC 93: 3840x2160 24.000 Hz 16:9 54.000 kHz 297.000 MHz
VIC 94: 3840x2160 25.000 Hz 16:9 56.250 kHz 297.000 MHz
VIC 95: 3840x2160 30.000 Hz 16:9 67.500 kHz 297.000 MHz
VIC 98: 4096x2160 24.000 Hz 256:135 54.000 kHz 297.000 MHz
VIC 31: 1920x1080 50.000 Hz 16:9 56.250 kHz 148.500 MHz
VIC 16: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz
VIC 20: 1920x1080i 50.000 Hz 16:9 28.125 kHz 74.250 MHz
VIC 5: 1920x1080i 60.000 Hz 16:9 33.750 kHz 74.250 MHz
VIC 19: 1280x720 50.000 Hz 16:9 37.500 kHz 74.250 MHz
VIC 4: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz
VIC 32: 1920x1080 24.000 Hz 16:9 27.000 kHz 74.250 MHz
VIC 34: 1920x1080 30.000 Hz 16:9 33.750 kHz 74.250 MHz
VIC 60: 1280x720 24.000 Hz 16:9 18.000 kHz 59.400 MHz
VIC 62: 1280x720 30.000 Hz 16:9 22.500 kHz 74.250 MHz
VIC 18: 720x576 50.000 Hz 16:9 31.250 kHz 27.000 MHz
VIC 22: 1440x576i 50.000 Hz 16:9 15.625 kHz 27.000 MHz
VIC 3: 720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz
VIC 7: 1440x480i 59.940 Hz 16:9 15.734 kHz 27.000 MHz
VIC 17: 720x576 50.000 Hz 4:3 31.250 kHz 27.000 MHz
VIC 21: 1440x576i 50.000 Hz 4:3 15.625 kHz 27.000 MHz
VIC 2: 720x480 59.940 Hz 4:3 31.469 kHz 27.000 MHz
VIC 6: 1440x480i 59.940 Hz 4:3 15.734 kHz 27.000 MHz
VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz
Audio Data Block:
Linear PCM:
Max channels: 6
Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
Supported sample sizes (bits): 24 20 16
AC-3:
Max channels: 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 640 kb/s
DTS:
Max channels: 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 1504 kb/s
Dolby Digital+:
Max channels: 8
Supported sample rates (kHz): 48 44.1
Speaker Allocation Data Block:
FL/FR - Front Left/Right
LFE1 - Low Frequency Effects 1
FC - Front Center
BL/BR - Back Left/Right
Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
Source physical address: 3.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 300 MHz
Supported Content Types:
Graphics
Photo
Cinema
Game
Extended HDMI video details:
HDMI VICs:
HDMI VIC 1: 3840x2160 30.000 Hz 16:9 67.500 kHz 297.000 MHz
HDMI VIC 2: 3840x2160 25.000 Hz 16:9 56.250 kHz 297.000 MHz
HDMI VIC 3: 3840x2160 24.000 Hz 16:9 54.000 kHz 297.000 MHz
HDMI VIC 4: 4096x2160 24.000 Hz 256:135 54.000 kHz 297.000 MHz
Video Capability Data Block:
YCbCr quantization: Selectable (via AVI YQ)
RGB quantization: Selectable (via AVI Q)
PT scan behavior: Supports both over- and underscan
IT scan behavior: Supports both over- and underscan
CE scan behavior: Always Overscanned
Colorimetry Data Block:
xvYCC601
xvYCC709
sYCC601
opYCC601
opRGB
BT2020cYCC
BT2020YCC
BT2020RGB
YCbCr 4:2:0 Video Data Block:
VIC 96: 3840x2160 50.000 Hz 16:9 56.250 kHz 297.000 MHz
VIC 97: 3840x2160 60.000 Hz 16:9 67.500 kHz 297.000 MHz
VIC 101: 4096x2160 50.000 Hz 256:135 56.250 kHz 297.000 MHz
VIC 102: 4096x2160 60.000 Hz 256:135 67.500 kHz 297.000 MHz
HDR Static Metadata Data Block:
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Hybrid Log-Gamma
Supported static metadata descriptors:
Static metadata type 1
Detailed Timing Descriptors:
DTD 3: 1920x1080i 60.000 Hz 16:9 33.750 kHz 74.250 MHz (952 mm x 535 mm)
Hfront 88 Hsync 44 Hback 148 Hpol P
Vfront 2 Vsync 5 Vback 15 Vpol P Vfront +0.5 Odd Field
Vfront 2 Vsync 5 Vback 15 Vpol P Vback +0.5 Even Field
Checksum: 0x1VIC 102: 4096x2160 60.000 Hz 256:135 67.500 kHz 297.000 MHz is listed as a YCbCr 4:2:0 only format. 4:2:0 is not supported on the Pi.
4096x2160 @ 24Hz should work and would be a useful test to confirm the width/height registers are programmed correctly.
The TCL EDID appears to say the same.
The DRM driver should have filtered out all 4:2:0 modes because it knows they aren't supported by the hardware, so have you been manually selecting them?
You can add drm/debug=0x14 to /boot/cmdline.txt (don't add any carriage returns) to get a load of debug in dmesg, which includes all the parsing of the EDID for which modes it believes the hardware (both source and sink) support.
alanbork
commented
3 years ago what do you mean by manually selecting them? I didn't add something to config.txt if that's what you mean? I used stock modetest from the drm/freedesktop project.
6by9
commented
3 years ago OK, I'll artificially load your EDID and see what the parsing is doing. If edid-decode is giving the correct decode of those EDIDs, then I don't believe 4096x2160 @ 60Hz is possible with your display wanting it as YCbCr 4:2:0 (which the Pi doesn't support).
Something odd is happening if it does allow it, as the driver does NOT set ycbcr_420_allowed on the connector, so https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_modes.c#L1184 should reject it.
alanbork
commented
3 years ago ok, turns out that the tv has a per-port setting for what edid to send, and I had not enabled hdmi 2.0 on that port. my bad. that's why my previous report and current report do not line up.
alanbork
commented
3 years ago edid after enabling hdmi 2, etc on the port the pi is plugged into.
alanbork
commented
3 years ago having fixed that we are back to where I was before:
root@raspberrypi:~# modetest | grep '#'
modetest -s 89:3840x2160-60 WORKS modetest -s 89:4096x2160-50 WORKS modetest -s 89:4096x2160-59.94 no signal, locks modetest modetest -s 89:4096x2160-60 no signal, locks modetest
6by9
commented
3 years ago I'll look at your updated EDID in a mo, but modetest with the old EDID reports modes as
Connectors:
id encoder status name size (mm) modes encoders
89 88 connected HDMI-A-1 950x540 38 88
modes:
index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
#0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
#1 4096x2160 24.00 4096 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
#2 4096x2160 23.98 4096 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
#3 3840x2160 30.00 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
#4 3840x2160 29.97 3840 4016 4104 4400 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
#5 3840x2160 25.00 3840 4896 4984 5280 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
#6 3840x2160 24.00 3840 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
#7 3840x2160 23.98 3840 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
#8 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: phsync, pvsync; type: driver
#9 1920x1080i 30.00 1920 2008 2052 2200 1080 1084 1094 1125 74250 flags: phsync, pvsync, interlace; type: driver
#10 1920x1080i 29.97 1920 2008 2052 2200 1080 1084 1094 1125 74176 flags: phsync, pvsync, interlace; type: driver
#11 1920x1080 50.00 1920 2448 2492 2640 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver
#12 1920x1080i 25.00 1920 2448 2492 2640 1080 1084 1094 1125 74250 flags: phsync, pvsync, interlace; type: driver
#13 1920x1080 30.00 1920 2008 2052 2200 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
#14 1920x1080 29.97 1920 2008 2052 2200 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
#15 1920x1080 24.00 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
#16 1920x1080 23.98 1920 2558 2602 2750 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
#17 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: driver
#18 1600x900 60.00 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver
#19 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver
#20 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, pvsync; type: driver
#21 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#22 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync, pvsync; type: driver
#23 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#24 1280x720 30.00 1280 3040 3080 3300 720 725 730 750 74250 flags: phsync, pvsync; type: driver
#25 1280x720 29.97 1280 3040 3080 3300 720 725 730 750 74176 flags: phsync, pvsync; type: driver
#26 1280x720 24.00 1280 3040 3080 3300 720 725 730 750 59400 flags: phsync, pvsync; type: driver
#27 1280x720 23.98 1280 3040 3080 3300 720 725 730 750 59341 flags: phsync, pvsync; type: driver
#28 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; type: driver
#29 800x600 60.32 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; type: driver
#30 720x576 50.00 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
#31 720x576i 25.00 720 732 795 864 576 580 586 625 13500 flags: nhsync, nvsync, interlace, dblclk; type: driver
#32 720x480 60.00 720 736 798 858 480 489 495 525 27027 flags: nhsync, nvsync; type: driver
#33 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
#34 720x480i 30.00 720 739 801 858 480 488 494 525 13514 flags: nhsync, nvsync, interlace, dblclk; type: driver
#35 720x480i 29.97 720 739 801 858 480 488 494 525 13500 flags: nhsync, nvsync, interlace, dblclk; type: driver
#36 640x480 60.00 640 656 752 800 480 490 492 525 25200 flags: nhsync, nvsync; type: driver
#37 640x480 59.94 640 656 752 800 480 490 492 525 25175 flags: nhsync, nvsync; type: driver4096x2160 @ 60 is not one of those modes
alanbork
commented
3 years ago 4096x2160 @ 60 is not one of those modes
yes, that's what I see too, before enabling hdmi 2.0. very sorry about that mistake. but after enabling it and rebooting the pi 4096x2160 @ 60 is back in the list.
alanbork
commented
3 years ago after adding the drm flag to cmdline, "modetest -s 89:4096x2160-60" gives:
trying to open device 'vc4'...done setting mode 4096x2160-60.00Hz on connectors 89, crtc 87 failed to set gamma: Function not implemented
dmesg says (but only after modetest is locked up for at least a minute):
[ 204.633524] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] ERROR [CRTC:87:crtc-0] flip_done timed out
[ 214.873435] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] ERROR [CRTC:87:crtc-0] flip_done timed out
[ 225.113356] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] ERROR [PLANE:31:plane-0] flip_done timed out
[ 226.153242] ------------[ cut here ]------------
[ 226.153280] WARNING: CPU: 2 PID: 599 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128
[ 226.153295] Firmware transaction timeout
[ 226.153309] Modules linked in: 8021q garp stp llc brcmfmac brcmutil sha256_generic cfg80211 rfkill v3d gpu_sched raspberrypi_hwmon i2c_bcm2835 bcm2835_codec(C) bcm2835_isp(C) bcm2835_v4l2(C) v4l2_mem2mem vc4 bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common cec drm_kms_helper videodev drm mc vc_sm_cma(C) drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd rpivid_mem syscopyarea sysfillrect sysimgblt fb_sys_fops backlight uio_pdrv_genirq uio nvmem_rmem i2c_dev ip_tables x_tables ipv6
[ 226.154026] CPU: 2 PID: 599 Comm: modetest Tainted: G C 5.10.27-v7l+ #1409
[ 226.154036] Hardware name: BCM2711
[ 226.154046] Backtrace:
[ 226.154076] [
6by9
commented
3 years ago The HDMI2 analyser has decided to work again, so I do have a test system :-)
Using your EDID, selecting 4096x2160@50 via modetest works. @60 doesn't by default. Add
core_freq=600
core_freq_min=600to /boot/config.txt and selecting 4096x2160@60 works.
So it looks to be an issue of the clock being slightly too low to be able to clock through the extra pixels of 4096 vs 3840.
@timg236 @popcornmix Is it worth looking again at the clock config, or do we just document that 4096x2160@60 needs an overclock?
popcornmix
commented
3 years ago What clock config do you think could help?
Does kms behave any differently? (with the 4kp60 patchset)
It may just be that the extra pixels from the 4096 width are too much for 550MHz core/hvs clock. Ideally we should filter those modes out of edid if core_freq <= 600 (or whatever we believe the minimum usable frequency is) so a user could make them available with a core_freq overclock.
6by9
commented
3 years ago I haven't tested further. I'll try full KMS with the 4k60 patches in a bit, but I suspect they'll be the same.
4096 is 6.7% more than 3840, so plausibly 586MHz. I don't recall what the clocking arrangement is now and therefore what clock frequencies are possible.
If we can determine the required conditions, then yes we can filter them out with an appropriate warning message. We already query the firmware with RPI_FIRMWARE_GET_DISPLAY_CFG to get the max pixel clock (ie whether hdmi_enable_4k60=1), so that can gain core_clock_freq checks too.
popcornmix
commented
3 years ago 4096 is 6.7% more than 3840, so plausibly 586MHz. I don't recall what the clocking arrangement is now and therefore what clock frequencies are possible.
Latest firmware sets PLLA to an integer multiple of the max of core,v3d,isp,h264,hevc. So you can specify arbitrary values, i.e. core_clock=586 will get you an accurate core clock (but you may effectively be also overclocking v3d,isp,h264,hevc).
If you don't specify over_voltage yourself you will get a default one based on the increase in clocks over default.
alanbork
commented
3 years ago Overclocking fixes the lockup - 4096x2160-60 is displayed correctly, with no tearing.
It's not a perfect solution, however, as 3840x2160-60, which was working perfectly, now has tearing. well, tearing isn't exactly the right word - it's like a fragment of the most recently flipped buffer is shown 2 frames early. see video: https://www.youtube.com/watch?v=3nhIT1MwPKg. use 25% speed to get to the "good part", and then , and . to step frame by frame.
what's happening: after swapbuffer gets called a small triangular segment of the back buffer shows up on screen immediately. because of double buffering, that full frame that the fragment came from will show up as expected after 2 more refresh cycles.
the fragment is an odd triangular cutout:
6by9
commented
3 years ago FKMS has issues with vsync synchronisation. It's not going to be fixed as vc4-kms-v3d is the better solution. 4k60 support there should be merged within a week or two - it is all working now.
Altering the core clock has shifted the timing of V3D completing vs display being rendered.
alanbork
commented
3 years ago any chance of getting early access to that kms-v3d binary blob? with my lag testing setup I could do some verification that the timing is working properly.
On Fri, Apr 16, 2021 at 10:10 AM 6by9 @.***> wrote:
FKMS has issues with vsync synchronisation. It's not going to be fixed as vc4-kms-v3d is the better solution. 4k60 support there should be merged within a week or two - it is all working now.
Altering the core clock has shifted the timing of V3D completing vs display being rendered.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/3842#issuecomment-821317015, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5MF2FEWWMWCNDVZCSDTJBVOZANCNFSM4RAJL62Q .
popcornmix
commented
3 years ago Can you build your own kernel? It's described here You'd want to build with this PR included: https://github.com/raspberrypi/linux/pull/4284
6by9
commented
3 years ago Or more technically that's a backport of the upstream commits https://patchwork.kernel.org/project/dri-devel/list/?series=466407
alanbork
commented
3 years ago I have under x86, but it's a bit beyond my enthusiasm to help out to set it up for the pi. I was hoping more for a binary file or two I could copy to /boot or whatever. But if that's too much trouble I understand.
On Fri, Apr 16, 2021 at 10:28 AM popcornmix @.***> wrote:
Can you build your own kernel? It's described here https://www.raspberrypi.org/documentation/linux/kernel/building.md You'd want to build with this PR included:
4284 https://github.com/raspberrypi/linux/pull/4284
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/3842#issuecomment-821326303, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPGZ5KMKCEMPFRHEUDAGM3TJBXSRANCNFSM4RAJL62Q .
popcornmix
commented
3 years ago You can wait. I expect it will be merged (and hence appear in rpi-update kernel) in the next week or so.
mripard
commented
3 years ago We got a lot of fixes that might fix the issue reported here, can you test if it's still there with an updated kernel? Thanks!
I'm running into an issue trying to get 4K60p output from my RPi4 to my Acer Nitro XV273K monitor. I thought this might have been the typical EDID issue that many people have run into trying to get 4K60p to work, but this appears to be more of a corner case that involves a bug in the DRM VC4 driver causing it to get stuck in a loop and eventually crash an/or restart.
The specific symptom in this case is that when I set "hdmi_enable_4kp60=1" in config.txt and reboot, the display will show the initial boot screen with the 4 raspberry pi logos and boot logs, but as soon as the VC4 driver takes over, the display goes blank and stays blank. I did eventually discover that If I wait for 8 or 9 minutes, the display does in fact come back on and show the RPi OS desktop at 4k60p. This behavior is consistent and repeatable.
Hardware list:
OS:
Steps:
Analysis: I spent most of the day yesterday trying to debug this issue. My initial thought was that this was an EDID parsing / matching issue, but after some investigation I determined that wasn't the case and that the VC4 DRM driver is selecting the appropriate modeline. After enabling the DRM debug logs in the kernel via the "drm.debug=0x14" kernel command line flag, I could see that the DRM driver is getting stuck in a loop with the following error logs popping out 30 seconds or so:
This goes on for several minutes until the VC4 DRM driver apparently crashes or restarts just past the 7 minute mark. The following backtrace is dumped at this point:
Immediately after this backtrace is dumped, the VC4 DRM driver seems to correct itself and successfully brings up the desktop at 4k60p.
I've reached the limit of my ability to debug this issue, so I need some guidance from the RPi experts...
Thanks! -Robert Hildinger