Re: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)

Hi, Frank:

Frank Wunderlich [off-list ref] 於 2021年7月6日 週二 下午7:54寫道：

Hi Daniel

quoted

Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
Von: "Daniel Vetter" [off-list ref]
An: "Frank Wunderlich" [off-list ref]
Cc: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>, "Maxime Ripard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "David Airlie" <redacted>, "Daniel Vetter" <redacted>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, "Chun-Kuang Hu" <chunkuang.hu@kernel.org>, "Philipp Zabel" <p.zabel@pengutronix.de>, linux-mediatek@lists.infradead.org, "Matthias Brugger" <matthias.bgg@gmail.com>
Betreff: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)

On Tue, Jul 06, 2021 at 11:54:39AM +0200, Frank Wunderlich wrote:

quoted

Hi,

i've noticed that HDMI is broken at least on my board (Bananapi-r2,mt7623) on 5.13.

after some research i noticed that it is working till

commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b
Author: Dafna Hirschfeld [off-list ref]
Date:   Tue Mar 30 13:09:02 2021 +0200

    drm/mediatek: Don't support hdmi connector creation


which is the last of mtk-drm-next-5.13 [1] so i guess a problem with core-patches

dmesg shows the following:

[    7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (ops mtk_dis
p_ovl_component_ops)
[    7.080330] mediatek-drm mediatek-drm.1.auto: bound 14008000.rdma (ops mtk_di
sp_rdma_component_ops)
[    7.089429] mediatek-drm mediatek-drm.1.auto: bound 1400b000.color (ops mtk_d
isp_color_component_ops)
[    7.098689] mediatek-drm mediatek-drm.1.auto: bound 14012000.rdma (ops mtk_di
sp_rdma_component_ops)
[    7.107814] mediatek-drm mediatek-drm.1.auto: bound 14014000.dpi (ops mtk_dpi
_component_ops)
[    7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 because com
ponent 9 is disabled or missing
....
[   38.403957] Console: switching to colour frame buffer device 160x64
[   48.516398] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[   48.516422] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:cr
tc-0] commit wait timed out
[   58.756384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[   58.756399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:
32:HDMI-A-1] commit wait timed out
[   68.996384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[   68.996399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:33:p
lane-0] commit wait timed out
[   68.996423] [drm:mtk_drm_crtc_atomic_begin] *ERROR* new event while there is
still a pending event
[   69.106385] ------------[ cut here ]------------
[   69.106392] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:151
1 drm_atomic_helper_wait_for_vblanks.part.0+0x2a0/0x2a8
[   69.106414] [CRTC:41:crtc-0] vblank wait timed out

so i guess the breaking commit may be this:

$ git logone -S"drm_crtc_commit_wait" -- drivers/gpu/drm/
b99c2c95412c 2021-01-11 drm: Introduce a drm_crtc_commit_wait helper

in drivers/gpu/drm/drm_atomic{,_helper}.c

but i cannot confirm it because my git bisect does strange things (after
defining 5.13 as bad and the 2e4773915223 as good, second step is before
the good commit till the end, last steps are 5.11...). sorry, i'm still
new to bisect.

drm history runs in parallel with the main tree, so occasionally the
version that's reported as baseline is confusing and older than what you
might expect. Just trust git bisect, it's doing the right thing, and make
sure you test exactly the kernel you're supposed to test. Compiling with
CONFIG_LOCALVERSION_AUTO helps a lot to make sure you're really booting
into the right sha1.

my build-script adds sha1 to filename (for tftp-usage) and kernelinfo (uname -a)

quoted

quoted

the fix is targeting to 5.12-rc2, is guess because CK Hu's tree is based
on this...but the fix was not included in 5.12-rc2 (only after
5.12.0...got it by merging 5.12.14)

Yeah that can also happen because of all the non-linear trees involved in
linux development.

how to find the real breaking commit?

quoted

quoted

maybe you can help me?

So now I'm confused, you're talking about a fix, or is it still broken in
latest upstream?
-Daniel

it is still broken, as i did not found the root cause...only a guess based on errors in dmesg...git bisect points me afair to mt76 wifi-driver which is completely unrelated...as i said, the fix i defined as "last good" was no more there after 2nd bisect step.

The fix i set as last good was fixing 5.12 issue (handling connector/creating bridge without it), but 5.13 has a new one (atomic timeout,drivers/gpu/drm/drm_atomic{,_helper}.c) which i cannot trace to the breaking commit.

I think you have done many experiment [1] and you bisect between
2e4773915223 (good) and be18cd1fcae2 (bad), and you are confused by
merge commit.
You may refer to [2] and it may help you to understand git bisect.

[1] http://forum.banana-pi.org/t/bpi-r2-hdmi-4k-tv-fail/12307/4
[2] https://stackoverflow.com/questions/17267816/git-bisect-with-merged-commits

Regards,
Chun-Kuang.

regards Frank

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek