Hi

Am 09.12.21 um 19:17 schrieb Guilherme G. Piccoli:

Thanks again Alex! Some comments inlined below:

On 09/12/2021 15:06, Alex Deucher wrote:

quoted

Not really in a generic way.  It's asic and platform specific.  In
addition most modern displays require link training to bring up the
display, so you can't just save and restore registers.

Oh sure, I understand that. My question is more like: is there a way,
inside amdgpu driver, to save this state before taking
over/overwriting/reprogramming the device? So we could (again, from
inside the amdgpu driver) dump this pre-saved state in the shutdown
handler, for example, having the device in a "pre-OS" state when the new
kexec'ed kernel starts.

We have have been talking about reading out and storing state of active 
devices within DRM. So far nothing usable has emerged. In a distant 
future, kexec might be able to store information about the active 
framebuffer and the new kernel's simpledrm (or some other driver) could 
use it as output.

But don't hold your breath for it. It won't happen anytime soon.

Best regards
Thomas

quoted

The drivers are asic and platform specific.  E.g., the driver for
vangogh is different from renoir is different from skylake, etc.  The
display programming interfaces are asic specific.

Cool, that makes sense! But if you (or anybody here) know some of these
GOP drivers, e.g. for the qemu/qxl device, I'm just curious to
see/understand how complex is the FW driver to just put the
device/screen in a usable state.

Cheers,


Guilherme

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev