Andrew Worsley <amworsley@xxxxxxxxx> writes: Hello Andrew, > On Mon, 13 Nov 2023 at 20:18, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: >> Am 13.11.23 um 09:51 schrieb Javier Martinez Canillas: >> > Some DT platforms use EFI to boot and in this case the EFI Boot Services >> > may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that will later be >> > queried by the Linux EFI stub to fill the global struct screen_info data. >> > [...] > > I applied the patch and just the simpledrm driver is probed (the efifb is not): > > grep -i -E 'drm|efifb' --color -C3 dmesg-6.5.0-asahi-00780-gf5aadc85a34d.txt > [ 2.621433] systemd-journald[276]: varlink-21: Changing state > idle-server \xe2\x86\x92 pending-disconnect > [ 2.621437] systemd-journald[276]: varlink-21: Changing state > pending-disconnect \xe2\x86\x92 processing-disconnect > [ 2.621439] systemd-journald[276]: varlink-21: Changing state > processing-disconnect \xe2\x86\x92 disconnected > [ 2.878828] [drm] Initialized simpledrm 1.0.0 20200625 for > bd58dc000.framebuffer on minor 0 > [ 2.909764] Console: switching to colour frame buffer device 160x50 Great, thanks for testing. The patch works then as expected. Can I get your Tested-by then ? > > I am wondering if the drm_aperture_remove_framebuffers() shouldn't be > called in the probe function anyway > as it ends up overriding the efifb one as wanted and handles the case > the simpledrm (CONFIG_DRM_SIMPLEDRM) > is not present. > Perhaps there is an accepted principle that such kernels *should* fail > to set up a FB? > We were talking with Thomas that the sysfb design seems to be reaching its limits and need some rework but currently you either need some driver that matches the "simple-framebuffer" device that is registered by OF or won't get an early framebuffer in the system. That could be either simpledrm or simplefb. But if a DT has a device node for "simple-framebuffer", how can the OF core know if there is a driver to match that device? And same for any other device defined in the DTB. It's similar on platforms that use sysfb to register the device (e.g: x86) since either "simple-framebuffer" is registered (if CONFIG_SYSFB_SIMPLEFB is enabled) or "efi-framebuffer" (if CONFIG_SYSFB_SIMPLEFB is disabled). That means CONFIG_SYSFB_SIMPLEFB=y and CONFIG_DRM_SIMPLEDRM disabled won't work either, even if CONFIG_FB_EFI=y which is the case you are mentioning. What I think that doesn't make sense is to remove conflicting framebuffers from drivers that can only handle firmware provided framebuffers. As said in the other thread, drm_aperture_remove_framebuffers() is only meant for native DRM drivers. > Andrew > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
