[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f0595a07-c722-4eec-88b3-a7a60142e449@leemhuis.info>
Date: Thu, 4 Dec 2025 15:44:55 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: "angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>,
Matthias Brugger <matthias.bgg@...il.com>
Cc: Evans Jahja <evansjahja13@...il.com>, linux-mediatek@...ts.infradead.org,
linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: 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
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@...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