On 7/8/26 14:13, Gary Bisson wrote:
Hi Adam,
On Tue, Jul 07, 2026 at 08:25:41PM -0500, Adam Thiede wrote:
On 7/7/26 05:38, AngeloGioacchino Del Regno wrote:
On 7/7/26 10:51, Thorsten Leemhuis wrote:
On 7/7/26 04:20, CK Hu (胡俊光) wrote:
On Mon, 2026-07-06 at 12:16 +0200, Thorsten Leemhuis wrote:
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://urldefense.com/v3/__https://gitlab.postmarketos.org/
postmarketOS/pmaports/-/__;!!CTRNKA9wMg0ARbw!
jrsPDtSEUdaINzLlq92Li8gmsEBkTOxZ6WUzNHjvIN6CyOJjHiHkNSOhIRPXFTLPlaYlxU2uvryVkwjUAN9bmax5$
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://urldefense.com/v3/__https://termbin.com/8nbd__;!!
CTRNKA9wMg0ARbw!
jrsPDtSEUdaINzLlq92Li8gmsEBkTOxZ6WUzNHjvIN6CyOJjHiHkNSOhIRPXFTLPlaYlxU2uvryVkwjUAJooSyqL$
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?
It's welcome anyone to provide a revert patch,
but I would still wait for the fixup patch until 7.2-rc4.
If no fixup patch exist, then apply the revert patch.
From my understanding of things the position in the devel cycle doesn't
matter much in a case like this. To quote Linus statements from
https://www.kernel.org/doc/html/latest/process/handling-
regressions.html#on-how-quickly-regressions-should-be-fixed
"""
From 2026-01-22:
But a user complaining should basically result in an immediate fix -
possibly a "revert and rethink".
With a later clarification on 2026-01-28:
It's also worth noting that "immediate" obviously doesn't mean "right
this *second* when the problem has been reported".
But if it's a regression with a known commit that caused it, I think
the rule of thumb should generally be "within a week", preferably
before the next rc.
"""
Adam reported the problem about three weeks ago, so we are way past the
"rule of thumb" timeframe Linus set.
Ciao, Thorsten
This is a kind of odd situation here. The fix from Adam is actually
correct, as in,
the SN65DSI83 bridge gets broken without...
....but then, there's some more oddness going on: I tried to reproduce
this on my
MT8173 Elm device, but there I can resume the system just fine, and the
display is
up and running like normal?
I'm not sure what to advice here at this point - just adding some info.
Cheers,
Angelo
Angelo, would you mind sharing your config, and the details of what you're
running? It might be a configuration difference.
As a FYI here is the latest branch I tested that patch on:
https://github.com/gibsson/linux-next/commits/master-mtk/
As far as I remember suspend/resume was ok. It was tested with a
Tungsten510 SMARC SOM (MT8370) + sn65dsi83 + tm070jdhg30 display.
Both the bridge and the display are mainline, you can see that the main
change is in the defconfig where a bunch of options are changed to be
built-in (for NFS booting).
I'll try to repro against latest kernel this week and report back.
In your case, is the panel upstream as well?
Regards,
Gary
Gary, thanks for chiming in.
The machine he's referring to is using a Parade PS8640 DSI to eDP bridge: check
mt8173-elm.dtsi for (slightly) more information.
Cheers,
Angelo
