Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1450081 > unrolled thread

[PATCH 4.6 138/203] drm/vmwgfx: Work around mode set failure in 2D VMs

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-07-26 00:10 +0200
Last post2016-07-26 00:10 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 4.6 138/203] drm/vmwgfx: Work around mode set failure in 2D VMs Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-07-26 00:10 +0200

#1450081 — [PATCH 4.6 138/203] drm/vmwgfx: Work around mode set failure in 2D VMs

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-07-26 00:10 +0200
Subject[PATCH 4.6 138/203] drm/vmwgfx: Work around mode set failure in 2D VMs
Message-ID<rYWev-1Uf-59@gated-at.bofh.it>
4.6-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sinclair Yeh <syeh@vmware.com>

commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream.

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.

Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |    7 +++++++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |    9 +--------
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -704,6 +704,13 @@ static int vmw_driver_load(struct drm_de
 			vmw_read(dev_priv,
 				 SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB);
 
+		/*
+		 * Workaround for low memory 2D VMs to compensate for the
+		 * allocation taken by fbdev
+		 */
+		if (!(dev_priv->capabilities & SVGA_CAP_3D))
+			mem_size *= 2;
+
 		dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE;
 		dev_priv->prim_bb_mem =
 			vmw_read(dev_priv,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1553,14 +1553,7 @@ int vmw_du_connector_fill_modes(struct d
 		DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
 	};
 	int i;
-	u32 assumed_bpp = 2;
-
-	/*
-	 * If using screen objects, then assume 32-bpp because that's what the
-	 * SVGA device is assuming
-	 */
-	if (dev_priv->active_display_unit == vmw_du_screen_object)
-		assumed_bpp = 4;
+	u32 assumed_bpp = 4;
 
 	if (dev_priv->assume_16bpp)
 		assumed_bpp = 2;

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web