dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


  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