Hi,
i've noticed that HDMI is broken at least on my board (Bananapi-r2,mt7623) on 5.13.
after some research i noticed that it is working till
commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b
Author: Dafna Hirschfeld <[email protected]>
Date: Tue Mar 30 13:09:02 2021 +0200
drm/mediatek: Don't support hdmi connector creation
which is the last of mtk-drm-next-5.13 [1] so i guess a problem with core-patches
dmesg shows the following:
[ 7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (ops mtk_dis
p_ovl_component_ops)
[ 7.080330] mediatek-drm mediatek-drm.1.auto: bound 14008000.rdma (ops mtk_di
sp_rdma_component_ops)
[ 7.089429] mediatek-drm mediatek-drm.1.auto: bound 1400b000.color (ops mtk_d
isp_color_component_ops)
[ 7.098689] mediatek-drm mediatek-drm.1.auto: bound 14012000.rdma (ops mtk_di
sp_rdma_component_ops)
[ 7.107814] mediatek-drm mediatek-drm.1.auto: bound 14014000.dpi (ops mtk_dpi
_component_ops)
[ 7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 because com
ponent 9 is disabled or missing
....
[ 38.403957] Console: switching to colour frame buffer device 160x64
[ 48.516398] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 48.516422] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:cr
tc-0] commit wait timed out
[ 58.756384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 58.756399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:
32:HDMI-A-1] commit wait timed out
[ 68.996384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[ 68.996399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:33:p
lane-0] commit wait timed out
[ 68.996423] [drm:mtk_drm_crtc_atomic_begin] *ERROR* new event while there is
still a pending event
[ 69.106385] ------------[ cut here ]------------
[ 69.106392] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:151
1 drm_atomic_helper_wait_for_vblanks.part.0+0x2a0/0x2a8
[ 69.106414] [CRTC:41:crtc-0] vblank wait timed out
so i guess the breaking commit may be this:
$ git logone -S"drm_crtc_commit_wait" -- drivers/gpu/drm/
b99c2c95412c 2021-01-11 drm: Introduce a drm_crtc_commit_wait helper
in drivers/gpu/drm/drm_atomic{,_helper}.c
but i cannot confirm it because my git bisect does strange things (after defining 5.13 as bad and the 2e4773915223 as good, second step is before the good commit till the end, last steps are 5.11...). sorry, i'm still new to bisect.
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
On Tue, Jul 06, 2021 at 11:54:39AM +0200, Frank Wunderlich wrote:
> Hi,
>
> i've noticed that HDMI is broken at least on my board (Bananapi-r2,mt7623) on 5.13.
>
> after some research i noticed that it is working till
>
> commit 2e477391522354e763aa62ee3e281c1ad9e8eb1b
> Author: Dafna Hirschfeld <[email protected]>
> Date: Tue Mar 30 13:09:02 2021 +0200
>
> drm/mediatek: Don't support hdmi connector creation
>
>
> which is the last of mtk-drm-next-5.13 [1] so i guess a problem with core-patches
>
> dmesg shows the following:
>
> [ 7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (ops mtk_dis
> p_ovl_component_ops)
> [ 7.080330] mediatek-drm mediatek-drm.1.auto: bound 14008000.rdma (ops mtk_di
> sp_rdma_component_ops)
> [ 7.089429] mediatek-drm mediatek-drm.1.auto: bound 1400b000.color (ops mtk_d
> isp_color_component_ops)
> [ 7.098689] mediatek-drm mediatek-drm.1.auto: bound 14012000.rdma (ops mtk_di
> sp_rdma_component_ops)
> [ 7.107814] mediatek-drm mediatek-drm.1.auto: bound 14014000.dpi (ops mtk_dpi
> _component_ops)
> [ 7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 because com
> ponent 9 is disabled or missing
> ....
> [ 38.403957] Console: switching to colour frame buffer device 160x64
> [ 48.516398] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 48.516422] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:cr
> tc-0] commit wait timed out
> [ 58.756384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 58.756399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:
> 32:HDMI-A-1] commit wait timed out
> [ 68.996384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 68.996399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:33:p
> lane-0] commit wait timed out
> [ 68.996423] [drm:mtk_drm_crtc_atomic_begin] *ERROR* new event while there is
> still a pending event
> [ 69.106385] ------------[ cut here ]------------
> [ 69.106392] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:151
> 1 drm_atomic_helper_wait_for_vblanks.part.0+0x2a0/0x2a8
> [ 69.106414] [CRTC:41:crtc-0] vblank wait timed out
>
> so i guess the breaking commit may be this:
>
> $ git logone -S"drm_crtc_commit_wait" -- drivers/gpu/drm/
> b99c2c95412c 2021-01-11 drm: Introduce a drm_crtc_commit_wait helper
>
> in drivers/gpu/drm/drm_atomic{,_helper}.c
>
> but i cannot confirm it because my git bisect does strange things (after
> defining 5.13 as bad and the 2e4773915223 as good, second step is before
> the good commit till the end, last steps are 5.11...). sorry, i'm still
> new to bisect.
drm history runs in parallel with the main tree, so occasionally the
version that's reported as baseline is confusing and older than what you
might expect. Just trust git bisect, it's doing the right thing, and make
sure you test exactly the kernel you're supposed to test. Compiling with
CONFIG_LOCALVERSION_AUTO helps a lot to make sure you're really booting
into the right sha1.
> 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
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 <[email protected]>
> Date: Tue Mar 30 13:09:02 2021 +0200
>
> drm/mediatek: Don't support hdmi connector creation
>
>
> which is the last of mtk-drm-next-5.13 [1] so i guess a problem with core-patches
>
> dmesg shows the following:
>
> [ 7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (ops mtk_dis
> p_ovl_component_ops)
> [ 7.080330] mediatek-drm mediatek-drm.1.auto: bound 14008000.rdma (ops mtk_di
> sp_rdma_component_ops)
> [ 7.089429] mediatek-drm mediatek-drm.1.auto: bound 1400b000.color (ops mtk_d
> isp_color_component_ops)
> [ 7.098689] mediatek-drm mediatek-drm.1.auto: bound 14012000.rdma (ops mtk_di
> sp_rdma_component_ops)
> [ 7.107814] mediatek-drm mediatek-drm.1.auto: bound 14014000.dpi (ops mtk_dpi
> _component_ops)
> [ 7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 because com
> ponent 9 is disabled or missing
> ....
> [ 38.403957] Console: switching to colour frame buffer device 160x64
> [ 48.516398] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 48.516422] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:cr
> tc-0] commit wait timed out
> [ 58.756384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 58.756399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:
> 32:HDMI-A-1] commit wait timed out
> [ 68.996384] [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
> [ 68.996399] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:33:p
> lane-0] commit wait timed out
> [ 68.996423] [drm:mtk_drm_crtc_atomic_begin] *ERROR* new event while there is
> still a pending event
> [ 69.106385] ------------[ cut here ]------------
> [ 69.106392] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:151
> 1 drm_atomic_helper_wait_for_vblanks.part.0+0x2a0/0x2a8
> [ 69.106414] [CRTC:41:crtc-0] vblank wait timed out
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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
> Gesendet: Donnerstag, 08. Juli 2021 um 09:22 Uhr
> Von: "Dafna Hirschfeld" <[email protected]>
> 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
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" <[email protected]>
>
> 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 <[email protected]>
>
> 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
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" <[email protected]>
>
>>
>> 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 <[email protected]>
>
>>
>> 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
>
> Gesendet: Donnerstag, 08. Juli 2021 um 14:30 Uhr
> Von: "Dafna Hirschfeld" <[email protected]>
> > 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?
> Gesendet: Donnerstag, 08. Juli 2021 um 11:35 Uhr
> Von: "Frank Wunderlich" <[email protected]>
> 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
Hi,
i've found it :)
hdmi-problem is caused by
commit 440147639ac79f699a4eb9811d0bc39d3cc815f4
Author: CK Hu <[email protected]>
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 Frank,
Missatge de Frank Wunderlich <[email protected]> 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 <[email protected]>
> 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
> Gesendet: Freitag, 09. Juli 2021 um 12:24 Uhr
> Von: "Enric Balletbo Serra" <[email protected]>
> 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
> Gesendet: Freitag, 09. Juli 2021 um 12:38 Uhr
> Von: "Frank Wunderlich" <[email protected]>
> An: "Enric Balletbo Serra" <[email protected]>
> Cc: "CK Hu" <[email protected]>, "Dafna Hirschfeld" <[email protected]>, "chunkuang Hu" <[email protected]>, "Thomas Zimmermann" <[email protected]>, "David Airlie" <[email protected]>, "linux-kernel" <[email protected]>, "Enric Balletbo i Serra" <[email protected]>, "moderated list:ARM/Mediatek SoC support" <[email protected]>, "dri-devel" <[email protected]>, "Matthias Brugger" <[email protected]>, "Collabora Kernel ML" <[email protected]>
> 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" <[email protected]>
> > 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
Hi, Frank:
Frank Wunderlich <[email protected]> 於 2021年7月9日 週五 下午7:28寫道：
>
> > Gesendet: Freitag, 09. Juli 2021 um 12:38 Uhr
> > Von: "Frank Wunderlich" <[email protected]>
> > An: "Enric Balletbo Serra" <[email protected]>
> > Cc: "CK Hu" <[email protected]>, "Dafna Hirschfeld" <[email protected]>, "chunkuang Hu" <[email protected]>, "Thomas Zimmermann" <[email protected]>, "David Airlie" <[email protected]>, "linux-kernel" <[email protected]>, "Enric Balletbo i Serra" <[email protected]>, "moderated list:ARM/Mediatek SoC support" <[email protected]>, "dri-devel" <[email protected]>, "Matthias Brugger" <[email protected]>, "Collabora Kernel ML" <[email protected]>
> > 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" <[email protected]>
> > > 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
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/[email protected]/