[Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Hans de Goede]

Hi,

On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/1/21 4:43 PM, Hans de Goede wrote:
>>>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>>>> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
>>>> Predia Basic tablet would no longer properly light up after reboot.
>>>>
>>>> The backlight still turns back on after reboot, but the LCD shows an
>>>> all black display. The display is also all black during the time that
>>>> EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
>>>>
>>>> In this scenario the panel is initialized so that it appears to be working
>>>> and the fastboot code skips doing a modeset. Forcing a modeset by doing a
>>>> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
>>>> /sys/class/graphics/fb0/blank causes the panel to work again.
>>>>
>>>> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
>>>> a no-op when set; and set this on vlv/chv devices when a DSI panel is
>>>> detected, to work around this.
>>>>
>>>> Admittedly this is a bit of a big hammer, but these platforms have been
>>>> around for quite some time now and they have always worked fine without
>>>> the new behavior to shutdown everything on shutdown/reboot. This approach
>>>> simply disables the recently introduced new shutdown behavior in this
>>>> specific case where it is known to cause problems. Which is a nice and
>>>> simple way to deal with this.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>>
>>> Ping? Since sending this patch I've been seeing the issue addressed by
>>> this on variour other CHT based devices too.
>>>
>>> So we have various devices suffering from a black screen after reboot
>>> now. This is pretty serious usability regression.
>>>
>>> As such it would be good to get this reviewed, or another fix proposed.
>>
>> For the quirks we try to limit them to very specific vendor and model ids,
>> so I wonder if it would be possible to get this information in here instead
>> to all the vlv with dsi...
>>
>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>
>> Jani?
>> Ville?
> 
> We need to figure out why the panel doesn't start up again.

Note it is the GOP which fails to light it up again. I think we turn something
off, which after a power-on-reset is on, so the GOP expects it to be on.

> If it has
> problems with this then surely it also fails if we just happen to reboot
> with the panel already off?

I would assume so, yes, but that only happens on say a "reboot --force"
over ssh, while the screen is off. Which are rather exceptional circumstances.

Where as just a regular reboot is quite normal and now results in a black
screen. And recovery of this condition by a normal user involves a
power-cycle by pressing the power-button for 10 seconds (these are tablets
so the force-power-off time is quite long), which most users don't even know
they can do...

> Oh a modeset fixes it? Then I guess it's just fastboot fail due to DSI
> code being crap?

This is not a fastboot issue, if I make the grub menu show every boot,
the grub-menu is also all black, as the GOP fails to properly initialize
the panel when this happens fastboot just inherits this condition.

Assuming that we want to have the EFI gfx/console work on reboot
(for say the grub menu), then disabling fastboot is not going to help.

Also note that the Windows boot-splash with the circling dots uses the
efifb, so rebooting into Windows also leads to a blackscreen at least
until Windows has booted all the way. Note I have not tried Windows,
so I don't know if Windows will recover from the black screen once
its gfx driver loads, or if it stays black then too.

> If no one is willing to fix it then I guess we just
> need to disable fastboot for DSI somehow.

See above, this is a GOP issue, so there is nothing for us to fix,
what we need to do is stop leaving the hw in a state which the GOP
cannot deal with. Which leads me to believe that we just need to disable
the "graceful shutdown" on the combination of DSI + BYT/CHT.

Regards,

Hans