Randy Dunlap wrote:
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@synopsys.com wrote:
Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen Thinh.Nguyen@synopsys.com 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_HELPERdepends on FB=y || FB=DRM_KMS_HELPER
depends on DRMselect DRM_KMS_HELPERselect FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLITI 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?
I just use the change above and "make" with olddefconfig option. Is it not expected?
Thanks, Thinh