Re: Exynos vblank timeout issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux