Hi Daniel
> Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> Von: "Daniel Vetter" <[email protected]>
> An: "Frank Wunderlich" <[email protected]>
> Cc: "Maarten Lankhorst" <[email protected]>, "Maxime Ripard" <[email protected]>, "Thomas Zimmermann" <[email protected]>, "David Airlie" <[email protected]>, "Daniel Vetter" <[email protected]>, [email protected], [email protected], "Chun-Kuang Hu" <[email protected]>, "Philipp Zabel" <[email protected]>, [email protected], "Matthias Brugger" <[email protected]>
> 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 <[email protected]>
> > 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)
> > 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.
regards Frank
Hi, Frank:
Frank Wunderlich <[email protected]> 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter" <[email protected]>
> > An: "Frank Wunderlich" <[email protected]>
> > Cc: "Maarten Lankhorst" <[email protected]>, "Maxime Ripard" <[email protected]>, "Thomas Zimmermann" <[email protected]>, "David Airlie" <[email protected]>, "Daniel Vetter" <[email protected]>, [email protected], [email protected], "Chun-Kuang Hu" <[email protected]>, "Philipp Zabel" <[email protected]>, [email protected], "Matthias Brugger" <[email protected]>
> > 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 <[email protected]>
> > > 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)
>
> > > 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.
>
> regards Frank
>
> _______________________________________________
> Linux-mediatek mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi, Frank:
Frank Wunderlich <[email protected]> 於 2021年7月6日 週二 下午7:54寫道：
>
> Hi Daniel
>
> > Gesendet: Dienstag, 06. Juli 2021 um 13:20 Uhr
> > Von: "Daniel Vetter" <[email protected]>
> > An: "Frank Wunderlich" <[email protected]>
> > Cc: "Maarten Lankhorst" <[email protected]>, "Maxime Ripard" <[email protected]>, "Thomas Zimmermann" <[email protected]>, "David Airlie" <[email protected]>, "Daniel Vetter" <[email protected]>, [email protected], [email protected], "Chun-Kuang Hu" <[email protected]>, "Philipp Zabel" <[email protected]>, [email protected], "Matthias Brugger" <[email protected]>
> > 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 <[email protected]>
> > > 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)
>
> > > 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi,
> Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr
> Von: "Chun-Kuang Hu" <[email protected]>
> 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.
thanks for confirming the strange behaviour is caused by merge-commit. that was i'm thinking about...if the merge-commit is not in actual bisect "tree" then all commits linked to it disappear. basicly i understand bisect (binary search - checkout a commit by splitting commits in 2 halfes and then splitting the bad half again and again till only 1 commit is detected).
Imho the simplest solution may be flatten the tree (at least from good..HEAD) by rebasing, right?
tried simple rebasing (from 5.12-rc2 sha1 ~17823 commits), but failed somewhere in usb-subsystem ;(
i guess this happens if changes made in mergecommit...also tried with --rebase-merges and --preserve-merges but all do not make the history complete flat without conflicts
set the merge itself as good is not a solution, as there are many merges and in one is the breaking commit
other examples in your link do not change current history, only give tips for merging without these merge-commits
i have git v2.25.1
btw. i have done many more experiments as public visible, reverting commits that may break (many i can't revert as they have depencies-code changed in same block after the commit to be reverted - e.g.) by reading commit-message, and adding some debug-messages in the drm_atomic_helper.c (drm_atomic_helper_wait_for_vblanks,drm_atomic_helper_wait_for_flip_done where the WARN() is done), but i have not yet nailed down the issue
> [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