Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Message-ID: <trinity-9886112a-f7f2-4ae8-8e09-39c73c04b751-1625571632221@3c-app-gmx-bs60>
From:   Frank Wunderlich <frank-w@public-files.de>
To:     Daniel Vetter <daniel@ffwll.ch>
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>
Subject: Aw: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
Content-Type: text/plain; charset=UTF-8
Date:   Tue, 6 Jul 2021 13:40:32 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <YOQ8ktv1MypezrEy@phenom.ffwll.local>
References: <trinity-cc8f5927-9aaf-43ae-a107-6a6229f1b481-1625565279264@3c-app-gmx-bs60>
 <YOQ8ktv1MypezrEy@phenom.ffwll.local>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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 Rip=
ard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "Dav=
id Airlie" <airlied@linux.ie>, "Daniel Vetter" <daniel@ffwll.ch>, dri-deve=
l@lists.freedesktop.org, linux-kernel@vger.kernel.org, "Chun-Kuang Hu" <ch=
unkuang.hu@kernel.org>, "Philipp Zabel" <p.zabel@pengutronix.de>, linux-me=
diatek@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,mt7=
623) 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 c=
ore-patches
> >
> > dmesg shows the following:
> >
> > [    7.071342] mediatek-drm mediatek-drm.1.auto: bound 14007000.ovl (o=
ps 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 (o=
ps mtk_dpi
> > _component_ops)
> > [    7.116338] mediatek-drm mediatek-drm.1.auto: Not creating crtc 1 b=
ecause 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_he=
lper.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 (aft=
er
> > defining 5.13 as bad and the 2e4773915223 as good, second step is befo=
re
> > the good commit till the end, last steps are 5.11...). sorry, i'm stil=
l
> > 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 mak=
e
> 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 (una=
me -a)

> > the fix is targeting to 5.12-rc2, is guess because CK Hu's tree is bas=
ed
> > 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 i=
n
> 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 i=
n
> 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/creat=
ing 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