dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	linux-fbdev@vger.kernel.org, kexec@lists.infradead.org,
	amd-gfx@lists.freedesktop.org
Cc: kernel@gpiccoli.net, kasong@redhat.com,
	"Baoquan He" <bhe@redhat.com>,
	"Samuel Iglesias Gonsálvez" <siglesias@igalia.com>,
	Xinhui.Pan@amd.com, dri-devel@lists.freedesktop.org,
	pjones@redhat.com, kraxel@redhat.com, alexander.deucher@amd.com,
	"Dave Young" <dyoung@redhat.com>,
	"Vivek Goyal" <vgoyal@redhat.com>
Subject: Re: Reuse framebuffer after a kexec (amdgpu / efifb)
Date: Thu, 9 Dec 2021 17:09:46 +0100	[thread overview]
Message-ID: <bb02d57c-d850-b319-9e76-663c0c2f8eed@amd.com> (raw)
In-Reply-To: <62aab616-53cb-ff9f-c5f3-169c547bd1ee@igalia.com>

Hi Guilherme,

Am 09.12.21 um 17:00 schrieb Guilherme G. Piccoli:
> Hi all, I have a question about the possibility of reusing a framebuffer
> after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
> a separate GPU hardware), but I guess the question is kinda generic
> hence I've looped most of the lists / people I think does make sense
> (apologies for duplicates).
>
>
> The context is: we have a hardware that has an amdgpu-controlled device
> (Vangogh model) and as soon as the machine boots, efifb is providing
> graphics - I understand the UEFI/GRUB outputs rely in EFI framebuffer as
> well. As soon amdgpu module is available, kernel loads it and it takes
> over the GPU, providing graphics. The kexec_file_load syscall allows to
> pass a valid screen_info structure, so by kexec'ing a new kernel, we
> have again efifb taking over on boot time, but this time I see nothing
> in the screen. I've manually blacklisted amdgpu in this new kexec'ed
> kernel, I'd like to rely in the simple framebuffer - the goal is to have
> a tiny kernel kexec'ed. I'm using kernel version 5.16.0-rc4.
>
> I've done some other experiments, for exemple: I've forced screen_info
> model to match VLFB, so vesafb took over after the kexec, with the same
> result. Also noticed that BusMaster bit was off after kexec, in the AMD
> APU PCIe device, so I've set it on efifb before probe, and finally
> tested the same things in qemu, with qxl, all with the same result
> (blank screen).
> The most interesting result I got (both with amdgpu and qemu/qxl) is
> that if I blacklist these drivers and let the machine continue using
> efifb since the beginning, after kexec the efifb is still able to
> produce graphics.
>
> Which then led me to think that likely there's something fundamentally
> "blocking" the reuse of the simple framebuffer after kexec, like maybe
> DRM stack is destroying the old framebuffer somehow? What kind of
> preparation is required at firmware level to make the simple EFI VGA
> framebuffer work, and could we perform this in a kexec (or "save it"
> before the amdgpu/qxl drivers take over and reuse later)?

unfortunately what you try here will most likely not work easily.

During bootup the ASIC is initialized in a VGA compatibility mode by the 
VBIOS which also allows efifb to display something. And among the first 
things amdgpu does is to disable this compatibility mode :)

What you need to do to get this working again is to issue a PCIe reset 
of the GPU and then re-init the ASIC with the VBIOS tables.

Alex should know more details about how to do this.

Regards,
Christian.

>
> Any advice is greatly appreciated!
> Thanks in advance,
>
>
> Guilherme


  reply	other threads:[~2021-12-09 17:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 16:00 Reuse framebuffer after a kexec (amdgpu / efifb) Guilherme G. Piccoli
2021-12-09 16:09 ` Christian König [this message]
2021-12-09 17:31 ` Alex Deucher
2021-12-09 17:59   ` Guilherme G. Piccoli
2021-12-09 18:06     ` Alex Deucher
2021-12-09 18:17       ` Guilherme G. Piccoli
2021-12-09 19:20         ` Alex Deucher
2021-12-10  7:19         ` Gerd Hoffmann
2021-12-10  8:24         ` Thomas Zimmermann
2021-12-10 14:08           ` Guilherme G. Piccoli
2021-12-10 14:16             ` Alex Deucher
2021-12-10 14:25               ` Guilherme G. Piccoli
2021-12-10 15:13                 ` Christian König
2021-12-10 15:24                   ` Guilherme G. Piccoli
2021-12-10 15:32                     ` Christian König
2021-12-10 19:11                     ` Alex Deucher
2021-12-11  0:54                   ` Felix Kuehling
2021-12-11  9:20                     ` Gerd Hoffmann
2021-12-10 19:05                 ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb02d57c-d850-b319-9e76-663c0c2f8eed@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bhe@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dyoung@redhat.com \
    --cc=gpiccoli@igalia.com \
    --cc=kasong@redhat.com \
    --cc=kernel@gpiccoli.net \
    --cc=kexec@lists.infradead.org \
    --cc=kraxel@redhat.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=siglesias@igalia.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).