Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1391394
| From | Ard Biesheuvel <ard.biesheuvel@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation |
| Date | 2016-04-29 22:30 +0200 |
| Message-ID | <rtncZ-3HL-11@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <rsYxX-8l7-11@gated-at.bofh.it> <rt1Pc-2H9-5@gated-at.bofh.it> <rtgXW-6T4-41@gated-at.bofh.it> <rth7A-6Yb-15@gated-at.bofh.it> <rtmTE-3yl-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> On 29 apr. 2016, at 22:06, Bjorn Helgaas <helgaas@kernel.org> wrote: > >> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote: >>> On 29 April 2016 at 15:41, Bjorn Helgaas <helgaas@kernel.org> wrote: >>>> On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote: >>>> On 28.04.16 20:06, Bjorn Helgaas wrote: > >>>>> If firmware is giving us a bare address of something, that seems like >>>>> a clue that it might depend on that address staying the same. >>>> >>>> Well, I'd look at it from the other side. It gives us a correct address >>>> on entry with the system configured at exactly the state it's in on >>>> entry. If Linux changes the system, some guarantees obviously don't work >>>> anymore. >>> >>> Can you point me to the part of the EFI spec that communicates this? >>> I'm curious what the intent is and whether there's any indication that >>> EFI expects the OS to preserve some configuration. I don't think it's >>> reasonable for the OS to preserve this sort of configuration because >>> it limits how well we can support hotplug. >>> >>> I wonder if we're using this frame buffer address as more than what >>> EFI intended. For example, maybe it was intended for use by an early >>> console driver, but there's some other mechanism we should be using >>> after that. >> >> The UEFI spec describes this as follows (UEFIv2.6 section 11.9) >> >> """ >> Graphics output may also be required as part of the startup of an >> operating system. There are >> potentially times in modern operating systems prior to the loading of >> a high performance OS >> graphics driver where access to graphics output device is required. >> The Graphics Output Protocol >> supports this capability by providing the EFI OS loader access to a >> hardware frame buffer and >> enough information to allow the OS to draw directly to the graphics >> output device. >> """ >> >> So the intent is to provide minimal framebuffer services until the >> 'real' driver takes over. > > Makes sense. A 'real' driver for a PCI device would use > pci_register_driver() and use pci_resource_start() or similar to > locate the framebuffer, which would avoid the problem because the PCI > core doesn't change BARs while a driver owns the device. > >> The GOP protocol only describes the base and size of the framebuffer, >> and the pixel format. At boot time, the early UEFI code in the kernel >> could potentially figure out which PCI device it is related to, if >> necessary, but i am not sure if this would solve the x86 case as well. > > Does drivers/video/fbdev/efifb.c support only a single framebuffer > device? If a system has several, how does it decide which to use? I > assume UEFI would provide GOP for all the framebuffers? > Yes. The early efi code iterates over all gop instances to figure out which one is connected to the efi console. > If we could fix this by making efifb claim a PCI device, I think that > would be cleaner. I don't know how to figure out the correct device, > but that would solve the "BAR changed" problem, and it would have > cleaner ownership semantics, too. If the bus layout is static, the efi init code can record the segment/bus/device and match it with the kernel's view. is that guaranteed to be sufficient for all implementations of pci? > It looks like the current situation is that a device-specific driver > (radeon, i915, etc.) could claim the device via the usual > pci_register_driver() path, and the efifb driver could think it owns > the device at the same time. This seems like too obvious a problem, > so maybe there's some ad hoc mechanism that resolves this?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-28 18:30 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Alexander Graf <agraf@suse.de> - 2016-04-28 18:50 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-28 20:10 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Alexander Graf <agraf@suse.de> - 2016-04-28 23:40 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-04-29 12:10 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-29 15:50 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-04-29 16:00 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-29 22:10 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-04-29 22:30 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Alexander Graf <agraf@suse.de> - 2016-04-29 23:00 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-29 23:40 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Alexander Graf <agraf@suse.de> - 2016-04-30 00:00 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Alexander Graf <agraf@suse.de> - 2016-04-30 00:10 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-30 01:40 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-30 23:20 +0200
Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation Bjorn Helgaas <helgaas@kernel.org> - 2016-04-29 23:30 +0200
csiph-web