Randy Dunlap wrote: > Hi-- > > On 2/2/22 15:55, Thinh Nguyen wrote: >> Arnd Bergmann wrote: >>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: >>>> Fabio Estevam wrote: >>>>> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: >>>>>> >>>>>> On 2/1/22 15:01, Thinh Nguyen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> One of our test setups is unable to boot (stuck at initramfs). Git >>>>>>> bisection points to the commit below: >>>>>>> >>>>>>> f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") >>>>>>> >>>>>>> Reverting this patch resolves the issue. This issue persists in mainline >>>>>>> also. Unfortunately there isn't any meaningful log. Hopefully someone >>>>>>> can give some insight as to what could be the issue and revert/fix this >>>>>>> issue. >>>>>> >>>>>> Hi, >>>>>> Did you enable DRM_FBDEV_EMULATION? >>>> >>>> I did not enable it. >>>> >>>>>> Please provide the failing .config file. >>>>> >>>>> Does selecting CONFIG_FB=y help? >>>>> >>>> >>>> On the config that has the issue, this isn't set. After reverting the >>>> commit above, this was set. Maybe this is what's needed? I need to test it. >>> >>> 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. >> >>> 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. >> >>> >>> 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. >>> >>> Arnd >> >> 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. > > I took bad.config with kernel 5.17-rc1 and then manually set/enabled: > > CONFIG_FB > CONFIG_FB_EFI > CONFIG_FB_MODE_HELPERS > CONFIG_FB_TILEBLITTING > CONFIG_LOGO > > and I got very close to your good.config file. > Can you do the same and see if it works for you? > If so, then we can decide what to do about it. > > > thanks. Yes. It works as expected. Thanks, Thinh