Hi, Frank:
Frank Wunderlich frank-w@public-files.de 於 2021年7月6日 週二 下午7:54寫道：
Hi Daniel
Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr Von: "Daniel Vetter" daniel@ffwll.ch An: "Frank Wunderlich" frank-w@public-files.de Cc: "Maarten Lankhorst" maarten.lankhorst@linux.intel.com, "Maxime Ripard" mripard@kernel.org, "Thomas Zimmermann" tzimmermann@suse.de, "David Airlie" airlied@linux.ie, "Daniel Vetter" daniel@ffwll.ch, 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:
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 dafna.hirschfeld@collabora.com Date: Tue Mar 30 13:09:02 2021 +0200
drm/mediatek: Don't support hdmi connector creationwhich 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)
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?
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