From: Frank Wunderlich <hidden> Date: 2021-07-06 09:55:06
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.
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)
maybe you can help me?
regards Frank
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next-5.13
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: Daniel Vetter <hidden> Date: 2021-07-06 12:02:37
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 [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.
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.
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
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
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
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
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
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.
regards Frank
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
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.
From: Frank Wunderlich <hidden> Date: 2021-07-07 16:34:08
Hi,
Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr
Von: "Chun-Kuang Hu" [off-list ref]
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
Hi Frank,
On 06.07.21 11:54, 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 [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
We also encountered that warning on mt8173 device - Acer Chromebook R13. It happen after resuming from suspend to ram.
We could not find a version that works and we were not able to find the fix of the bug.
It seems like the irq isr is not called after resuming from suspend.
Please share if you have new findings regarding that bug.
Thanks,
Dafna
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.
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)
maybe you can help me?
regards Frank
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next-5.13
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: Frank Wunderlich <hidden> Date: 2021-07-08 08:01:11
Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
Von: "Dafna Hirschfeld" [off-list ref]
We also encountered that warning on mt8173 device - Acer Chromebook R13. It happen after resuming from suspend to ram.
We could not find a version that works and we were not able to find the fix of the bug.
It seems like the irq isr is not called after resuming from suspend.
Please share if you have new findings regarding that bug.
Hi,
i have not yet found a way to make the commit-history flat for running bisect without the issue of disappearing childcommits when mergecommit is out of bisect scope. so i tried to start at working 5.12.0 with mtk-drm-patches and commits from drm core (i hope i have catched them all) by cherry-picking the single commits.
c24e104c26aa 2021-06-09 drm: Lock pointer access in drm_master_release() (HEAD -> 5.12-drm)
2aa9212803a4 2021-06-08 drm: Fix use-after-free read in drm_getunique()
23b8d6c3be47 2021-04-08 treewide: Change list_sort to use const pointers
c1e987f51f06 2021-03-26 drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in drm_dp_mst_handle_up_req()
2176a9e962be 2021-04-01 drm/drm_internal.h: Remove repeated struct declaration
fc5d92c1485d 2021-04-08 drm/syncobj: use newly allocated stub fences
23a03d271e87 2021-03-29 drm/displayid: rename displayid_hdr to displayid_header
44ef605cb08f 2021-03-29 drm/displayid: allow data blocks with 0 payload length
bbdc0aefd1b5 2021-03-29 drm/edid: use the new displayid iterator for tile info
1ee4a22d671e 2021-03-29 drm/edid: use the new displayid iterator for finding CEA extension
d9b8c26b8ddf 2021-03-29 drm/edid: use the new displayid iterator for detailed modes
d9e95df8adc8 2021-03-29 drm/displayid: add new displayid section/block iterators
2dd279949358 2021-03-29 drm/displayid: add separate drm_displayid.c
bb1a3611abc1 2021-03-29 drm/edid: make a number of functions, parameters and variables const
0b18f5b98c71 2021-03-23 drm/dp_helper: Define options for FRL training for HDMI2.1 PCON
16fbc25ab84b 2021-03-25 drm/mst: Enhance MST topology logging
bb93ad6ab4e4 2021-03-26 drm: Fix 3 typos in the inline doc
27d30189b178 2021-03-22 drm/sysfs: Convert sysfs sprintf/snprintf family to sysfs_emit
04ad4ed36cf2 2021-03-18 drm: Few typo fixes
b8821cac052f 2021-03-13 drm: Add GUD USB Display driver
d3df1b84b9ff 2021-03-13 drm/probe-helper: Check epoch counter in output_poll_execute()
298372a0cda4 2021-03-13 drm/uapi: Add USB connector type
040c9022809d 2021-03-30 drm/mediatek: Don't support hdmi connector creation
7c6582b23551 2021-03-30 drm/mediatek: Switch the hdmi bridge ops to the atomic versions
b1b43d5948b2 2021-02-03 drm/mediatek: Add missing MODULE_DEVICE_TABLE()
fe5a0ff82cfb 2021-03-13 drm/mediatek: crtc: Make config-updating atomic
result: it is still working. so at least they do not break ;)
have you found any irq-related message in dmesg (i have not found any irq-error/warning-message)?
how have you traced that?
can somebody point us to the interrupts used for pageflip/vblank "requests"? in the wait-chain i do not see them,
it seems it is called asynchronous and wait only looks at a state in the completion-struct
i have the issue on bootup, i see only a purple screen instead of fbcon/xserver and the tracebacks
on serial are very annoying as they repeating every x seconds (maybe change to WARN_ONCE?).
But after a while it seems to stop.
imho we need a way to make the history (temporary) flat (remove parent-information from commits to merge) so that bisect have only a list and not a "tree"
regards Frank
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
finish_page_flip is called by mtk_crtc_ddp_irq. this seems to be set in mtk_drm_crtc_enable_vblank with mtk_ddp_comp_enable_vblank. this is called correctly
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
117 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
118 if (comp->funcs && comp->funcs->enable_vblank)
119 {
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
121 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
122 }
123 }
i see both messages, but mtk_crtc_ddp_irq is never called and so the other 2 not.
root@bpi-r2:~# dmesg | grep -i DEBUG
[ 6.433509] DEBUG: Passed mtk_drm_crtc_enable_vblank 510
[ 6.433530] DEBUG: Passed mtk_ddp_comp_enable_vblank 117
[ 6.433537] DEBUG: Passed mtk_ddp_comp_enable_vblank 121 <<<
comp->funcs->enable_vblank should be mtk_drm_crtc_enable_vblank, right?
641 static const struct drm_crtc_funcs mtk_crtc_funcs = {
642 .set_config = drm_atomic_helper_set_config,
643 .page_flip = drm_atomic_helper_page_flip,
644 .destroy = mtk_drm_crtc_destroy,
645 .reset = mtk_drm_crtc_reset,
646 .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
647 .atomic_destroy_state = mtk_drm_crtc_destroy_state,
648 .enable_vblank = mtk_drm_crtc_enable_vblank, <<<<<<<
649 .disable_vblank = mtk_drm_crtc_disable_vblank,
650 };
but it looks like a recursion:
mtk_drm_crtc_enable_vblank calls mtk_ddp_comp_enable_vblank => enable_vblank (=mtk_drm_crtc_enable_vblank), but i see the messages not repeating
mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
511 mtk_ddp_comp_enable_vblank(comp, mtk_crtc_ddp_irq, &mtk_crtc->base);
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
118 if (comp->funcs && comp->funcs->enable_vblank)
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
but params do not match...comp->funcs->enable_vblank takes 3 arguments but comp->funcs->enable_vblank has only one.something i miss here...
i guess not, but is watchdog somehow involved? i ask because i see this on reboot/poweroff:
"watchdog: watchdog0: watchdog did not stop!"
i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.12.14 too (hdmi is working there), but not 5.12.0!
that means something in drm-patches (mtk/core) breaks watchdog. maybe the recursion mentioned above?
regards Frank
Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
Von: "Dafna Hirschfeld" [off-list ref]
Hi Frank,
On 06.07.21 11:54, 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]
We also encountered that warning on mt8173 device - Acer Chromebook R13. It happen after resuming from suspend to ram.
We could not find a version that works and we were not able to find the fix of the bug.
It seems like the irq isr is not called after resuming from suspend.
Please share if you have new findings regarding that bug.
Thanks,
Dafna
finish_page_flip is called by mtk_crtc_ddp_irq. this seems to be set in mtk_drm_crtc_enable_vblank with mtk_ddp_comp_enable_vblank. this is called correctly
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
117 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
118 if (comp->funcs && comp->funcs->enable_vblank)
119 {
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
121 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
122 }
123 }
i see both messages, but mtk_crtc_ddp_irq is never called and so the other 2 not.
Yes, In my case the irq isr is also not called after resume which cause the warning
even though "enable_vblank" do get called. Don't know why is that.
No, this is a bit confusing , there are also the funcs of the components, see in file mtk_drm_ddp_comp.c
so for mt7623 it is mtk_ovl_enable_vblank.
Thanks,
Dafna
641 static const struct drm_crtc_funcs mtk_crtc_funcs = {
642 .set_config = drm_atomic_helper_set_config,
643 .page_flip = drm_atomic_helper_page_flip,
644 .destroy = mtk_drm_crtc_destroy,
645 .reset = mtk_drm_crtc_reset,
646 .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
647 .atomic_destroy_state = mtk_drm_crtc_destroy_state,
648 .enable_vblank = mtk_drm_crtc_enable_vblank, <<<<<<<
649 .disable_vblank = mtk_drm_crtc_disable_vblank,
650 };
but it looks like a recursion:
mtk_drm_crtc_enable_vblank calls mtk_ddp_comp_enable_vblank => enable_vblank (=mtk_drm_crtc_enable_vblank), but i see the messages not repeating
mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
511 mtk_ddp_comp_enable_vblank(comp, mtk_crtc_ddp_irq, &mtk_crtc->base);
113 static inline void mtk_ddp_comp_enable_vblank(struct mtk_ddp_comp *comp,
114 void (*vblank_cb)(void *),
115 void *vblank_cb_data)
116 {
118 if (comp->funcs && comp->funcs->enable_vblank)
120 comp->funcs->enable_vblank(comp->dev, vblank_cb, vblank_cb_data);
but params do not match...comp->funcs->enable_vblank takes 3 arguments but comp->funcs->enable_vblank has only one.something i miss here...
i guess not, but is watchdog somehow involved? i ask because i see this on reboot/poweroff:
"watchdog: watchdog0: watchdog did not stop!"
i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.12.14 too (hdmi is working there), but not 5.12.0!
that means something in drm-patches (mtk/core) breaks watchdog. maybe the recursion mentioned above?
regards Frank
quoted
Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
Von: "Dafna Hirschfeld" [off-list ref]
quoted
Hi Frank,
On 06.07.21 11:54, 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]
quoted
We also encountered that warning on mt8173 device - Acer Chromebook R13. It happen after resuming from suspend to ram.
We could not find a version that works and we were not able to find the fix of the bug.
It seems like the irq isr is not called after resuming from suspend.
Please share if you have new findings regarding that bug.
Thanks,
Dafna
From: Frank Wunderlich <hidden> Date: 2021-07-08 14:01:31
Gesendet: Donnerstag, 08. Juli 2021 um 14:30 Uhr
Von: "Dafna Hirschfeld" [off-list ref]
quoted
i see both messages, but mtk_crtc_ddp_irq is never called and so the other 2 not.
Yes, In my case the irq isr is also not called after resume which cause the warning
even though "enable_vblank" do get called. Don't know why is that.
quoted
comp->funcs->enable_vblank should be mtk_drm_crtc_enable_vblank, right?
No, this is a bit confusing , there are also the funcs of the components, see in file mtk_drm_ddp_comp.c
so for mt7623 it is mtk_ovl_enable_vblank.
thanks for pointing to this. in this function another struct is filled with the callback+data, and this callback seems to be called mtk_disp_ovl_irq_handler which name suggests also a irq as trigger
412 ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
413 IRQF_TRIGGER_NONE, dev_name(dev), priv);
414 if (ret < 0) {
415 dev_err(dev, "Failed to request irq %d: %d\n", irq, ret);
416 return ret;
417 }
as i don't see this error in dmesg, i guess the registration was successful. added again some debug and it looks like the interrupt callback (mtk_disp_ovl_irq_handler) is not called
[ 5.125002] DEBUG: Passed mtk_disp_ovl_probe 416 int reg:0
[ 6.344029] DEBUG: Passed mtk_drm_crtc_enable_vblank 510
[ 6.344051] DEBUG: Passed mtk_ddp_comp_enable_vblank 117
[ 6.344057] DEBUG: Passed mtk_ovl_enable_vblank 107
[ 6.344062] DEBUG: Passed mtk_ovl_enable_vblank 112
[ 6.344066] DEBUG: Passed mtk_ddp_comp_enable_vblank 121
@@ -410,6 +413,7 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)ret=devm_request_irq(dev,irq,mtk_disp_ovl_irq_handler,IRQF_TRIGGER_NONE,dev_name(dev),priv);+printk(KERN_ALERT"DEBUG: Passed %s %d int reg:%d\n",__FUNCTION__,__LINE__,ret);if(ret<0){dev_err(dev,"Failed to request irq %d: %d\n",irq,ret);returnret;
how can we trace this further? maybe watchdog related?
quoted
"watchdog: watchdog0: watchdog did not stop!"
i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.12.14 too (hdmi is working there), but not 5.12.0!
that means something in drm-patches (mtk/core) breaks watchdog. maybe the recursion mentioned above?
From: Frank Wunderlich <hidden> Date: 2021-07-08 15:31:24
Gesendet: Donnerstag, 08. Juli 2021 um 11:35 Uhr
Von: "Frank Wunderlich" [off-list ref]
i guess not, but is watchdog somehow involved? i ask because i see this on reboot/poweroff:
"watchdog: watchdog0: watchdog did not stop!"
i see this with my 5.13, 5.12-drm (5.12.0+mtk/core drm-patches) and 5.12.14 too (hdmi is working there), but not 5.12.0!
that means something in drm-patches (mtk/core) breaks watchdog. maybe the recursion mentioned above?
have to correct me: 5.12.0 shows this error too, so error not caused by drm-patches, but i guess unrelated to the possible irq issue causing hdmi not working on 5.13 (wait-for-vblank/page_flip tracebacks)
i'm not aware who is also involved in the problem, so i want to avoid send people to the wrong way :)
regards Frank
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
From: Frank Wunderlich <hidden> Date: 2021-07-09 10:02:43
Hi,
i've found it :)
hdmi-problem is caused by
commit 440147639ac79f699a4eb9811d0bc39d3cc815f4
Author: CK Hu [off-list ref]
Date: Wed Mar 17 19:17:10 2021 +0100
soc: mediatek: mmsys: Use an array for setting the routing registers
but i cannot revert it alone, but after reverting all mmsys-patches hdmi works (ovl irq-handler called)
$ git logone v5.12..v5.13-rc1 -- drivers/ | grep 'mtk\|mediatek' | grep mmsys
060f7875bd23 2021-04-05 soc: mediatek: mmsys: Add support for MT8167 SoC
1ff1270fca33 2021-03-30 soc: mediatek: mmsys: Add mt8183 mmsys routing table
440147639ac7 2021-03-17 soc: mediatek: mmsys: Use an array for setting the routing registers
ce15e7faa2fc 2021-03-17 soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
git revert 060f7875bd23 1ff1270fca33 440147639ac7 ce15e7faa2fc
and after reapplying them one-by-one it stops working on commit above (440147639ac7)
@Dafna can you confirm it solves your issue too?
btw. watchdog issue is caused by
commit bbece05c0d3a96817483e0b249ad1e302ba95117
watchdog: mtk_wdt: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem
have already contacted author
regards Frank
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi Frank,
Missatge de Frank Wunderlich [off-list ref] del dia dv., 9
de jul. 2021 a les 12:02:
Hi,
i've found it :)
hdmi-problem is caused by
commit 440147639ac79f699a4eb9811d0bc39d3cc815f4
Author: CK Hu [off-list ref]
Date: Wed Mar 17 19:17:10 2021 +0100
soc: mediatek: mmsys: Use an array for setting the routing registers
but i cannot revert it alone, but after reverting all mmsys-patches hdmi works (ovl irq-handler called)
$ git logone v5.12..v5.13-rc1 -- drivers/ | grep 'mtk\|mediatek' | grep mmsys
060f7875bd23 2021-04-05 soc: mediatek: mmsys: Add support for MT8167 SoC
1ff1270fca33 2021-03-30 soc: mediatek: mmsys: Add mt8183 mmsys routing table
440147639ac7 2021-03-17 soc: mediatek: mmsys: Use an array for setting the routing registers
ce15e7faa2fc 2021-03-17 soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
git revert 060f7875bd23 1ff1270fca33 440147639ac7 ce15e7faa2fc
and after reapplying them one-by-one it stops working on commit above (440147639ac7)
@Dafna can you confirm it solves your issue too?
btw. watchdog issue is caused by
commit bbece05c0d3a96817483e0b249ad1e302ba95117
watchdog: mtk_wdt: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem
have already contacted author
regards Frank
Hi Eric,
thanks for response, but it does not fix the issue for me. hdmi on mt7623 is DPI not DSI. There is already a mt7623 specific routing-table defined (one for DPI/HDMI and one for external=DSI/MIPI):
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_drm_drv.c#L74
maybe it can be included or compared with the "default" route?
regards Frank
Hi
i tried to convert the old routing table into the new format
@@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {.num_routes=ARRAY_SIZE(mmsys_default_routing_table),};+staticconststructmtk_mmsys_driver_datamt7623_mmsys_driver_data={+.clk_driver="clk-mt2701-mm",//leave clock as mt7623 is based on mt2701+.routes=mmsys_mt7623_routing_table,+.num_routes=ARRAY_SIZE(mmsys_mt7623_routing_table),+};+staticconststructmtk_mmsys_driver_datamt2712_mmsys_driver_data={.clk_driver="clk-mt2712-mm",.routes=mmsys_default_routing_table,
here i've left out COLOR0 and BLS because i have not found the 3rd (address) and 4th params (value) for the routing between them and edging components
this is the old route:
DDP_COMPONENT_OVL0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_BLS,
DDP_COMPONENT_DPI0,
so i guess i need:
DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN, RDMA0_MOUT_EN_COLOR0
DISP_REG_CONFIG_DISP_COLOR0_MOUT_EN, COLOR0_MOUT_EN_BLS
DISP_REG_CONFIG_DISP_BLS_MOUT_EN, BLS_MOUT_EN_DPI0
thinking OUT is right for display...it's no HDMI-in
but i'm unsure whats the difference between MOUT and SOUT
compatible for mmsys is already set to mediatek,mt7623-mmsys in arch/arm/boot/dts/mt7623n.dtsi but it's not working, i guess because color0 and bls are missing in route
any hint how to add them?
regards Frank
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Hi Eric,
thanks for response, but it does not fix the issue for me. hdmi on mt7623 is DPI not DSI. There is already a mt7623 specific routing-table defined (one for DPI/HDMI and one for external=DSI/MIPI):
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_drm_drv.c#L74
maybe it can be included or compared with the "default" route?
regards Frank
Hi
i tried to convert the old routing table into the new format
@@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {.num_routes=ARRAY_SIZE(mmsys_default_routing_table),};+staticconststructmtk_mmsys_driver_datamt7623_mmsys_driver_data={+.clk_driver="clk-mt2701-mm",//leave clock as mt7623 is based on mt2701+.routes=mmsys_mt7623_routing_table,+.num_routes=ARRAY_SIZE(mmsys_mt7623_routing_table),+};+staticconststructmtk_mmsys_driver_datamt2712_mmsys_driver_data={.clk_driver="clk-mt2712-mm",.routes=mmsys_default_routing_table,
here i've left out COLOR0 and BLS because i have not found the 3rd (address) and 4th params (value) for the routing between them and edging components
this is the old route:
DDP_COMPONENT_OVL0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_BLS,
DDP_COMPONENT_DPI0,
so i guess i need:
DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN, RDMA0_MOUT_EN_COLOR0
DISP_REG_CONFIG_DISP_COLOR0_MOUT_EN, COLOR0_MOUT_EN_BLS
DISP_REG_CONFIG_DISP_BLS_MOUT_EN, BLS_MOUT_EN_DPI0
thinking OUT is right for display...it's no HDMI-in
but i'm unsure whats the difference between MOUT and SOUT
compatible for mmsys is already set to mediatek,mt7623-mmsys in arch/arm/boot/dts/mt7623n.dtsi but it's not working, i guess because color0 and bls are missing in route
any hint how to add them?
SOUT means even though data could output to multiple sink, but could
only output to single sink at one moment. MOUT means data could output
to multiple sink at one moment.
For SOUT with 4 sink output, the value for each sink would be 0, 1, 2, 3.
For MOUT with 4 sink output, the value for each sink would be BIT(0),
BIT(1), BIT(2), BIT(3).
[1] is my original design, and it has 'mask' in struct mtk_mmsys_conn_cfg.
For SOUT with 4 sink output, the mask would be 0x3.
For MOUT with 4 sink output, the mask would be 0xf.
You could try to add back the mask.
[1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2345186
Regards,
Chun-Kuang.
From: Frank Wunderlich <hidden> Date: 2021-07-12 09:04:21
Hi,
HDMI is broken again in 5.14-rc1 (of course i have applied my patch [1])
now i've got a NULL pointer dereference
[ 21.883641] PC is at mtk_dpi_bridge_atomic_check+0x38/0x78
[ 21.889158] LR is at drm_atomic_bridge_chain_check+0x150/0x30c
"dpi" is not set correctly in mtk_dpi_bridge_atomic_check
this function is new since
commit ec8747c52434b69cea2b18068e72f051e23d3839
drm/mediatek: dpi: Add bus format negotiation
i do not see where bridge->driver_private is set, but in other function it is solved like this:
bridge_to_dpi(bridge)
this fixes the NULL-pointer dereference, and system starts to xserver, but i do not see fbcon...it looks like drm is now initialized later (~ at login prompt on serial console). i stopped lightdm and still do not see loginprompt on hdmi, so it looks like fbcon is broken
send out fix for NULL issue, but fbcon ist still unclear...but i see this in dmesg:
dmesg | grep -i fbcon
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200 video=1280x1024 console=tty1 fbcon=map:0
[ 0.000000] Unknown command line parameters: fbcon=map:0
[ 7.040167] fbcon=map:0
and no framebuffer/fb0 in dmesg
regards Frank
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210710132431.265985-1-linux@fw-web.de/
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek