[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAq5pW8-j6UzruT=SU05QgJ1AjLXeUwASLJ3O3SVKttaMbdTXQ@mail.gmail.com>
Date: Fri, 28 Nov 2025 11:59:49 +0900
From: Evans Jahja <evansjahja13@...il.com>
To: "angelogioacchino.delregno@...labora.com" <angelogioacchino.delregno@...labora.com>
Cc: linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
matthias.bgg@...il.com, regressions@...ts.linux.dev
Subject: [REGRESSION] mt8183-kukui: dts: changes in dts caused display to no
longer initialize - Was: Re: mt8183-kukui: drm/mediatek: dts: Invalid display
hw pipeline when probing mediatek-drm
#regzbot ^introduced: e72d63fa0563f8a6e98c10fed3a9ce74dc0536e6
#regzbot monitor: https://bugzilla.kernel.org/attachment.cgi?id=308962
Hi,
There has been a regression in the dts for my system
mt8183-kukui-krane, where changes in dts/mediatek/mt8183.dtsi broke my
machine.
The display works under v6.17.9 but is broken in v6.18-rc7. I was able
to replicate / fix the issue just by using the dts from the other
version.
> On Wed, Nov 26, 2025 at 3:01 AM Evans Jahja <evansjahja13@...il.com> wrote:
> >
> > Hi,
> >
> > I have a Lenovo IdeaPad Duet Chromebook CT-X636F, detected as Mediatek
> > krane sku176 board. (mt8183-kukui-krane)
> >
> > The display failed to initialize on the mainline kernel (linux
> > 6.18-rc7). Using the same config, on stable (linux 6.17.9) the display
> > works fine.
> >
> > config: https://bugzilla.kernel.org/show_bug.cgi?id=220803
> >
> > With the system on mainline kernel, I was able to check the serial
> > console, the error on dmesg looks like this:
> >
> > [ 6.513400] mediatek-drm mediatek-drm.18.auto: Building display
> > pipeline for MMSYS 0
> > [ 6.514983] mediatek-drm mediatek-drm.18.auto: Display HW Pipeline
> > built with 9 components.
> > [ 6.515009] mediatek-drm mediatek-drm.18.auto: Invalid display hw
> > pipeline. Last component: 38 (ret=-2)
> > [ 6.524422] mediatek-drm mediatek-drm.18.auto: probe with driver
> > mediatek-drm failed with error -22
> >
> > Temporarily modifying mtk_drm_drv.c by commenting calls to
> > mtk_drm_of_ddp_path_build_one CRTC_EXT and CRTC_THIRD allows the
> > display to function even on mainline. I was also able to add some
> > logging and determine that building the HW pipeline for CRTC_MAIN
> > works, but because building CRTC_EXT fails, the entire display would
> > not initialize.
> >
I think this is the issue:
https://lkml.org/lkml/2025/9/12/1242
On Wed, Nov 26, 2025 at 2:06 PM Evans Jahja <evansjahja13@...il.com> wrote:
>
> Hi Angelo, I was able to isolate the problem further to the dts. After
> bisecting the arch/arm64/boot/dts/mediatek/ and building the dts, it
> seems like this is the first commit that introduced the issue on my
> device.
>
> commit e72d63fa0563f8a6e98c10fed3a9ce74dc0536e6 (HEAD)
> Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
> Date: Thu Jul 24 10:39:08 2025 +0200
>
> arm64: dts: mediatek: mt8183: Migrate to display controller OF graph
>
> I am linking my full bisect log here:
>
> https://bugzilla.kernel.org/attachment.cgi?id=308962&action=edit
where we're unconditionally adding mmsys_ep_ext.
The issue seems to be caused by the recent addition of CRTC_EXT on the
base mt8183
Please kindly take a look. Apologies for any mistake, this is my first issue.
Evans Jahja
Powered by blists - more mailing lists