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
