On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli <gpiccoli@xxxxxxxxxx> wrote: > > On 09/12/2021 14:31, Alex Deucher wrote: > > [...] > > Once the driver takes over, none of the pre-driver state is retained. > > You'll need to load the driver in the new kernel to initialize the > > displays. Note the efifb doesn't actually have the ability to program > > any hardware, it just takes over the memory region that was used for > > the pre-OS framebuffer and whatever display timing was set up by the > > GOP driver prior to the OS loading. Once that OS driver has loaded > > the area is gone and the display configuration may have changed. > > > > Hi Christian and Alex, thanks for the clarifications! > > Is there any way to save/retain this state before amdgpu takes over? 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. > Would simpledrm be able to program the device again, to a working state? No. You need an asic specific driver that knows how to program the specific hardware. It's also platform specific in that you need to determine platform specific details such as the number and type of display connectors and encoders that are present on the system. > > Finally, do you have any example of such a GOP driver (open source) so I > can take a look? I tried to find something like that in Tianocore > project, but didn't find anything that seemed useful for my issue. 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. Alex
