Thomas Zimmermann <tzimmermann@xxxxxxx> writes: > Hi > > Am 18.11.23 um 12:10 schrieb Javier Martinez Canillas: >> Ard Biesheuvel <ardb@xxxxxxxxxx> writes: >> >> Hello Ard, >> >>> On Fri, 17 Nov 2023 at 00:09, Rob Herring <robh@xxxxxxxxxx> wrote: >> >> [...] >> >>>>>> >>>>>> This could also lead to an interesting scenario. As simple-framebuffer >>>>>> can define its memory in a /reserved-memory node, but that is ignored >>>>>> in EFI boot. Probably would work, but only because EFI probably >>>>>> generates its memory map table from the /reserved-memory nodes. >>>>>> >>>>> >>>>> I see. So what would be the solution then? Ignoring creating a platform >>>>> device for "simple-framebuffer" if booted using EFI and have an EFI-GOP? >>>> >>>> Shrug. I don't really know anything more about EFI FB, but I would >>>> guess it can't support handling resources like clocks, power domains, >>>> regulators, etc. that simple-fb can. So if a platform needs those, do >>>> we say they should not setup EFI-GOP? Or is there a use case for >>>> having both? Clients that don't muck with resources can use EFI-GOP >>>> and those that do use simple-fb. For example, does/can grub use >>>> EFI-GOP, but not simple-fb? >>>> >>> >>> The EFI GOP is just a dumb framebuffer, and it is not even generally >>> possible to cross reference the GOP with a particular device in the >>> device hierarchy unless you e.g., compare the BARs of each device with >>> the region described by the GOP protocol. >>> >>> GRUB for EFI will use the GOP and nothing else, but only at boot time >>> (the GOP protocol is more than a magic linear memory region, it also >>> implements a Blt() abstraction that permits the use of framebuffers >>> that are not mapped linearly into the address space at all, and GRUB >>> makes use of this) >>> >>> The EFI stub will only expose GOPs to the kernel if they are in fact >>> linear framebuffers, but has zero insight into whether the hardware >>> needs clocks and regulators, and whether or not the framebuffer needs >>> IOMMU pass through (which might be the case if the scanout is using >>> DMA into system memory) >>> >>> So calling EFI GOP 'source of truth' is rather generous, and I think >>> it makes sense to prioritize more accurate descriptions of the >>> underlying framebuffer over EFI GOP. >>> >> >> That was my opinion as well and the reason why I called the DTB the >> single source of truth. >> >>> However, making 'simple-framebuffer' magic in this regard doesn't seem >>> like a great approach to me. Is there a better way we could get the >>> resource conflict to be decided in a way where the EFI GOP gets >>> superseded if its resources are claimed by another device? >>> >> >> There is an aperture [0] framework that is used by the fbdev and DRM >> subsystems to allow native drivers to remove any conflicting devices >> that share the same framebuffer aperture. >> >> But it only makes sense for native drivers to use that I think, but >> in this case is about two drivers that attempt to use the same frame >> buffer provided by the firmware but getting it from different places. >> >> I don't have a better idea than this patch but maybe Thomas or Sima do? > > At SUSE, we've carried such a patch in our repos for some time. It works > around the double-framebuffer problem in a similar way. [1] > Thanks for the information. I see that your patch is basically mine but doing it unconditionally while this one only does the sysfb_disable() if a "simple-framebuffer" DT node has been found. > As Javier mentioned, we do track the framebuffer ranges for EFI/VESA/OF > framebuffers in the graphics aperture helpers. Fbdev has done this for > decades, and the current codebase extends and harmonizes this > functionality among fbdev and DRM drivers. > > WRT DT vs EFI: AFAIK the EFI support on affected platforms looks at the > DT to set up the EFI framebuffer. So IMHO the DT is the authoritative > source on the framebuffer. > Agreed. Sima Vetter also mentioned on IRC that they think this patch is the least bad option. Rob, Ard any thoughts? Maybe we can land this as a fix and then figure how this could be better handled in the long term? > Best regards > Thomas > > [1] https://bugzilla.suse.com/show_bug.cgi?id=1204315 > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
