Kconfig CONFIG_FB dependency regression
Thinh Nguyen
Thinh.Nguyen at synopsys.com
Wed Feb 2 15:55:57 PST 2022
Arnd Bergmann wrote:
> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen <Thinh.Nguyen at synopsys.com> wrote:
>> Fabio Estevam wrote:
>>> On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap <rdunlap at infradead.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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bad.config
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20220202/02a1b1ff/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: good.config
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20220202/02a1b1ff/attachment-0003.ksh>
More information about the Linux-mediatek
mailing list