Date:   Wed, 2 Feb 2022 23:55:57 +0000
From:   Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To:     Arnd Bergmann <arnd@...nel.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>
CC:     Fabio Estevam <festevam@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        John Youn <John.Youn@...opsys.com>,
        Bing Yuan <Bing.Yuan@...opsys.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Kconfig CONFIG_FB dependency regression

Arnd Bergmann wrote:
> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
>> Fabio Estevam wrote:
>>> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <rdunlap@...radead.org> 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.

Thanks,
Thinh

View attachment "bad.config" of type "text/plain" (152551 bytes)

View attachment "good.config" of type "text/plain" (154537 bytes)

Powered by blists - more mailing lists