linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: David Herrmann <dh.herrmann@gmail.com>,
	Ingo Molnar <mingo@kernel.org>, Dave Airlie <airlied@redhat.com>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: drm/cirrus: Ignore busy mem region when mapping VRAM
Date: Fri, 31 Jan 2014 10:51:56 +0000	[thread overview]
Message-ID: <52EB804C.2090506@canonical.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2854 bytes --]

I know this is a gross hack but something like that currently is required to
avoid a KVM guest booted from graphical grub mode (so simplefb is taking effect)
getting into a state where there is no framebuffer in use at all (since simplefb
was removed but cirrus fails to acquire VRAM resources which are held by the
platform device). _Guests in that stage appear to be frozen but can be reached
via network login with no problems.

It would be possible to release the mem region in the simplefb driver when
unmapping but that sounds equally bad. Is someone already looking into some
better solution here? Should the platform device be removed or what would be a
good way to go forward here?

-Stefan

--

From 5eaa87a69bb40ffeec759b6e5aeec1a26bba1680 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Wed, 29 Jan 2014 16:45:12 +0000
Subject: [PATCH] drm/cirrus: Ignore busy mem region when mapping VRAM

Since 29d274b8d3e2404cd1832b3a999b12f9d1e1d895 ("x86/simplefb: Mark
framebuffer mem-resources as IORESOURCE_BUSY to avoid bootup warning")
the messages for real hw drivers mapping the same region as the simple-
framebuffer are gone. But now the cirrus drm driver will always fail
to initialize its VRAM because the region is busy. Removing the
conflicting framebuffer only can stop simplefb from using the memory
and unmap it but it is the platform device which has the region assined
to itself.
As the comment of the above patch indicates there is currently no sane
way to get rid of the platform device. So at least for now accept that
the region can appear busy. It is usuable nonetheless.
This will fix VMs using the cirrus gfx emulation to appear locked up
when booting from GRUB gfx mode.

BugLink: http://bugs.launchpad.net/bugs/1269401

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 557d094..9f0193f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -101,8 +101,15 @@ static int cirrus_vram_init(struct cirrus_device *cdev)

 	if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
 				"cirrusdrmfb_vram")) {
-		DRM_ERROR("can't reserve VRAM\n");
-		return -ENXIO;
+		/*
+		 * With the simple-framebuffer now marking the region
+		 * busy there is no way of this succeeding with having
+		 * the framebuffer active. Getting here means the old
+		 * one has been kicked and the region is unmapped but
+		 * there is no way to eject the platform device to get
+		 * the request_region undone.
+		 */
+		DRM_ERROR("can't reserve VRAM (ignored)\n");
 	}

 	return 0;
-- 
1.8.3.2

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-drm-cirrus-Ignore-busy-mem-region-when.patch --]
[-- Type: text/x-diff; name="0001-drm-cirrus-Ignore-busy-mem-region-when.patch", Size: 2136 bytes --]

From 5eaa87a69bb40ffeec759b6e5aeec1a26bba1680 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Wed, 29 Jan 2014 16:45:12 +0000
Subject: [PATCH] drm/cirrus: Ignore busy mem region when mapping VRAM

Since 29d274b8d3e2404cd1832b3a999b12f9d1e1d895 ("x86/simplefb: Mark
framebuffer mem-resources as IORESOURCE_BUSY to avoid bootup warning")
the messages for real hw drivers mapping the same region as the simple-
framebuffer are gone. But now the cirrus drm driver will always fail
to initialize its VRAM because the region is busy. Removing the
conflicting framebuffer only can stop simplefb from using the memory
and unmap it but it is the platform device which has the region assined
to itself.
As the comment of the above patch indicates there is currently no sane
way to get rid of the platform device. So at least for now accept that
the region can appear busy. It is usuable nonetheless.
This will fix VMs using the cirrus gfx emulation to appear locked up
when booting from GRUB gfx mode.

BugLink: http://bugs.launchpad.net/bugs/1269401

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c
index 557d094..9f0193f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -101,8 +101,15 @@ static int cirrus_vram_init(struct cirrus_device *cdev)
 
 	if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
 				"cirrusdrmfb_vram")) {
-		DRM_ERROR("can't reserve VRAM\n");
-		return -ENXIO;
+		/*
+		 * With the simple-framebuffer now marking the region
+		 * busy there is no way of this succeeding with having
+		 * the framebuffer active. Getting here means the old
+		 * one has been kicked and the region is unmapped but
+		 * there is no way to eject the platform device to get
+		 * the request_region undone.
+		 */
+		DRM_ERROR("can't reserve VRAM (ignored)\n");
 	}
 
 	return 0;
-- 
1.8.3.2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

             reply	other threads:[~2014-01-31 10:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31 10:51 Stefan Bader [this message]
2014-02-03 16:44 ` drm/cirrus: Ignore busy mem region when mapping VRAM David Herrmann

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=52EB804C.2090506@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=airlied@redhat.com \
    --cc=dh.herrmann@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).