All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	linux-kernel@vger.kernel.org, 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


WARNING: multiple messages have this Message-ID (diff)
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


  reply	other threads:[~2023-07-02 10:17 UTC|newest]

Thread overview: 28+ 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 ` 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 21:44   ` Javier Martinez Canillas
2023-07-01 22:20   ` Randy Dunlap
2023-07-01 22:20     ` Randy Dunlap
2023-07-01 22:24   ` Arnd Bergmann
2023-07-01 22:24     ` Arnd Bergmann
2023-07-02  9:07     ` Geert Uytterhoeven
2023-07-02  9:07       ` Geert Uytterhoeven
2023-07-02 10:19       ` Javier Martinez Canillas
2023-07-02 10:19         ` Javier Martinez Canillas
2023-07-03  6:53   ` Thomas Zimmermann
2023-07-03  6:53     ` Thomas Zimmermann
2023-07-03  7:46     ` Javier Martinez Canillas
2023-07-03  7:46       ` Javier Martinez Canillas
2023-07-03  7:52       ` Thomas Zimmermann
2023-07-03  7:52         ` Thomas Zimmermann
2023-07-03  8:49         ` Javier Martinez Canillas
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 21:44   ` Javier Martinez Canillas
2023-07-01 22:06   ` Arnd Bergmann
2023-07-01 22:06     ` Arnd Bergmann
2023-07-02  9:04     ` Geert Uytterhoeven
2023-07-02  9:04       ` Geert Uytterhoeven
2023-07-02 10:17       ` Javier Martinez Canillas [this message]
2023-07-02 10:17         ` Javier Martinez Canillas

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=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.