On 4/15/21 2:49 PM, Daniel Vetter wrote:
On Thu, Apr 15, 2021 at 8:21 PM Zack Rusin <[email protected]> wrote:
On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
Respect DRM's kconfig setting for fbdev console emulation. If enabled,
it will select all required config options. So remove them from vmwgfx's
Kconfig file.
Signed-off-by: Thomas Zimmermann <[email protected]>
---
drivers/gpu/drm/vmwgfx/Kconfig | 7 +------
drivers/gpu/drm/vmwgfx/Makefile | 4 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index 15acdf2a7c0f..b3a34196935b 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -2,12 +2,7 @@
config DRM_VMWGFX
tristate "DRM driver for VMware Virtual GPU"
depends on DRM && PCI && X86 && MMU
- select FB_DEFERRED_IO
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
select DRM_TTM
- select FB
select MAPPING_DIRTY_HELPERS
# Only needed for the transitional use of drm_crtc_init - can be removed
# again once vmwgfx sets up the primary plane itself.
@@ -20,7 +15,7 @@ config DRM_VMWGFX
The compiled module will be called "vmwgfx.ko".
config DRM_VMWGFX_FBCON
- depends on DRM_VMWGFX && FB
+ depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
bool "Enable framebuffer console under vmwgfx by default"
help
Choose this option if you are shipping a new vmwgfx
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 8c02fa5852e7..9f5743013cbb 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
- vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
+ vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
@@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
ttm_object.o ttm_lock.o ttm_memory.o
+vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
+
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 7e6518709e14..e7836da190c4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct
vmw_private *dev_priv,
* Kernel framebuffer - vmwgfx_fb.c
*/
+#ifdef CONFIG_DRM_FBDEV_EMULATION
int vmw_fb_init(struct vmw_private *vmw_priv);
int vmw_fb_close(struct vmw_private *dev_priv);
int vmw_fb_off(struct vmw_private *vmw_priv);
int vmw_fb_on(struct vmw_private *vmw_priv);
+#else
+static inline int vmw_fb_init(struct vmw_private *vmw_priv)
+{
+ return 0;
+}
+static inline int vmw_fb_close(struct vmw_private *dev_priv)
+{
+ return 0;
+}
+static inline int vmw_fb_off(struct vmw_private *vmw_priv)
+{
+ return 0;
+}
+static inline int vmw_fb_on(struct vmw_private *vmw_priv)
+{
+ return 0;
+}
+#endif
/**
* Kernel modesetting - vmwgfx_kms.c
This changes the behavior a bit, I guess DRM_VMWGFX (or at least
DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve the old
behavior, but that's largely due to the fact that given how those options were
setup we never run without FB set. In general it should be ok and looks more
reasonable than the current setup. I'll try it out on Monday just in case, but
for now:
The issue is that select in Kconfig is pretty annoying (hard to
disable, and it's not recursive), so there's a bit a push to retire
it. Especially for user-facing config knobs like whether you want
fbdev emulation or not. Hence the change.
Yes, I understand the change. It makes sense. I'm just saying that given how
hard it was to even build vmwgfx without FB, it's likely it's never been
used/tested in this configuration so it might be broken without FB config set.
But like I said, it should be fine (it's basically only if we had some generic
init code for the rest of the codebase tied to fb initialization).
z
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
