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: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
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
OpenPGP_signature
Description: OpenPGP digital signature
