On 2/3/22 19:21, Thinh Nguyen wrote: > Arnd Bergmann wrote: >> On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: >>> Arnd Bergmann wrote: >>>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: >>>>> Fabio Estevam wrote: >>>> >>>> CONFIG_FB should not normally be needed for booting, so unless >>>> you have a graphical application in your initramfs that requires the /dev/fb0 >>>> device to work, it is not supposed to make a difference. >>>> >>> >>> I'm not sure, but it seems like the setup we have isn't the only one >>> that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs >>> to have CONFIG_FB set. >> >> No, that one is different: the change for imx_v6_v7_defconfig was >> done because they actually use a framebuffer console on some devices, >> so the patch just adds the symbol to enable the drivers they are using. >> >> This is expected with my original patch that doesn't implicitly enable >> the framebuffer layer any more. What is not expected is for the kernel >> to hang during boot as you reported for your unidentified platform. >> >>>> Are there any other differences in your .config before and after the patch? >>>> It's possible that you use some other driver that in turn depends on >>>> CONFIG_FB. Does your machine have any graphical output device? >>>> If yes, which driver do you use? >>> >>> I don't have the answer to those questions yet. Need more investigation. >>> I'm new to this particular test setup. >> >> Do you mean you don't know if there is a screen attached to the system? >> > > It does have a graphical output device, but I didn't check what it is or > what driver is driving it. I just notice that after the reported commit, > something stopped working. > >>>> >>>> You may also want to make sure that you have 9d6366e743f3 ("drm: >>>> fb_helper: improve CONFIG_FB dependency") in your kernel, which >>>> fixes a minor problem with my original patch. >>>> >>> >>> The issue also occurs in mainline, which has your minor fix commit >>> above. The revert isn't clean for the latest kernel version. I also have >>> to revert some of the changes along with CONFIG_FB. The revert looks >>> more like this for the latest kernel: >>> >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >>> index b1f22e457fd0..7cbc733a8569 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK >>> >>> config DRM_FBDEV_EMULATION >>> bool "Enable legacy fbdev support for your modesetting driver" >>> - depends on DRM_KMS_HELPER >>> - depends on FB=y || FB=DRM_KMS_HELPER >>> + depends on DRM >>> + select DRM_KMS_HELPER >>> + select FB >>> select FB_CFB_FILLRECT >>> select FB_CFB_COPYAREA >>> select FB_CFB_IMAGEBLIT >>> >>> >>> >>> I attached the configs for kernel v5.17-rc1. The "bad" config is without >>> any revert, the "good" config is with the change above. >> >> Looking at the config, I see that this is for an x86 machine, >> and you have the FB_EFI driver and EFI_EARLYCON enabled. >> >> What I suspec is going on is that you are looking at a screen rather >> than a serial console, and the kernel doesn't actually hang but you >> just don't see any more messages after the DRM driver takes >> over from EFI_EARLYCON because there is no console driver. >> >> In this case, what you see is the intended behavior, not a bug. >> If you want a graphical console in your system, you need to >> enable the support for this in your config. >> > > It sounds like that's the case. Unfortunately I'm not familiar with this > subsystem to say that's what happening. If there's nothing actually > broken from review, we can ignore this email thread. Hi, I don't know of anything that is broken... I am curious how CONFIG_FB_EFI came to be set when going from bad.config to good.config. Can you explain that? thanks. -- ~Randy