[PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable
Thorsten Leemhuis
regressions at leemhuis.info
Mon Jul 6 03:16:38 PDT 2026
On 6/22/26 15:23, Adam Thiede wrote:
> On 6/22/26 06:22, Gary Bisson wrote:
>> On Thu, Jun 18, 2026 at 04:06:28PM -0500, Adam Thiede wrote:
>>> On 1/20/26 05:36, Gary Bisson wrote:
>>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be
>>>> running in order to lock its PLL during its own pre-enable function.
>>>>
>>>> Without this change, the bridge gives the following error:
>>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110
>>>> sn65dsi83 14-002c: Unexpected link status 0x01
>>>> sn65dsi83 14-002c: reset the pipe
>>>> [...]
>>>
>>> This commit was part of 7.1 and caused a problem for me.
>>> I'm running postmarketOS (basically Alpine Linux) on a Lenovo C330
>>> chromebook with a Mediatek MT8173 processor.
>>> The problem: when the display on my laptop powers off (via suspend or
>>> idle,
>>> like xset dpms off) the picture does not come back when the display
>>> powers
>>> back on (from resume). The display backlight comes on and brightness is
>>> adjustable but there is no picture. The only fix is to reboot.
>>>
>>> Reverting this commit and applying it as a patch on top of 7.1
>>> addresses the
>>> issue for me.
>>>
>>> You can view the config I'm using here:
>>> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/
>>> merge_requests/8819
>>>
>>> Is there any sort of testing or other debugging info I can provide to
>>> help
>>> address this issue?
>>
>> Thanks for reporting the issue, could you share some logs? Is the driver
>> saying anything during resume? Also, what type of panel is used on that
>> chromebook?
>
> The curious thing is that there are no real logs in dmesg or /var/log/
> messages about this. This picture just fails to come back. If there are
> some kernel params I can set to get deeper logging, that would help, but
> I'm not aware of any.
>
> I think the panel is a "BOE NV116WHM-T00" - I used this command to get
> info: cat /sys/class/drm/card0-eDP-1/edid | edid-decode
>
> Output: https://termbin.com/8nbd
This looked stalled. If I'm mistaken here, please let me known; but if
no solution is in sight, should we maybe just revert the change until a
proper was found?
Ciao, Thorsten
More information about the linux-arm-kernel
mailing list