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.juec...@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
