Hi Martin, 2022년 6월 4일 (토) 오후 8:05, Martin Jücker <martin.juecker@xxxxxxxxx>님이 작성: > > 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 Seems malfunctioning of display controller, FIMD device. > > 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. FIMD device has a limit to DMA burst size. Please see how burst size is set according to pixel format, https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/tree/drivers/gpu/drm/exynos/exynos_drm_fimd.c?h=exynos-drm-fixes#n660 I think Android platform uses XRGB888 or ARGB888 for framebuffer. In this case, the burst size - it means the minimum size that FIMD's DMA controller reads some portion of frame buffer from memory - is 16 words. So width size should be multiple of the word size. Could you align the width size of the frame buffer to multiple of 16? According to your analysis, multiple of 8 would be ok. Thanks, Inki Dae > > 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
