Message-ID: <ef6558a9-c44a-4c66-967c-187f260f73e1@suse.de>
Date: Fri, 29 Aug 2025 15:07:14 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Nick Bowler <nbowler@...conx.ca>, Doug Anderson <dianders@...omium.org>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 regressions@...ts.linux.dev
Subject: Re: PROBLEM: AST2500 BMC video output disabled by reboot (regression)

Hi,

it's been a while since you sent this report. I assume, the problem is 
this there?

Am 30.04.25 um 15:28 schrieb Nick Bowler:
> Hi Doug,
>
> On Mon, Apr 28, 2025 at 01:40:25PM -0700, Doug Anderson wrote:
>> On Sun, Apr 20, 2025 at 9:26■PM Nick Bowler <nbowler@...conx.ca> wrote:
>>> I recently noticed that on current kernels I lose video output from
>>> my Blackbird's AST2500 BMC after a reboot
> [...]
>>>    ce3d99c8349584bc0fbe1e21918a3ea1155343aa is the first bad commit
>>>    commit ce3d99c8349584bc0fbe1e21918a3ea1155343aa
>>>    Author: Douglas Anderson <dianders@...omium.org>
>>>    Date:   Fri Sep 1 16:39:53 2023 -0700
>>>
>>>        drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers
> [...]
>> Bleh. That's not good. If I had to guess there's some subtle bug /
>> missing timing constraint that's being triggered here. A few things to
>> try:
>>
>> 1. Add a several second delay after the call to
>> "drm_atomic_helper_shutdown()", like msleep(5000) or something like
>> that. That's kind of a shot in the dark, but it's fairly common for
>> panels to get upset if you turn them off and then turn them on again
>> too quickly. This would be my blind guess of what is happening.
> Adding msleep(5000) does nothing except that once the video turns off
> it now takes 5 seconds longer to reboot.
>
>> 2. Could you give more details about what panel you're using?
> According to the documentation I have for the machine, the video output
> of the AST2500 BMC is connected to an IT66121 HDMI transmitter.

That dmesg refers to a SIL164. I always thought these where only for 
DVI. With the IT66121, I'd expect the warning from [1] in the dmesg.

[1] 
https://elixir.bootlin.com/linux/v6.16.3/source/drivers/gpu/drm/ast/ast_main.c#L196


The ast driver doesn't do much during shutdown. Could you please 
out-comment the lines at either [2] xor [3] and report on either effect? 
These calls turn of the video chip's memory access and sync pulses. Not 
doing that might resolve the problem.

[2] 
https://elixir.bootlin.com/linux/v6.16.3/source/drivers/gpu/drm/ast/ast_mode.c#L835
[3] 
https://elixir.bootlin.com/linux/v6.16.3/source/drivers/gpu/drm/ast/ast_mode.c#L839

Best regards
Thomas

>
> Then in turn I have that connected to some generic HDMI->VGA adapter
> (PrimeCables branded).  I also tried with another much more expensive
> device (Extron DVI-RGB 200) and observe no difference in behaviour.
>
> i think these devices are working and there's just no output signal
> on the hdmi port.
>
>> Ideally it'd be great if you could say which device tree you're using too.
> Not sure how to answer this.  Do you want me to look at something
> specific in /proc/device-tree?  Or dump it somehow?
>
>> 3. Any chance you can gather the `dmesg` from a failing boot and
>> provide it somehow? Are there any errors in the logs from the failing
>> boot?
> To clarify, there is no boot failure.  There is just no video output
> after rebooting.  I can then boot Linux again by any method that works
> without being able to see the screen, and then everything is fine once
> I do that.
>
> I've attached the dmesg output (gzipped) from after such a reboot.
> Except for the order and the timestamps, the messages are identical to
> when I boot after rebooting a kernel which does not disable the video.
>
> Thanks,
>    Nick

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Powered by blists - more mailing lists