From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-pci <linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Peter Jones <pjones@redhat.com>, linux-fbdev@vger.kernel.org, "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>, Matt Fleming <matt@codeblueprint.co.uk>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Subject: Re: [PATCH v2] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Wed, 12 Jul 2017 13:13:14 +0100 [thread overview] Message-ID: <CAKv+Gu8pmsqZj25_en7Q-i4tHhTjfuLoO9mRatH-+KZxMgi6ag@mail.gmail.com> (raw) In-Reply-To: <1886933.1k4ytioEMD@amdc3058> On 12 July 2017 at 11:00, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On Monday, July 10, 2017 10:13:05 PM Ard Biesheuvel wrote: >> On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP) >> instance to which the efifb driver attempts to attach in order to provide >> a minimal, unaccelerated framebuffer. The GOP protocol itself is not very >> sophisticated, and only describes the offset and size of the framebuffer >> in memory, and the pixel format. >> >> If the GOP framebuffer is provided by a PCI device, it will have been >> configured and enabled by the UEFI firmware, and the GOP protocol will >> simply point into a live BAR region. However, the GOP protocol itself does >> not describe this relation, and so we have to take care not to reconfigure >> the BAR without taking efifb's dependency on it into account. >> >> Commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers >> the framebuffer") attempted to do so by claiming the BAR resource early >> on, which prevents the PCI resource allocation routines from changing it. >> However, it turns out that this only works if the PCI device is not >> behind any bridges, since the bridge resources need to be claimed first. >> >> So instead, allow the BAR to be moved, but make the efifb driver deal >> with that gracefully. So record the resource that covers the BAR early >> on, and if it turns out to have moved by the time we probe the efifb >> driver, update the framebuffer address accordingly. >> >> While this is less likely to occur on x86, given that the firmware's >> PCI resource allocation is more likely to be preserved, this is a >> worthwhile sanity check to have in place, and so let's remove the > > It still cuts the patch description early.. > Ah yes, thanks for pointing that out. I will fix it up before queuing the patch. >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > From fbdev's side: > > Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > Cheers.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-pci <linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Peter Jones <pjones@redhat.com>, linux-fbdev@vger.kernel.org, "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>, Matt Fleming <matt@codeblueprint.co.uk>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Subject: Re: [PATCH v2] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Wed, 12 Jul 2017 12:13:14 +0000 [thread overview] Message-ID: <CAKv+Gu8pmsqZj25_en7Q-i4tHhTjfuLoO9mRatH-+KZxMgi6ag@mail.gmail.com> (raw) In-Reply-To: <1886933.1k4ytioEMD@amdc3058> On 12 July 2017 at 11:00, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On Monday, July 10, 2017 10:13:05 PM Ard Biesheuvel wrote: >> On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP) >> instance to which the efifb driver attempts to attach in order to provide >> a minimal, unaccelerated framebuffer. The GOP protocol itself is not very >> sophisticated, and only describes the offset and size of the framebuffer >> in memory, and the pixel format. >> >> If the GOP framebuffer is provided by a PCI device, it will have been >> configured and enabled by the UEFI firmware, and the GOP protocol will >> simply point into a live BAR region. However, the GOP protocol itself does >> not describe this relation, and so we have to take care not to reconfigure >> the BAR without taking efifb's dependency on it into account. >> >> Commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers >> the framebuffer") attempted to do so by claiming the BAR resource early >> on, which prevents the PCI resource allocation routines from changing it. >> However, it turns out that this only works if the PCI device is not >> behind any bridges, since the bridge resources need to be claimed first. >> >> So instead, allow the BAR to be moved, but make the efifb driver deal >> with that gracefully. So record the resource that covers the BAR early >> on, and if it turns out to have moved by the time we probe the efifb >> driver, update the framebuffer address accordingly. >> >> While this is less likely to occur on x86, given that the firmware's >> PCI resource allocation is more likely to be preserved, this is a >> worthwhile sanity check to have in place, and so let's remove the > > It still cuts the patch description early.. > Ah yes, thanks for pointing that out. I will fix it up before queuing the patch. >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > From fbdev's side: > > Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > Cheers.
next prev parent reply other threads:[~2017-07-12 12:13 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20170710211327epcas1p4443f6f9df236e76fd4afd91dccf45cd0@epcas1p4.samsung.com> 2017-07-10 21:13 ` [PATCH v2] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Ard Biesheuvel 2017-07-10 21:13 ` Ard Biesheuvel 2017-07-12 10:00 ` Bartlomiej Zolnierkiewicz 2017-07-12 10:00 ` Bartlomiej Zolnierkiewicz 2017-07-12 10:00 ` Bartlomiej Zolnierkiewicz 2017-07-12 12:13 ` Ard Biesheuvel [this message] 2017-07-12 12:13 ` Ard Biesheuvel [not found] ` <20170710211305.6475-1-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2017-07-11 9:43 ` Ard Biesheuvel 2017-07-11 9:43 ` Ard Biesheuvel 2017-07-11 9:43 ` Ard Biesheuvel 2017-07-11 11:55 ` Peter Jones 2017-07-11 11:55 ` Peter Jones 2017-07-11 11:55 ` Peter Jones 2017-07-11 12:12 ` Ard Biesheuvel 2017-07-11 12:12 ` Ard Biesheuvel 2017-07-12 19:54 ` Bjorn Helgaas 2017-07-12 19:54 ` Bjorn Helgaas 2017-07-12 19:54 ` Bjorn Helgaas
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=CAKv+Gu8pmsqZj25_en7Q-i4tHhTjfuLoO9mRatH-+KZxMgi6ag@mail.gmail.com \ --to=ard.biesheuvel@linaro.org \ --cc=b.zolnierkie@samsung.com \ --cc=bhelgaas@google.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=matt@codeblueprint.co.uk \ --cc=pjones@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.