Hi Martin,
What kind of panel does Galaxy Note 10.1 use? I guess it uses I80 panel which needs CPU-trigger. If so, you may need to check if the panel device works correctly after booting because FIMD will incur vsync timeout if the panel doesn't work. I think you could try to check if te signal works or not in exynos_dsi_te_irq_handler function of exynos_drm_dsi.c
Thanks, Inki Dae
2022년 5월 27일 (금) 오전 8:34, Martin Jücker martin.juecker@gmail.com님이 작성:
Hello again,
I tried to dig around a bit to unearth some more information. What I'm seeing is that it works just fine in the beginning, planes are updated a couple of times and suddenly, after one of the plane updates, the interrupt handler in the FIMD driver is no longer called. The screen goes dark but the device is still operational, e.g. ADB works fine, I can connect and execute commands.
Trying to figure out what is called when and curious about the state of the registers, I littered the code with print statements and it looks like vsync is still active, no other code calls into disabling it. All registers are as expected, e.g. VIDINTCON0 has the interrupt bit set. I also had a look at the interrupt combiner, this too has the corresponding lcd0-1 interrupt enabled at all times and there is no interrupt pending, even after FIMD stopped receiving them.
Looking at the wiki at https://exynos.wiki.kernel.org/todo_tasks I found issue #9. It's about trashed display or DMA freeze if planes are too narrow and I was wondering if this could be related. So I had a look at the drm debug output and planes are indeed getting very small. This happens exactly when the animation that is triggering the issue is playing, so this would match. Looking a bit closer at the position and size of the planes, I could see that the last working vsync was right after one of the planes was exactly 1 pixel in width and vsync only stopped working one update later. Here are the plane updates from the logs:
Planes getting smaller and smaller with each update: plane : offset_x/y(0,0), width/height(4,800) plane : offset_x/y(4,0), width/height(1276,800) plane : offset_x/y(0,0), width/height(1280,800) plane : offset_x/y(0,776), width/height(1280,24)
plane : offset_x/y(0,0), width/height(2,800) plane : offset_x/y(2,0), width/height(1278,800) plane : offset_x/y(0,0), width/height(1280,800) plane : offset_x/y(0,776), width/height(1280,24)
plane : offset_x/y(0,0), width/height(1,800) plane : offset_x/y(1,0), width/height(1279,800) plane : offset_x/y(0,0), width/height(1280,800) plane : offset_x/y(0,776), width/height(1280,24)
Still got a vsync in between those two. But after the following update, it's dead: plane : offset_x/y(0,0), width/height(1280,800) plane : offset_x/y(0,0), width/height(1280,24) plane : offset_x/y(0,740), width/height(1280,60) plane : offset_x/y(0,0), width/height(1280,800)
-> vsync timeout comes here
I have no idea how to analyze this further on the kernel side. I'll try to write an executable that triggers this bug next. If you have any ideas on that, I'd be very grateful.
Kind Regards Martin
On Sun, May 22, 2022 at 12:06:39PM +0200, Martin Jücker wrote:
On Sun, May 22, 2022 at 09:45:51AM +0200, Krzysztof Kozlowski wrote:
On 22/05/2022 02:02, Martin Jücker wrote:
Hello,
I'm trying to get Android 12 up and running on my Galaxy Note 10.1 which is based on Exynos 4412 with a Mali GPU. For Android 11, I had no issues with graphics but after upgrading and building Android 12, I'm getting a vblank wait timeout shortly after starting the device setup, which in turn leads to my display turning black and SurfaceFlinger hanging. This can be reliably reproduced after every reboot, so much so that it's basically always on the exact same step of the setup.
I'm using the following setup:
- 5.10.101 Android Common Kernel with some patches to get
the Note 10.1 up and running
It's Android kernel, so not upstream. It is perfectly fine to use downstream kernels, but with the issues you also go to downstream folks. I have no clue what Android did to Exynos.
Hi Krzysztof,
indeed, that was my mistake. Should have done that on mainline first.
I rebased some patches on top of v5.17.9 and tried again, same result. There are no Android patches in there, only p4note related things. You can have a look here:
https://github.com/Viciouss/linux/commits/v5.17.9-android
The behaviour is exactly the same, as soon as I try to advance in the setup process, it suddenly turns the screen all black.
Here is the warning again, just in case there are any differences.
[ 77.651495] ------------[ cut here ]------------ [ 77.651527] WARNING: CPU: 2 PID: 8 at ../drivers/gpu/drm/drm_atomic_helper.c:1530 drm_atomic_helper_wait_for_vblanks.part.1+0x2b0/0x2b4 [ 77.651593] [CRTC:49:crtc-0] vblank wait timed out [ 77.651608] Modules linked in: s5p_mfc s5p_jpeg v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common rfcomm kheaders hidp hci_uart cpufreq_userspace cpufreq_powersave cpufreq_conservative btbcm brcmfmac brcmutil bnep bluetooth atmel_mxt_ts [ 77.651789] CPU: 2 PID: 8 Comm: kworker/u8:0 Not tainted 5.17.9+ #3 [ 77.651813] Hardware name: Samsung Exynos (Flattened Device Tree) [ 77.651828] Workqueue: events_unbound commit_work [ 77.651858] Backtrace: [ 77.651874] dump_backtrace from show_stack+0x20/0x24 [ 77.651915] r7:c071097c r6:00000000 r5:c10ec66c r4:600f0013 [ 77.651926] show_stack from dump_stack_lvl+0x48/0x54 [ 77.651958] dump_stack_lvl from dump_stack+0x18/0x1c [ 77.651986] r5:c113dcf4 r4:c1d51e04 [ 77.651996] dump_stack from __warn+0x18c/0x190 [ 77.652030] __warn from warn_slowpath_fmt+0x80/0xbc [ 77.652070] r9:00000009 r8:c071097c r7:000005fa r6:c113dcf4 r5:c1d8cb40 r4:c113e338 [ 77.652081] warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.1+0x2b0/0x2b4 [ 77.652123] r9:00000001 r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:c398c800 [ 77.652135] drm_atomic_helper_wait_for_vblanks.part.1 from drm_atomic_helper_commit_tail_rpm+0x6c/0x7c [ 77.652175] r10:c14cce68 r9:c1c2a005 r8:00000000 r7:0e3f351d r6:00000012 r5:c398c000 [ 77.652188] r4:d42943c0 [ 77.652197] drm_atomic_helper_commit_tail_rpm from commit_tail+0xb8/0x1d8 [ 77.652228] r5:00000000 r4:d42943c0 [ 77.652238] commit_tail from commit_work+0x1c/0x20 [ 77.652274] r10:c1518d20 r9:c1c2a005 r8:00000000 r7:c1c2a000 r6:c1c0a800 r5:c1c08a00 [ 77.652287] r4:d42943ec [ 77.652297] commit_work from process_one_work+0x1b0/0x528 [ 77.652324] process_one_work from worker_thread+0x54/0x4d8 [ 77.652356] r10:c1c0a800 r9:00000088 r8:c1403d00 r7:c1c0a81c r6:c1c08a18 r5:c1c0a800 [ 77.652368] r4:c1c08a00 [ 77.652378] worker_thread from kthread+0x104/0x134 [ 77.652419] r10:00000000 r9:c1d43e5c r8:c1d05880 r7:c1d8cb40 r6:c1c08a00 r5:c015530c [ 77.652432] r4:c1d05700 [ 77.652441] kthread from ret_from_fork+0x14/0x2c [ 77.652468] Exception stack(0xc1d51fb0 to 0xc1d51ff8) [ 77.652488] 1fa0: 00000000 00000000 00000000 00000000 [ 77.652509] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 77.652528] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 77.652550] r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c015da78 r4:c1d05700 [ 77.652561] ---[ end trace 0000000000000000 ]---
Kind Regards Martin
Best regards, Krzysztof