On Sat, Jun 04, 2022 at 01:05:39PM +0900, Inki Dae wrote: > Hi Martin, > Hi Inki, > What kind of panel does Galaxy Note 10.1 use? I guess it uses I80 > panel which needs CPU-trigger. the Note 10.1 uses a Samsung LTL101AL01 LCD which is connected via the RGB interface. In the meantime I tried several things but to no avail. Krzysztof proposed in IRC to disable devfreq which had no effect. I compared the mainline sources with the vendor kernel, but there are no notable differences and the parts that were a bit different also didn't solve the problem when applied to mainline. I then tried to reproduce the issue, I noticed that things go wrong as soon as I get to planes that are less than 8x8 pixels. There is two different issues I can make out: 1) Active pixels are not what expected, so the plane is 1x4 pixels but only two pixels will be visible on the display 2) The screen goes dark and the vblank interrupt stops working The vblank occurs for all planes that are 1x8 or any multiple of it, so 1x16, 1x24 as well as planes bigger than 1x279 in size. This is for the primary plane. A width of two seems to be fine here. For overlay planes, the situation is worse. All planes of width one will trigger a vsync timeout. Also, planes of widths smaller 8 seem to be hit and miss, most of them don't work. The first issue with the wrong number of pixels seems to be for small planes less than 8x8 pixels that don't trigger the vsync issue but it's more difficult to find a pattern here. It looks like even numbers like 4x4, 4x6 are fine but as soon as at least one odd number is present, it will go down the drain. 5x6 for example will only display 5x5 pixels, 5x5 will display four rows of five pixels and one row with one pixel. Kind Regards Martin > 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@xxxxxxxxx>님이 작성: > > > > 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
