From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C58CAC433F5 for ; Thu, 9 Dec 2021 18:06:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242712AbhLISKR (ORCPT ); Thu, 9 Dec 2021 13:10:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242268AbhLISKR (ORCPT ); Thu, 9 Dec 2021 13:10:17 -0500 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9624DC061746 for ; Thu, 9 Dec 2021 10:06:43 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id n104-20020a9d2071000000b005799790cf0bso7060212ota.5 for ; Thu, 09 Dec 2021 10:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GVu5cc9bTD6vf22XXmPr/TIBYXrD+gTouz5yZ1xCKFU=; b=Xf/yTmEHMqg3WBvvWp7JeHPcAbwglbi73Ndqgu4jkx6O/nW1EQQEfD+kVPcXCNgdc2 ch0xRU5cTdQdnLf4b6np9zbhXJQMLcwo8SDbaq25SGReFw3ZSso69BYgmUywbrZ32d8T LaY073GbVX8vbg+DRLxJ5R6HOazKLyLuYq/w0vqoV2EIKI2sP3dhf751sjTXaW+x0C0D yrBm/37MR4VsFA/iHLb18Q1PY2CT+IV4QTMv54pTkhFNymH7ItVZssRtoBS8Xb2ZSw/H /A6mmCtjIuD7O+4S5LfDbrwRrwkcAaJc8cDs3RW3miczuhq80AgDirUVVhF8EKCIjfFj 1jYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GVu5cc9bTD6vf22XXmPr/TIBYXrD+gTouz5yZ1xCKFU=; b=hngf0XLgMLAjZJzYTOPTMZ2r3VkPc+qryBz7dg3X2c+ZlO0+xf5aexrloMS/vaaAbB hhG8jMlvybSZqMKOvsB09BaNQAxp+y7eDmTkWBVpo3RmRqS/JZfQEd5K8fqNMJyteenS 5r99SnVt5buZ/LNOEDbEojEA3ki8jUiH6kdcjVjfZh0LO8pG96pcVZT7omelM/Bh7UL8 DL2qcipLpt+BWLdA8uZglgrexSrl0L5+6kIqMslTWDizKH1XX2FPMofSpA9GBMRi/fwy bamoV5j77lIeuFHSndiIVSt/o/fiIj99Ih5paRWLEiSKtn4x935wDuoDwhhJBZJpB6Cc GbKg== X-Gm-Message-State: AOAM533L2aK2pGkFyPV6PsJzaceFWDOaV3LykLBsv611sZWxNVKij8Hv pv7bH4QkGXnFWk+cB5ahrTnIWsKBYgaUq8iNRJc= X-Google-Smtp-Source: ABdhPJzODhY9yg2B/H0YvUtQi1UpyUrWst1qCagatbL8h3sVtVrWHhxikW3ibeZARthXGbUpDT25ejOrazxGsyBff2w= X-Received: by 2002:a05:6830:1bcf:: with SMTP id v15mr6999009ota.200.1639073202803; Thu, 09 Dec 2021 10:06:42 -0800 (PST) MIME-Version: 1.0 References: <62aab616-53cb-ff9f-c5f3-169c547bd1ee@igalia.com> In-Reply-To: From: Alex Deucher Date: Thu, 9 Dec 2021 13:06:31 -0500 Message-ID: Subject: Re: Reuse framebuffer after a kexec (amdgpu / efifb) To: "Guilherme G. Piccoli" Cc: "open list:EFIFB FRAMEBUFFER DRIVER" , kexec@lists.infradead.org, amd-gfx list , kernel@gpiccoli.net, kasong@redhat.com, Baoquan He , =?UTF-8?Q?Samuel_Iglesias_Gons=C3=A1lvez?= , xinhui pan , Maling list - DRI developers , pjones@redhat.com, Gerd Hoffmann , "Deucher, Alexander" , Dave Young , Christian Koenig , Vivek Goyal Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22866C433EF for ; Thu, 9 Dec 2021 18:06:45 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 713C110E143; Thu, 9 Dec 2021 18:06:44 +0000 (UTC) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8089810E143; Thu, 9 Dec 2021 18:06:43 +0000 (UTC) Received: by mail-ot1-x331.google.com with SMTP id x3-20020a05683000c300b0057a5318c517so6996590oto.13; Thu, 09 Dec 2021 10:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GVu5cc9bTD6vf22XXmPr/TIBYXrD+gTouz5yZ1xCKFU=; b=Xf/yTmEHMqg3WBvvWp7JeHPcAbwglbi73Ndqgu4jkx6O/nW1EQQEfD+kVPcXCNgdc2 ch0xRU5cTdQdnLf4b6np9zbhXJQMLcwo8SDbaq25SGReFw3ZSso69BYgmUywbrZ32d8T LaY073GbVX8vbg+DRLxJ5R6HOazKLyLuYq/w0vqoV2EIKI2sP3dhf751sjTXaW+x0C0D yrBm/37MR4VsFA/iHLb18Q1PY2CT+IV4QTMv54pTkhFNymH7ItVZssRtoBS8Xb2ZSw/H /A6mmCtjIuD7O+4S5LfDbrwRrwkcAaJc8cDs3RW3miczuhq80AgDirUVVhF8EKCIjfFj 1jYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GVu5cc9bTD6vf22XXmPr/TIBYXrD+gTouz5yZ1xCKFU=; b=3DDqY3XeaGh7Gd6JTVGEkHR6yOtgbRaQ6f7Xd2k3TrUNF+XAo5o3SdN3cOTxcE3Zah HXTxfk8CRK8F/sJP4vjso9DOtLRUiaklsjnI0xFR+pI3atmkmc+R046jWAvOPOOLFZ8r noTicNp1uh7YnypJoLerQ/TYEG5a5rgFLELA3n6C72AMD0WxDK+Knd2qU2K/BCzi+arp 04F2vWt8aUwo9fCeRdFn5C9BEfnYXmzuahE499BgMT1hnnngdLtze4TsYxfWpMa0O9R8 curDzEgIaGf5XOfCZ2IIfTpYxq6lM89gKZCnTPTKUhpBklMQh3opWbXcmxAkEf17o999 3IoA== X-Gm-Message-State: AOAM531vAO7B/dljcdV6TI7FnZa9XNaXAff14AEnPhMbMF+9M7fCmDBY 8S4ASHVBJC3RaMsOf6B+8aZa77p3dLNYB0EXvsA= X-Google-Smtp-Source: ABdhPJzODhY9yg2B/H0YvUtQi1UpyUrWst1qCagatbL8h3sVtVrWHhxikW3ibeZARthXGbUpDT25ejOrazxGsyBff2w= X-Received: by 2002:a05:6830:1bcf:: with SMTP id v15mr6999009ota.200.1639073202803; Thu, 09 Dec 2021 10:06:42 -0800 (PST) MIME-Version: 1.0 References: <62aab616-53cb-ff9f-c5f3-169c547bd1ee@igalia.com> In-Reply-To: From: Alex Deucher Date: Thu, 9 Dec 2021 13:06:31 -0500 Message-ID: Subject: Re: Reuse framebuffer after a kexec (amdgpu / efifb) To: "Guilherme G. Piccoli" Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:EFIFB FRAMEBUFFER DRIVER" , xinhui pan , kasong@redhat.com, Baoquan He , =?UTF-8?Q?Samuel_Iglesias_Gons=C3=A1lvez?= , kernel@gpiccoli.net, kexec@lists.infradead.org, amd-gfx list , pjones@redhat.com, Maling list - DRI developers , "Deucher, Alexander" , Dave Young , Christian Koenig , Vivek Goyal , Gerd Hoffmann Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mvNoa-00H8Nq-4w for kexec@lists.infradead.org; Thu, 09 Dec 2021 18:06:45 +0000 Received: by mail-ot1-x335.google.com with SMTP id w6-20020a9d77c6000000b0055e804fa524so7063638otl.3 for ; Thu, 09 Dec 2021 10:06:43 -0800 (PST) MIME-Version: 1.0 References: <62aab616-53cb-ff9f-c5f3-169c547bd1ee@igalia.com> In-Reply-To: From: Alex Deucher Date: Thu, 9 Dec 2021 13:06:31 -0500 Message-ID: Subject: Re: Reuse framebuffer after a kexec (amdgpu / efifb) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: "Guilherme G. Piccoli" Cc: "open list:EFIFB FRAMEBUFFER DRIVER" , kexec@lists.infradead.org, amd-gfx list , kernel@gpiccoli.net, kasong@redhat.com, Baoquan He , =?UTF-8?Q?Samuel_Iglesias_Gons=C3=A1lvez?= , xinhui pan , Maling list - DRI developers , pjones@redhat.com, Gerd Hoffmann , "Deucher, Alexander" , Dave Young , Christian Koenig , Vivek Goyal On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec