Re: Reuse framebuffer after a kexec (amdgpu / efifb)

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1819 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]