From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jules Villard <jvillard@ens-lyon.fr>,
linux-kernel@vger.org, Andrew Morton <akpm@osdl.org>,
Dave Airlie <airlied@linux.ie>
Subject: Re: Suspend to {mem,disk} broken in 2.6.15-rc6/rc7 on my T42
Date: Tue, 27 Dec 2005 12:49:33 +1100 [thread overview]
Message-ID: <1135648173.4780.18.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0512261545460.14098@g5.osdl.org>
Also, while we are at it, can you try this patch on top of current
-git ? What I _think_ might be happening is that the X server is also
trying to muck around with the card memory map and is forcing it back
into a wrong setting that also happens to no longer match what the DRM
wants to do and blows up. There are bugs all over the place in that code
(and still some bugs in the DRM as well anyway). This patch attempts to
avoid that by using the largest of the 2 values, which I think will
cause it to behave as it used to for you and will still fix the problem
with machines that have an aperture size smaller than the video memory.
That might be good enough until I fully fix X and the DRM (work in progress
but there are other "issues").
Index: linux-work/drivers/char/drm/radeon_cp.c
===================================================================
--- linux-work.orig/drivers/char/drm/radeon_cp.c 2005-12-24 10:07:22.000000000 +1100
+++ linux-work/drivers/char/drm/radeon_cp.c 2005-12-27 12:48:02.000000000 +1100
@@ -1312,7 +1312,7 @@
static int radeon_do_init_cp(drm_device_t * dev, drm_radeon_init_t * init)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
- unsigned int mem_size;
+ unsigned int mem_size, aper_size;
DRM_DEBUG("\n");
@@ -1527,7 +1527,9 @@
mem_size = RADEON_READ(RADEON_CONFIG_MEMSIZE);
if (mem_size == 0)
mem_size = 0x800000;
- dev_priv->gart_vm_start = dev_priv->fb_location + mem_size;
+ aper_size = max(RADEON_READ(RADEON_CONFIG_APER_SIZE), mem_size);
+
+ dev_priv->gart_vm_start = dev_priv->fb_location + aper_size;
#if __OS_HAS_AGP
if (!dev_priv->is_pci)
next prev parent reply other threads:[~2005-12-27 12:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-26 19:45 Suspend to {mem,disk} broken in 2.6.15-rc6/rc7 on my T42 Jules Villard
[not found] ` <Pine.LNX.4.64.0512261201360.14098@g5.osdl.org>
2005-12-26 21:23 ` Jules Villard
2005-12-27 2:58 ` Marc Koschewski
2005-12-27 3:02 ` Marc Koschewski
2005-12-26 23:55 ` Linus Torvalds
2005-12-27 0:00 ` Benjamin Herrenschmidt
2005-12-27 1:20 ` Jules Villard
2005-12-27 1:27 ` Benjamin Herrenschmidt
2005-12-27 12:55 ` Jules Villard
2005-12-27 23:26 ` Benjamin Herrenschmidt
2005-12-28 6:16 ` Benjamin Herrenschmidt
2005-12-28 21:49 ` Linus Torvalds
2005-12-28 23:14 ` Benjamin Herrenschmidt
2005-12-27 1:19 ` Jules Villard
2005-12-27 1:27 ` Benjamin Herrenschmidt
2005-12-27 1:49 ` Benjamin Herrenschmidt [this message]
2005-12-27 12:14 ` Jules Villard
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=1135648173.4780.18.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=airlied@linux.ie \
--cc=akpm@osdl.org \
--cc=jvillard@ens-lyon.fr \
--cc=linux-kernel@vger.org \
--cc=torvalds@osdl.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