Re: [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

[Denis Gessert]

Hi,

I found this email chain while troubleshooting why my Levovo Duet (with the MT8183 chip) would not boot using any 6.18.* kernel. 

I can confirm that on my device the current stable 6.18.8 does not boot unless I revert the commit

commit e72d63fa0563f8a6e98c10fed3a9ce74dc0536e6 (HEAD)
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
Date:   Thu Jul 24 10:39:08 2025 +0200

    arm64: dts: mediatek: mt8183: Migrate to display controller OF graph

mentioned below. With the reverted commit the device boots as intended. 

Cheers,

Denis

On 12/4/25 15:44, Thorsten Leemhuis wrote:

Lo!

Matthias, AngeloGioacchino, have you maybe looked into regression that
seems to be caused by 72d63fa0563f8 ("arm64: dts: mediatek: mt8183:
Migrate to display controller OF graph")?

Evans Jahja, just to be sure: I suppose it still happens with 6.18
final? And have you tried if reverting the change fixes this ("fix the
issue just by using the dts from the other version" might have changed
other things as well, that's why I'm asking)

Ciao, Thorsten

On 11/28/25 03:59, Evans Jahja wrote:

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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
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="">

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature