All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: "H . Peter Anvin" <hpa@zytor.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	x86@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-fbdev@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Maxime Ripard <mripard@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Peter Robinson <pbrobinson@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel@ffwll.ch>, Ingo Molnar <mingo@redhat.com>,
	David Airlie <airlied@linux.ie>,
	Javier Martinez Canillas <javierm@redhat.com>
Subject: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled
Date: Fri, 27 Aug 2021 12:00:23 +0200	[thread overview]
Message-ID: <20210827100027.1577561-1-javierm@redhat.com> (raw)

This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still using fbcon with the DRM fbdev emulation layer.

The reason for doing this is that now with simpledrm we could just boot
with simpledrm -> real DRM driver, without needing any legacy fbdev driver
(e.g: efifb or simplefb) even for the early console.

We want to do that in the Fedora kernel, but currently need to keep option
CONFIG_FB enabled and all fbdev drivers explicitly disabled, which makes
the configuration harder to maintain.

It is a RFC because I'm not that familiar with the fbdev core, but I have
tested and works with CONFIG_DRM_FBDEV_EMULATION=y and CONFIG_FB disabled.
This config automatically disables all the fbdev drivers that is our goal.

Patch 1/4 is just a clean up, patch 2/4 moves a couple of functions out of
fbsysfs.o, that are not related to sysfs attributes creation and finally
patch 3/4 makes the fbdev split that is mentioned above.

Patch 4/4 makes the DRM fbdev emulation depend on the new FB_CORE symbol
instead of FB. This could be done as a follow-up but for completeness is
also included in this series.

Best regards,
Javier


Javier Martinez Canillas (4):
  fbdev: Rename fb_*_device() functions names to match what they do
  fbdev: Move framebuffer_{alloc,release}() functions to fbmem.c
  fbdev: Split frame buffer support in FB and FB_CORE symbols
  drm: Make fbdev emulation depend on FB_CORE instead of FB

 arch/x86/Makefile                  |  2 +-
 arch/x86/video/Makefile            |  2 +-
 drivers/gpu/drm/Kconfig            |  2 +-
 drivers/video/console/Kconfig      |  2 +-
 drivers/video/fbdev/Kconfig        | 57 +++++++++++++---------
 drivers/video/fbdev/core/Makefile  | 13 +++--
 drivers/video/fbdev/core/fbmem.c   | 73 ++++++++++++++++++++++++++--
 drivers/video/fbdev/core/fbsysfs.c | 77 +-----------------------------
 include/linux/fb.h                 | 18 ++++++-
 9 files changed, 134 insertions(+), 112 deletions(-)

-- 
2.31.1


             reply	other threads:[~2021-08-27 10:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 10:00 Javier Martinez Canillas [this message]
2021-08-27 10:00 ` [RFC PATCH 1/4] fbdev: Rename fb_*_device() functions names to match what they do Javier Martinez Canillas
2021-08-27 17:50 ` [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled Thomas Zimmermann
2021-08-27 20:20   ` Daniel Vetter
2021-08-27 22:02     ` Javier Martinez Canillas
2021-08-31 12:35       ` Daniel Vetter
2021-09-01  9:08         ` Javier Martinez Canillas
2021-09-02 14:31           ` Daniel Vetter
2021-09-01 14:17         ` Sam Ravnborg
2021-09-09 15:52           ` Noralf Trønnes
2021-09-09 16:27             ` Noralf Trønnes
2021-09-10 16:05               ` Sam Ravnborg

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=20210827100027.1577561-1-javierm@redhat.com \
    --to=javierm@redhat.com \
    --cc=airlied@linux.ie \
    --cc=bp@alien8.de \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=mripard@kernel.org \
    --cc=pbrobinson@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tzimmermann@suse.de \
    --cc=x86@kernel.org \
    /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.