From: Javier Martinez Canillas <javierm@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>,
Arthur Grillo <arthurgrillo@riseup.net>,
dri-devel@lists.freedesktop.org
Cc: tales.aparecida@gmail.com, Helge Deller <deller@gmx.de>,
Randy Dunlap <rdunlap@infradead.org>,
mairacanal@riseup.net, andrealmeid@riseup.net
Subject: Re: [PATCH] drm/tests: Remove CONFIG_DRM_FBDEV_EMULATION on .kunitconfig
Date: Fri, 28 Jul 2023 12:41:08 +0200 [thread overview]
Message-ID: <87r0osxqrf.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <c02a7694-00f1-48d2-9299-13c0a40dc0ae@app.fastmail.com>
"Arnd Bergmann" <arnd@arndb.de> writes:
[adding Randy Dunlap who also reported the same issue]
Hello Arnd,
> On Thu, Jul 27, 2023, at 18:45, Javier Martinez Canillas wrote:
>> Arthur Grillo Queiroz Cabral <arthurgrillo@riseup.net> writes:
>>> On 27/07/23 13:07, Javier Martinez Canillas wrote:
>>>> "Arnd Bergmann" <arnd@arndb.de> writes:
>>>>> Changing the local config should not be required after fixing
>>>>> the Kconfig files.
>>>>>
>>>>
>>>> CONFIG_VT can only be disabled if CONFIG_EXPERT=y but I also see that it
>>>> does not default to 'y' if !UML. Also FRAMEBUFFER_CONSOLE depends on !UML
>>>> but DRM_FBDEV_EMULATION selects FRAMEBUFFER_CONSOLE if !EXPERT.
>>>>
>>>> Maybe we should include !UML in that condition to? Something like this:
>>>>
>>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>>> index 0d499669d653..734332f222ea 100644
>>>> --- a/drivers/gpu/drm/Kconfig
>>>> +++ b/drivers/gpu/drm/Kconfig
>>>> @@ -135,7 +135,7 @@ config DRM_DEBUG_MODESET_LOCK
>>>> config DRM_FBDEV_EMULATION
>>>> bool "Enable legacy fbdev support for your modesetting driver"
>>>> depends on DRM
>>>> - select FRAMEBUFFER_CONSOLE if !EXPERT
>>>> + select FRAMEBUFFER_CONSOLE if (!EXPERT && !UML)
>
> Yes, that should work. Was the original bug report about UML then?
>
By original do you mean Arthur's report or Randy's? But yes, in both cases
CONFIG_UML=y when the issue was seen.
> I'm not actually sure we need the select at all. When I tried
> to narrow down how fbdev is used in the previous
> thread, the answer was pretty much that it could be used
> in any possible way, so there might be users that only want
> the /dev/fb0 interface but not the console, or even just
> the logo.
>
Yes, I agree with you. Maybe then the fix could be to just drop that select?
> Another thing we could do here would be
>
> config DRM_FBDEV_EMULATION
> select FRAMEBUFFER_CONSOLE if VT
>
> which is simpler and probably just as good. Or if we decide that
> DRM_FBDEV_EMULATION is in fact only useful for FRAMEBUFFER_CONSOLE
> and add 'depends on VT' and removed the "if (...)"
>
As mentioned I don't think thatis only useful with fbcon/vt and there
should be possible to enable the fbdev DRM emulation even without it.
>>>> With that I'm able to run the DRM kunit tests wihtout the mentioned
>>>> problem. But I'm not sure if that is the correct fix or not.
>>>
>>> It works here too, I just don't understand why this commit caused this
>>> bug, as it did not touch this line.
>>
>> Yes, I also don't understand why the FB_CORE split made it more likely to
>> happen since AFAICT the same problem could had happen with just CONFIG_FB.
>
> c242f48433e79 ("drm: Make FB_CORE to be selected if DRM fbdev emulation
> is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB' to
> an effective 'select FB_CORE', so any config that previously had
> DRM=y and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>
Ah, right. I see it now. Thanks for the explanation.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2023-07-28 10:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 22:03 [PATCH] drm/tests: Remove CONFIG_DRM_FBDEV_EMULATION on .kunitconfig Arthur Grillo
2023-07-27 8:33 ` Arnd Bergmann
2023-07-27 16:07 ` Javier Martinez Canillas
2023-07-27 16:39 ` Arthur Grillo Queiroz Cabral
2023-07-27 16:45 ` Javier Martinez Canillas
2023-07-27 17:56 ` Arnd Bergmann
2023-07-28 10:41 ` Javier Martinez Canillas [this message]
2023-08-04 12:53 ` Javier Martinez Canillas
2023-07-27 16:44 ` Arthur Grillo Queiroz Cabral
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r0osxqrf.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=andrealmeid@riseup.net \
--cc=arnd@arndb.de \
--cc=arthurgrillo@riseup.net \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=mairacanal@riseup.net \
--cc=rdunlap@infradead.org \
--cc=tales.aparecida@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox