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

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

[Frank Wunderlich]

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

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

[Daniel Vetter]

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

> 
> regards Frank
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next-5.13

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

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

[Frank Wunderlich]

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 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
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

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

[Chun-Kuang Hu]

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

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

[Chun-Kuang Hu]

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

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

[Frank Wunderlich]

Hi,

> Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr
> Von: "Chun-Kuang Hu" <chunkuang.hu@kernel.org>

> 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


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

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

[Dafna Hirschfeld]

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 <dafna.hirschfeld@collabora.com>
> 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
> 

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

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

[Frank Wunderlich]

> Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
> Von: "Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>
> 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

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

[Frank Wunderlich]

Hi

just a small update, added debug in the vendor-specific functions for page_flip and vblank and it seems they never get called

--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -87,21 +87,25 @@ static void mtk_drm_crtc_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
 {
        struct drm_crtc *crtc = &mtk_crtc->base;
        unsigned long flags;
-
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
        spin_lock_irqsave(&crtc->dev->event_lock, flags);
        drm_crtc_send_vblank_event(crtc, mtk_crtc->event);
        drm_crtc_vblank_put(crtc);
        mtk_crtc->event = NULL;
        spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
 }

 static void mtk_drm_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
 {
+printk(KERN_ALERT "DEBUG: Passed %s %d update:%d,needsvblank:%d\n",__FUNCTION__,__LINE__,mtk_crtc->config_updating,mtk_crtc->pending_needs_vblank);
        drm_crtc_handle_vblank(&mtk_crtc->base);
        if (!mtk_crtc->config_updating && mtk_crtc->pending_needs_vblank) {
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
                mtk_drm_crtc_finish_page_flip(mtk_crtc);
                mtk_crtc->pending_needs_vblank = false;
        }
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
 }

 static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)

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" <dafna.hirschfeld@collabora.com>

>
> 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 <dafna.hirschfeld@collabora.com>

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


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

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

[Dafna Hirschfeld]

Hi

On 08.07.21 11:35, Frank Wunderlich wrote:
> Hi
> 
> just a small update, added debug in the vendor-specific functions for page_flip and vblank and it seems they never get called
> 
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -87,21 +87,25 @@ static void mtk_drm_crtc_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
>   {
>          struct drm_crtc *crtc = &mtk_crtc->base;
>          unsigned long flags;
> -
> +printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
>          spin_lock_irqsave(&crtc->dev->event_lock, flags);
>          drm_crtc_send_vblank_event(crtc, mtk_crtc->event);
>          drm_crtc_vblank_put(crtc);
>          mtk_crtc->event = NULL;
>          spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
> +printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
>   }
> 
>   static void mtk_drm_finish_page_flip(struct mtk_drm_crtc *mtk_crtc)
>   {
> +printk(KERN_ALERT "DEBUG: Passed %s %d update:%d,needsvblank:%d\n",__FUNCTION__,__LINE__,mtk_crtc->config_updating,mtk_crtc->pending_needs_vblank);
>          drm_crtc_handle_vblank(&mtk_crtc->base);
>          if (!mtk_crtc->config_updating && mtk_crtc->pending_needs_vblank) {
> +printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
>                  mtk_drm_crtc_finish_page_flip(mtk_crtc);
>                  mtk_crtc->pending_needs_vblank = false;
>          }
> +printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
>   }
> 
>   static void mtk_drm_crtc_destroy(struct drm_crtc *crtc)
> 
> 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.

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

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
> 
> 
>> Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
>> Von: "Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>
> 
>>
>> 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 <dafna.hirschfeld@collabora.com>
> 
>>
>> 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
> 

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

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

[Frank Wunderlich]

> Gesendet: Donnerstag, 08. Juli 2021 um 14:30 Uhr
> Von: "Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>
> > 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.


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

--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -86,6 +86,7 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
 {
        struct mtk_disp_ovl *priv = dev_id;

+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
        /* Clear frame completion interrupt */
        writel(0x0, priv->regs + DISP_REG_OVL_INTSTA);

@@ -93,6 +94,7 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
                return IRQ_NONE;

        priv->vblank_cb(priv->vblank_cb_data);
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);

        return IRQ_HANDLED;
 }
@@ -102,11 +104,12 @@ void mtk_ovl_enable_vblank(struct device *dev,
                           void *vblank_cb_data)
 {
        struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
-
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
        ovl->vblank_cb = vblank_cb;
        ovl->vblank_cb_data = vblank_cb_data;
        writel(0x0, ovl->regs + DISP_REG_OVL_INTSTA);
        writel_relaxed(OVL_FME_CPL_INT, ovl->regs + DISP_REG_OVL_INTEN);
+printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
 }

 void mtk_ovl_disable_vblank(struct device *dev)
@@ -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);
                return ret;


how can we trace this further? maybe watchdog related?

> >
> > "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?


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

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

[Frank Wunderlich]

> Gesendet: Donnerstag, 08. Juli 2021 um 11:35 Uhr
> Von: "Frank Wunderlich" <frank-w@public-files.de>
> 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

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

[Frank Wunderlich]

Hi,

i've found it :)

hdmi-problem is caused by

commit 440147639ac79f699a4eb9811d0bc39d3cc815f4
Author: CK Hu <ck.hu@mediatek.com>
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

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

[Enric Balletbo Serra]

Hi Frank,

Missatge de Frank Wunderlich <frank-w@public-files.de> 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 <ck.hu@mediatek.com>
> 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)
>

If this is the offending commit, could you try if the following patch
fixes the issue for you?

https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.13-next/fixes&id=db39994e0bd852c6612a9709e63c09b98b161e00

If not, and that patch is the offending commit, it probably means that
the default routing table doesn't work for mt7623. Needs a specific
soc table.

Thanks,
  Enric.

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

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

[Frank Wunderlich]

> Gesendet: Freitag, 09. Juli 2021 um 12:24 Uhr
> Von: "Enric Balletbo Serra" <eballetbo@gmail.com>
> If this is the offending commit, could you try if the following patch
> fixes the issue for you?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.13-next/fixes&id=db39994e0bd852c6612a9709e63c09b98b161e00
>
> If not, and that patch is the offending commit, it probably means that
> the default routing table doesn't work for mt7623. Needs a specific
> soc table.

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

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

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

[Frank Wunderlich]

> Gesendet: Freitag, 09. Juli 2021 um 12:38 Uhr
> Von: "Frank Wunderlich" <frank-w@public-files.de>
> An: "Enric Balletbo Serra" <eballetbo@gmail.com>
> Cc: "CK Hu" <ck.hu@mediatek.com>, "Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>, "chunkuang Hu" <chunkuang.hu@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "David Airlie" <airlied@linux.ie>, "linux-kernel" <linux-kernel@vger.kernel.org>, "Enric Balletbo i Serra" <enric.balletbo@collabora.com>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org>, "dri-devel" <dri-devel@lists.freedesktop.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "Collabora Kernel ML" <kernel@collabora.com>
> Betreff: Aw: Re: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
>
>
> > Gesendet: Freitag, 09. Juli 2021 um 12:24 Uhr
> > Von: "Enric Balletbo Serra" <eballetbo@gmail.com>
> > If this is the offending commit, could you try if the following patch
> > fixes the issue for you?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.13-next/fixes&id=db39994e0bd852c6612a9709e63c09b98b161e00
> >
> > If not, and that patch is the offending commit, it probably means that
> > the default routing table doesn't work for mt7623. Needs a specific
> > soc table.
>
> 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

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 080660ef11bf..134dae13382f 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
        .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
 };

+static const struct mtk_mmsys_driver_data mt7623_mmsys_driver_data = {
+       .clk_driver = "clk-mt2701-mm",
+       .routes = mmsys_mt7623_routing_table,
+       .num_routes = ARRAY_SIZE(mmsys_mt7623_routing_table),
+};
+
 static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
        .clk_driver = "clk-mt2712-mm",
        .routes = mmsys_default_routing_table,
@@ -133,6 +139,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
                .compatible = "mediatek,mt2701-mmsys",
                .data = &mt2701_mmsys_driver_data,
        },
+       {
+               .compatible = "mediatek,mt7623-mmsys",
+               .data = &mt7623_mmsys_driver_data,
+       },
        {
                .compatible = "mediatek,mt2712-mmsys",
                .data = &mt2712_mmsys_driver_data,
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index 11388961dded..fd397f68339c 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -214,5 +214,14 @@ static const struct mtk_mmsys_routes mmsys_default_routing_table[] = {
                DISP_REG_CONFIG_DISP_UFOE_MOUT_EN, UFOE_MOUT_EN_DSI0,
        }
 };
-
+static const struct mtk_mmsys_routes mmsys_mt7623_routing_table[] = {
+       //HDMI
+       {
+               DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
+               DISP_REG_CONFIG_DISP_OVL_MOUT_EN, OVL_MOUT_EN_RDMA
+       }, {
+               DDP_COMPONENT_RDMA0, DDP_COMPONENT_DPI0,
+               DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN, RDMA0_SOUT_DPI0
+       }
+};
 #endif /* __SOC_MEDIATEK_MTK_MMSYS_H */
:...skipping...
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 080660ef11bf..134dae13382f 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
        .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
 };

+static const struct mtk_mmsys_driver_data mt7623_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),
+};
+
 static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
        .clk_driver = "clk-mt2712-mm",
        .routes = mmsys_default_routing_table,
@@ -133,6 +139,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
                .compatible = "mediatek,mt2701-mmsys",
                .data = &mt2701_mmsys_driver_data,
        },
+       {
+               .compatible = "mediatek,mt7623-mmsys",
+               .data = &mt7623_mmsys_driver_data,
+       },
        {
                .compatible = "mediatek,mt2712-mmsys",
                .data = &mt2712_mmsys_driver_data,
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index 11388961dded..fd397f68339c 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -214,5 +214,14 @@ static const struct mtk_mmsys_routes mmsys_default_routing_table[] = {
                DISP_REG_CONFIG_DISP_UFOE_MOUT_EN, UFOE_MOUT_EN_DSI0,
        }
 };
-
+static const struct mtk_mmsys_routes mmsys_mt7623_routing_table[] = {
+       //HDMI
+       {
+               DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
+               DISP_REG_CONFIG_DISP_OVL_MOUT_EN, OVL_MOUT_EN_RDMA
+       }, {
+               DDP_COMPONENT_RDMA0, DDP_COMPONENT_DPI0,
+               DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN, RDMA0_SOUT_DPI0
+       }
+};

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

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

[Chun-Kuang Hu]

Hi, Frank:

Frank Wunderlich <frank-w@public-files.de> 於 2021年7月9日 週五 下午7:28寫道：
>
> > Gesendet: Freitag, 09. Juli 2021 um 12:38 Uhr
> > Von: "Frank Wunderlich" <frank-w@public-files.de>
> > An: "Enric Balletbo Serra" <eballetbo@gmail.com>
> > Cc: "CK Hu" <ck.hu@mediatek.com>, "Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>, "chunkuang Hu" <chunkuang.hu@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "David Airlie" <airlied@linux.ie>, "linux-kernel" <linux-kernel@vger.kernel.org>, "Enric Balletbo i Serra" <enric.balletbo@collabora.com>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org>, "dri-devel" <dri-devel@lists.freedesktop.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "Collabora Kernel ML" <kernel@collabora.com>
> > Betreff: Aw: Re: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
> >
> >
> > > Gesendet: Freitag, 09. Juli 2021 um 12:24 Uhr
> > > Von: "Enric Balletbo Serra" <eballetbo@gmail.com>
> > > If this is the offending commit, could you try if the following patch
> > > fixes the issue for you?
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.13-next/fixes&id=db39994e0bd852c6612a9709e63c09b98b161e00
> > >
> > > If not, and that patch is the offending commit, it probably means that
> > > the default routing table doesn't work for mt7623. Needs a specific
> > > soc table.
> >
> > 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
>
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index 080660ef11bf..134dae13382f 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
>         .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
>  };
>
> +static const struct mtk_mmsys_driver_data mt7623_mmsys_driver_data = {
> +       .clk_driver = "clk-mt2701-mm",
> +       .routes = mmsys_mt7623_routing_table,
> +       .num_routes = ARRAY_SIZE(mmsys_mt7623_routing_table),
> +};
> +
>  static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
>         .clk_driver = "clk-mt2712-mm",
>         .routes = mmsys_default_routing_table,
> @@ -133,6 +139,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
>                 .compatible = "mediatek,mt2701-mmsys",
>                 .data = &mt2701_mmsys_driver_data,
>         },
> +       {
> +               .compatible = "mediatek,mt7623-mmsys",
> +               .data = &mt7623_mmsys_driver_data,
> +       },
>         {
>                 .compatible = "mediatek,mt2712-mmsys",
>                 .data = &mt2712_mmsys_driver_data,
> diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
> index 11388961dded..fd397f68339c 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.h
> +++ b/drivers/soc/mediatek/mtk-mmsys.h
> @@ -214,5 +214,14 @@ static const struct mtk_mmsys_routes mmsys_default_routing_table[] = {
>                 DISP_REG_CONFIG_DISP_UFOE_MOUT_EN, UFOE_MOUT_EN_DSI0,
>         }
>  };
> -
> +static const struct mtk_mmsys_routes mmsys_mt7623_routing_table[] = {
> +       //HDMI
> +       {
> +               DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
> +               DISP_REG_CONFIG_DISP_OVL_MOUT_EN, OVL_MOUT_EN_RDMA
> +       }, {
> +               DDP_COMPONENT_RDMA0, DDP_COMPONENT_DPI0,
> +               DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN, RDMA0_SOUT_DPI0
> +       }
> +};
>  #endif /* __SOC_MEDIATEK_MTK_MMSYS_H */
> :...skipping...
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index 080660ef11bf..134dae13382f 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -20,6 +20,12 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
>         .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
>  };
>
> +static const struct mtk_mmsys_driver_data mt7623_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),
> +};
> +
>  static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
>         .clk_driver = "clk-mt2712-mm",
>         .routes = mmsys_default_routing_table,
> @@ -133,6 +139,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
>                 .compatible = "mediatek,mt2701-mmsys",
>                 .data = &mt2701_mmsys_driver_data,
>         },
> +       {
> +               .compatible = "mediatek,mt7623-mmsys",
> +               .data = &mt7623_mmsys_driver_data,
> +       },
>         {
>                 .compatible = "mediatek,mt2712-mmsys",
>                 .data = &mt2712_mmsys_driver_data,
> diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
> index 11388961dded..fd397f68339c 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.h
> +++ b/drivers/soc/mediatek/mtk-mmsys.h
> @@ -214,5 +214,14 @@ static const struct mtk_mmsys_routes mmsys_default_routing_table[] = {
>                 DISP_REG_CONFIG_DISP_UFOE_MOUT_EN, UFOE_MOUT_EN_DSI0,
>         }
>  };
> -
> +static const struct mtk_mmsys_routes mmsys_mt7623_routing_table[] = {
> +       //HDMI
> +       {
> +               DDP_COMPONENT_OVL0, DDP_COMPONENT_RDMA0,
> +               DISP_REG_CONFIG_DISP_OVL_MOUT_EN, OVL_MOUT_EN_RDMA
> +       }, {
> +               DDP_COMPONENT_RDMA0, DDP_COMPONENT_DPI0,
> +               DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN, RDMA0_SOUT_DPI0
> +       }
> +};
>
> 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.

>
> regards Frank

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

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

[Frank Wunderlich]

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