Radeon acpi vgapost

Thses patches resume ATI radeon cards from acpi S3 suspend when using radeonfb by reposting the video bios. This is needed to be able to use S3 when the framebuffer is enabled.

Michael Marineau
[email protected]
Oregon State University

Generic function to post the video bios.

Based directly on the original patch by Ole Rohne.

Michael Marineau
[email protected]
Oregon State University

Index: linux-2.6.13-rc7/arch/i386/kernel/acpi/sleep.c
===================================================================
@@ -5,6 +5,7 @@
  *  Copyright (C) 2001-2003 Pavel Machek <[email protected]>
  */
 
+#include <linux/module.h>
 #include <linux/acpi.h>
 #include <linux/bootmem.h>
 #include <linux/dmi.h>

@@ -56,6 +57,34 @@ void acpi_restore_state_mem (void)
 	zap_low_mappings();
 }
 
+/*
+ * acpi_vgapost
+ */
+
+extern void do_vgapost_lowlevel (unsigned long);
+
+void acpi_vgapost (unsigned long slot)
+{
+	unsigned long flags, saved_video_flags = acpi_video_flags;
+
+	acpi_video_flags = (slot & 0xffff) << 16 | 1;
+
+	/* Map low memory and copy information */
+	init_low_mapping(swapper_pg_dir, USER_PTRS_PER_PGD);
+	memcpy((void *) acpi_wakeup_address, &wakeup_start, &wakeup_end - &wakeup_start);
+	acpi_copy_wakeup_routine(acpi_wakeup_address);
+
+	/* Tunnel thru real mode */
+	local_irq_save(flags);
+	do_vgapost_lowlevel(acpi_wakeup_address);
+	local_irq_restore(flags);
+
+	/* Restore mapping etc */
+	zap_low_mappings();
+	acpi_video_flags = saved_video_flags;
+}
+EXPORT_SYMBOL (acpi_vgapost);
+
 /**
  * acpi_reserve_bootmem - do _very_ early ACPI initialisation
  *

Hi!

(Just FYI, I already ACKed those patches, and I'll like them to go in after some testing in -mm).
Pavel

if you have sharp zaurus hardware you don't need... you know my address

Michael Marineau napsal(a):

Jiri Slaby         www.fi.muni.cz/~xslaby
~\-/~      [email protected]      ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

The wakeup.S code is missing a small piece of code.

For a lot of BIOSes you need to set ax to a PCI ID, I have code in my tree at the moment that does this:

in do_vgapost_lowlevel:
acpi_video_devnum = (pci_dev->bus->number<<8) | (pci_dev->devfn);

and then in the wakeup code
movl video_devnum-wakeup_code, %eax

The code is all in the patch at
http://www.skynet.ie/~airlied/patches/lk/my_pm_diffs
This is just a drop of my current tree from when I was hacking on suspend/resume at OLS.

Dave.

Ben, do I have your blessing on this one?

Adds the video post method of resume for x86 to radeonfb to allow for resuming after S3 acpi suspend.

Michael Marineau
[email protected]
Oregon State University

Index: linux-2.6.13-rc7/drivers/video/aty/radeon_pm.c
===================================================================
@@ -2403,6 +2403,15 @@ static void radeon_reinitialize_QW(struc
 
 #endif /* CONFIG_PPC_OF */
 
+#if defined(CONFIG_ACPI) && defined(CONFIG_X86)
+extern void acpi_vgapost (unsigned long slot);
+
+static void radeon_reinitialize_vgapost(struct radeonfb_info *rinfo)
+{
+	acpi_vgapost (rinfo->pdev->devfn);
+}
+#endif
+
 static void radeon_set_suspend(struct radeonfb_info *rinfo, int suspend)
 {
 	u16 pwr_cmd;

@@ -2657,6 +2666,8 @@ int radeonfb_pci_resume(struct pci_dev *
 		 */
 		else if (rinfo->pm_mode & radeon_pm_d2)
 			radeon_set_suspend(rinfo, 0);
+		if (rinfo->pm_mode & radeon_pm_post && rinfo->reinit_func != NULL)
+			rinfo->reinit_func(rinfo);
 
 		rinfo->asleep = 0;
 	} else

@@ -2777,6 +2788,13 @@ void radeonfb_pm_init(struct radeonfb_in
 #endif
 	}
 #endif /* defined(CONFIG_PM) && defined(CONFIG_PPC_OF) */
+
+#if defined(CONFIG_ACPI) && defined(CONFIG_X86)
+	if (rinfo->is_mobility && rinfo->pm_reg) {
+		rinfo->reinit_func = radeon_reinitialize_vgapost;
+		rinfo->pm_mode |= radeon_pm_post;
+	}
+#endif
 }
 
 void radeonfb_pm_exit(struct radeonfb_info *rinfo)

Index: linux-2.6.13-rc7/drivers/video/aty/radeonfb.h
===================================================================
@@ -271,6 +271,7 @@ enum radeon_pm_mode {
 	radeon_pm_none	= 0,		/* Nothing supported */
 	radeon_pm_d2	= 0x00000001,	/* Can do D2 state */
 	radeon_pm_off	= 0x00000002,	/* Can resume from D3 cold */
+	radeon_pm_post	= 0x00000004,	/* Resume with vgapost */
 };
 
 struct radeonfb_info {

Update documentation to reflect that this patch is now in the kernel.

Michael Marineau
[email protected]
Oregon State University

Index: linux-2.6.13-rc7/Documentation/power/video.txt
===================================================================
@@ -42,9 +42,9 @@ There are a few types of systems where v
   vbestate restore < /tmp/delme; setfont <whatever>, and your video
   should work.
 
-(7) on some systems, it is possible to boot most of kernel, and then
-  POSTing bios works. Ole Rohne has patch to do just that at
-  http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
+(7) on some systems, it is possible to POST the bios from within the
+  kernel which allows for the use of a framebuffer. The radeonfb incudes
+  this capability.
 
 Now, if you pass acpi_sleep=something, and it does not work with your
 bios, you'll get a hard crash during resume. Be careful. Also it is

Just wanted to report that these patches lead to progress on my T41p; relevant lspci -vvv:

0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) (prog-if 00 [VGA])
Subsystem: IBM: Unknown device 054f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 3000 [size=256]
Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
Capabilities: <available only to root>

In 2.6.13-rc7 or 2.6.13-rc6-mm2, after echo mem > /sys/power/state, the lcd light comes back, but no video is actually displayed (I just notice that the backlight turns on). With your patches, I now see (with either rc7 or rc6-mm2) a mostly black screen with "inux" in the upper left -- basically a garbled console -- which slowly turns completely white.

If you would like me to do more debugging, I would be more than happy to do so.

Thanks for the work so far,
Nish

I've seen the "inux" thing in the past, but by pressing a key shortly after the screen turns back on the system continued to resume as usual.
Given that the backlight normally turns back on for you maybe this post
method isn't the correct solution for your card. Mine wouldn't even turn on the backlight.

What is the behaviour when the framebuffer is not enabled? If in that case it doesn't work out of the box, does it work with a userspace trick like vbetool?

Michael Marineau
[email protected]
Oregon State University

Oh ok, thanks. I tried the keypress and nothing happened.

It definitely doesn't work OOB for me. I didn't know about vbetool before (I have messed with radeontool, though, when I told BenH about this problem a while ago).

Here is what I ended up with in my lidbtn.sh (when I wish to sleep-to-mem):

chvt 1 //vbetool needs to run from text console
echo mem > /sys/power/state
vbetool post //brings back video mode correctly
chvt 7 //return to X

This seems to work, if the framebuffer is not enabled.

radeontool's regs argument provides some useful information, I think. I have attache three files, radeontool.pre, radeontool.post and radeontool.postpost, which capture the output of radeontool regs before the suspend, after the suspend and after the vbetool command respectively. As you can see, there is a significant difference between .pre and .post and less of one between .pre and .postpost.

Perhaps also useful, I have attached the equivalent output with the fb enabled, in radeontool.fb.pre, radeontool.fb.post and radeontool.fb.postpost.

Thanks,
Nish

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0f000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=00770103
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0f000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=02000000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=08000008

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0d000048
RADEON_CRTC_GEN_CNTL=03000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=00770103
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000048
RADEON_CRTC_GEN_CNTL=03000200
RADEON_CRTC2_GEN_CNTL=02000000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=080c0089

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

These patches break resume from S3 for me. On a vanilla kernel, radeonfb comes back fine, with your patches applied, the backlight gets turned on (by BIOS I think) and shortly afterwards its turned off for good. (Radeon M11 on Sony Vaio)

 Manuel Lauss

Ok, attached is a patch to only attempt a vga post on Rv250 cards (M9) which I have in my laptop. I'm guessing cards older than M9 might also be helped with this patch, but better to be conservative than risk breaking systems that do work properly.

Michael Marineau
[email protected]
Oregon State University

Index: linux-2.6.13-rc7/drivers/video/aty/radeon_pm.c
===================================================================
@@ -2790,7 +2790,8 @@ void radeonfb_pm_init(struct radeonfb_in
 #endif /* defined(CONFIG_PM) && defined(CONFIG_PPC_OF) */
 
 #if defined(CONFIG_ACPI) && defined(CONFIG_X86)
-	if (rinfo->is_mobility && rinfo->pm_reg) {
+	if (rinfo->is_mobility && rinfo->pm_reg &&
+	     rinfo->family == CHIP_FAMILY_RV250) {
 		rinfo->reinit_func = radeon_reinitialize_vgapost;
 		rinfo->pm_mode |= radeon_pm_post;
 	}

Please don't make this unconditional. There's no guarantee whatsoever that the code at c000:0003 does anything useful on a laptop, and it may actually be harmful in some cases. The sensible approach is to whitelist it based on DMI entries or provide a sysfs attribute so userspace can enable/disable it.

How well does this patch deal with multihead? If I have a mixed radeon/non-radeon system, and the primary head is a non-radeon, won't this result in the wrong card being POSTed?

Matthew Garrett | [email protected]