| Message ID | trinity-e6443313-a436-4e9d-a93c-1bef1cce135d-1625736911475@3c-app-gmx-bap19 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Aw: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2) | expand |
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 >
> 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
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
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
> 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
--- 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)
Hi just a small update, added debug in the vendor-specific functions for page_flip and vblank and it seems they never get called 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