From: Javier Martinez Canillas <javierm@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>, Dave Airlie <airlied@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 2/2] drm: Make fbdev emulation select FB_CORE instead of depends on FB
Date: Sun, 02 Jul 2023 12:17:30 +0200 [thread overview]
Message-ID: <87sfa6aa85.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <CAMuHMdWQ3FcmyCd-mWOWVAXzgoOX8wBD8-LbRwjNkC=sz3y27g@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Hi Arnd,
>
> On Sun, Jul 2, 2023 at 12:07 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sat, Jul 1, 2023, at 23:44, Javier Martinez Canillas wrote:
>> > Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
>> > emulation layer to just select the former.
>> >
>> > This allows to disable the CONFIG_FB option if is not needed, which will
>> > avoid the need to explicitly disable each of the legacy fbdev drivers.
>> >
>> > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> > ---
>> >
>> > Changes in v2:
>> > - Make CONFIG_DRM_FBDEV_EMULATION to select FB_CORE (Thomas Zimmermann).
>> >
>> > drivers/gpu/drm/Kconfig | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> > index afb3b2f5f425..d9b1710e3ad0 100644
>> > --- a/drivers/gpu/drm/Kconfig
>> > +++ b/drivers/gpu/drm/Kconfig
>> > @@ -132,7 +132,7 @@ 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
>> > + select FB_CORE
>>
>> This will unfortunately force FB_CORE=y even with DRM=m, it would be nice
>> to allow both to be loadable modules. Any of these should work:
>>
Right, I missed that. Thanks for pointing that out.
>> a) Add another hidden symbol like
>>
>> config DRM_FB_CORE
>> def_tristate DRM && DRM_FBDEV_EMULATION
>> select FB_CORE
>
> More complexity to keep track of...
>
Yes, I would avoid this option as well.
>>
>> b) move the 'select' to DRM
>>
>> config DRM
>> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
>> select FB_CORE if DRM_FBDEV_EMULATION
>
> I prefer this one, as it keeps the select close to the user.
>
Agreed with Geert that this is the best option.
> BTW, the tristate help text can use some overhaul ;-)
>
Indeed :) I will add a preparatory patch to this series improving that
prompt text.
>> c) Remove the 'select' and instead use the default
>>
>> config FB_CORE
>> def_tristate FB || (DRM && DRM_FBDEV_EMULATION)
>
> Adding it here means this patch would touch two subsystems.
>
Yeah. Even when in practice we push changes for drivers/video and
drivers/gpu/drm in drm-misc, I agree that option (b) is better.
> Gr{oetje,eeting}s,
>
> Geert
>
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
prev parent reply other threads:[~2023-07-02 10:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 21:44 [PATCH v2 0/2] Allow disabling all native fbdev drivers and only keeping DRM emulation Javier Martinez Canillas
2023-07-01 21:44 ` [PATCH v2 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols Javier Martinez Canillas
2023-07-01 22:20 ` Randy Dunlap
2023-07-01 22:24 ` Arnd Bergmann
2023-07-02 9:07 ` Geert Uytterhoeven
2023-07-02 10:19 ` Javier Martinez Canillas
2023-07-03 6:53 ` Thomas Zimmermann
2023-07-03 7:46 ` Javier Martinez Canillas
2023-07-03 7:52 ` Thomas Zimmermann
2023-07-03 8:49 ` Javier Martinez Canillas
2023-07-01 21:44 ` [PATCH v2 2/2] drm: Make fbdev emulation select FB_CORE instead of depends on FB Javier Martinez Canillas
2023-07-01 22:06 ` Arnd Bergmann
2023-07-02 9:04 ` Geert Uytterhoeven
2023-07-02 10:17 ` Javier Martinez Canillas [this message]
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=87sfa6aa85.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/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