[PATCH] fix S3 support on AMD K8 famF

[Rudolf Marek]

Hi all,

I think I fixed the S3 suspend/resume on AMD which was broken since Stephan did 
the change with cbmem :)

The patch does following:

1) wraps the s3 parts of chipset code/memory init code with if 
CONFIG_HAVE_ACPI_RESUME == 1 getting rid of ugly define in romstage.c

2) the patch implements get_cbmem_toc in chipset specific way if defined.
On Intel targets it should be unchanged. On K8T890 the the cbmem_toc is read 
from NVRAM. Why you ask? Because we cannot do it as on intel, because the 
framebuffer might be there making it hard to look for it in memory (and remember 
we need it so early that everying is uncached)

3) The patch removes hardcoded limits for suspend/resume save area (it was 1MB) 
on intel. Now it computes right numbers itself.

4) it impelements saving the memory during CAR to reserved range in sane way. 
First the sysinfo area (CAR data) is copied, then the rest after car is disabled 
(cached copy is used). I changed bit also the the copy of CAR area is now done 
uncached for target which I feel is more right.

I think I did not change the Intel suspend/resume behaviour but best would be if 
someone can test it. Please note this patch was unfinished on my drive since 
ages and it would be very nice to get it in to prevent bit rotten it again.
Now I feel it is done good way and should not break anything. I did a test with 
abuild and it seems fine.

The Rachmann did suspend/resume support for Asus M2V he will post the patch soon.

Signed-off-by: Rudolf Marek

Thanks,
Rudolf

[Tobias Diedrich]

Rudolf Marek wrote:
> Hi all,
>
> I think I fixed the S3 suspend/resume on AMD which was broken since 
> Stephan did the change with cbmem :)
>
> The patch does following:
> wraps the s3 parts of chipset code/memory init code with if
>
> CONFIG_HAVE_ACPI_RESUME == 1 getting rid of ugly define in romstage.c
> the patch implements get_cbmem_toc in chipset specific way if defined.
>
> On Intel targets it should be unchanged. On K8T890 the the cbmem_toc is 
> read from NVRAM. Why you ask? Because we cannot do it as on intel, 
> because the framebuffer might be there making it hard to look for it in 
> memory (and remember we need it so early that everying is uncached)
> The patch removes hardcoded limits for suspend/resume save area (it
>
> was 1MB) on intel. Now it computes right numbers itself.
> it impelements saving the memory during CAR to reserved range in sane
>
> way. First the sysinfo area (CAR data) is copied, then the rest after car 
> is disabled (cached copy is used). I changed bit also the the copy of CAR 
> area is now done uncached for target which I feel is more right.
>
> I think I did not change the Intel suspend/resume behaviour but best 
> would be if someone can test it. Please note this patch was unfinished on 
> my drive since ages and it would be very nice to get it in to prevent bit 
> rotten it again.
> Now I feel it is done good way and should not break anything. I did a 
> test with abuild and it seems fine.
>
> The Rachmann did suspend/resume support for Asus M2V he will post the patch soon.
>
> Signed-off-by: Rudolf Marek

Tested and works fine for me on my M2V with patch to add
board-specific init and dsdt parts.

Acked-by: Tobias Diedrich

[PATCH] S3 support for ASUS M2V

[Tobias Diedrich]

S3 support for ASUS M2V

This adds the board-specific parts for S3 support on the M2V board.

Signed-off-by: Tobias Diedrich

---

Index: src/mainboard/asus/m2v/dsdt.asl
===================================================================
--- src/mainboard/asus/m2v/dsdt.asl.orig	2010-11-22 01:00:33.000000000 +0100
+++ src/mainboard/asus/m2v/dsdt.asl	2010-11-22 01:23:53.000000000 +0100
@@ -59,10 +59,10 @@

/* _PR CPU0 is dynamically supplied by SSDT */

-	/* For now only define 2 power states:
+	/* We define 3 power states:
     *  - S0 which is fully on
+	 *  - S3 which is suspend to ram
     *  - S5 which is soft off
-	 * Any others would involve declaring the wake up methods.
     *
     * Package contents:
     * ofs len desc
@@ -73,6 +73,7 @@
     * 2   2   Reserved
     */
    Name (_S0, Package () { 0x00, 0x00, 0x00, 0x00 })
+	Name (_S3, Package () { 0x01, 0x01, 0x00, 0x00 })
    Name (_S5, Package () { 0x02, 0x02, 0x00, 0x00 })

/* Root of the bus hierarchy */
@@ -341,6 +342,7 @@

Device (SBRG) { /* southbridge */
    			Name (_ADR, 0x00110000)
+				OperationRegion (PCIC, PCI_Config, 0x0, 0x100)

/* PS/2 keyboard (seems to be important for WinXP install) */
    			Device (KBD)
@@ -459,9 +461,9 @@
    		}
    	}

-		OperationRegion (PCI0.SBRG.SBR1, PCI_Config, 0x55, 0x03)
-		Field (PCI0.SBRG.SBR1, ByteAcc, NoLock, Preserve)
+		Field (PCI0.SBRG.PCIC, ByteAcc, NoLock, Preserve)
    	{
+			Offset (0x55),
    		/*
    		 * Offset 0x55:
    		 *    3-0: reserved
@@ -538,4 +540,25 @@
 PCI_INTX_DEV(INTC, PINC, 3)
 PCI_INTX_DEV(INTD, PIND, 4)
    }
+
+	Field (_SB.PCI0.SBRG.PCIC, ByteAcc, NoLock, Preserve)
+	{
+		Offset (0x94),
+		/* two LSB bits are power led blink rate */
+		LEDR,   2,
+	}
+
+	Method (_PTS, 1, NotSerialized)
+	{
+		/* blink power led while suspended */
+		Store (0x1, LEDR)
+	}
+
+	Method (_WAK, 1, NotSerialized)
+	{
+		/* stop power led blinking */
+		Store (0x0, LEDR)
+		/* wake OK */
+		Return(Package(0x02){0x00, 0x00})
+	}
 }
Index: src/mainboard/asus/m2v/Kconfig
===================================================================
--- src/mainboard/asus/m2v/Kconfig.orig	2010-11-22 01:00:33.000000000 +0100
+++ src/mainboard/asus/m2v/Kconfig	2010-11-22 01:00:57.000000000 +0100
@@ -17,6 +17,7 @@
    select BOARD_ROMSIZE_KB_512
    select RAMINIT_SYSINFO
    select TINY_BOOTBLOCK
+	select HAVE_ACPI_RESUME
    select HAVE_PIRQ_TABLE
    select PIRQ_ROUTE
    select HAVE_ACPI_TABLES
Index: src/mainboard/asus/m2v/romstage.c
===================================================================
--- src/mainboard/asus/m2v/romstage.c.orig	2010-11-22 01:00:33.000000000 +0100
+++ src/mainboard/asus/m2v/romstage.c	2010-11-22 01:00:57.000000000 +0100
@@ -78,6 +78,15 @@
 #include "cpu/amd/dualcore/dualcore.c"
 #include "cpu/amd/car/post_cache_as_ram.c"
 #include "cpu/amd/model_fxx/init_cpus.c"
+
+// Now, this needs to be included because it relies on the symbol
+// __PRE_RAM__ being set during CAR stage (in order to compile the
+// BSS free versions of the functions). Either rewrite the code
+// to be always BSS free, or invent a flag that's better suited than
+// __PRE_RAM__ to determine whether we're in ram init stage (stage 1)
+//
+#include "lib/cbmem.c"
+
 #include "cpu/amd/model_fxx/fidvid.c"
 #include "northbridge/amd/amdk8/resourcemap.c"

@@ -247,6 +256,7 @@
    enable_rom_decode();
    m2v_bus_init();
    m2v_it8712f_gpio_init();
+	it8712f_enable_3vsbsw();

printk(BIOS_INFO, "now booting... \n");

[PATCH] S3 support for ASUS M2V

[Stefan Reinauer]

On 11/21/10 4:34 PM, Tobias Diedrich wrote:
> S3 support for ASUS M2V
>
> This adds the board-specific parts for S3 support on the M2V board.
>
> Signed-off-by: Tobias Diedrich

Nice! I'm surprised how small the patch is.

Acked-by: Stefan Reinauer

[Stefan Reinauer]

On 11/21/10 3:39 PM, Rudolf Marek wrote:
> the patch implements get_cbmem_toc in chipset specific way if defined.
>
> On Intel targets it should be unchanged. On K8T890 the the cbmem_toc
> is read from NVRAM. Why you ask? Because we cannot do it as on intel,
> because the framebuffer might be there making it hard to look for it
> in memory (and remember we need it so early that everying is uncached)

Can't we read the size of the framebuffer on resume? Maybe the register
is  connected to the resume power well?
> The patch removes hardcoded limits for suspend/resume save area (it
>
> was 1MB) on intel. Now it computes right numbers itself.

This is good. We should look into reducing this size on most platforms
though. I think some AMD boards use incredibly high numbers for RAM_TOP
> I think I did not change the Intel suspend/resume behaviour but best
> would be if someone can test it.

Unfortunately I can not, at the moment. Hopefully someone can step in?
> Please note this patch was unfinished on my drive since ages and it
> would be very nice to get it in to prevent bit rotten it again.
> Now I feel it is done good way and should not break anything. I did a
> test with abuild and it seems fine.
>
> The Rachmann did suspend/resume support for Asus M2V he will post the
> patch soon.
>
> Signed-off-by: Rudolf Marek

Awesome! Thanks a lot for cleaning up behind me ;)

Acked-by: Stefan Reinauer

Stefan

[Rudolf Marek]

> Can't we read the size of the framebuffer on resume? Maybe the register
> is  connected to the resume power well?

Nope it is not, and if we have a CMOS option for FB size we don't know how big 
it is. This solution is therefore most easy and straightforward.

Committed revision 6117.

Thanks,
Rudolf