From owner-acpi-jp@jp.freebsd.org  Tue Jan  2 13:23:17 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id NAA81405;
	Tue, 2 Jan 2001 13:23:17 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id NAA81310
	for <acpi-jp@jp.freebsd.org>; Tue, 2 Jan 2001 13:22:50 +0900 (JST)
	(envelope-from peter@netplex.com.au)
Received: from netplex.com.au (localhost [127.0.0.1])
	by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f024Mt806471;
	Mon, 1 Jan 2001 20:23:11 -0800 (PST)
	(envelope-from peter@netplex.com.au)
Message-Id: <200101020423.f024Mt806471@mobile.wemm.org>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: acpi-jp@jp.freebsd.org
cc: msmith@freebsd.org
Date: Mon, 01 Jan 2001 20:22:55 -0800
From: Peter Wemm <peter@netplex.com.au>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1013
Subject: [acpi-jp 1013] [PATCH] How to get acpica to work on a Sony VAIO PCG-F690..
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: peter@netplex.com.au

Mike Smith suggested that I send this patch here for comment.  There is a
bug in the acpica code in the write-with-rule code.  When executing
the SMI call AML code, it was executing this incorrectly:
Method(PHS0, 1) {
	Store(Arg0, BCMD)
	Store(Zero, SMIC)
	While(LEqual(BCMD, Arg0)) {
	}
	Store(0x0, BCMD)
}

The "Store(Zero, SMIC)" was actually being executed as:
Tempval = Read SMIC (8 bit quantity)
Tempval = (Tempval & 0xffffff00) | (Zero & 0x000000ff)
Store(Tempval, SMIC) (8 bit quantity)

It seems that *any* access to SMIC (0x8040 on my vaio) causes an SMI event
and the second call was breaking the while() loop causing it to spin forever
and lock up.

I added code to detect when the value written did not need need to preserve
old contents.  With my attached patch, it correctly writes an 8-bit zero
to the SMIC register once, instead of doing an 8-bit read followed by
an 8-bit write.

The diff also has code to fix some 32 bit vs 64 bit printfs for debugging
this section of code.

There is one outstanding problem.  If I use the BIOS setup and put the
CPU speed in 'Auto' mode, the system hangs at some random SMI call in the
same while() loop.  If I set the CPU speed to 'Full', it reliably boots.
I do not know why, I have done some detailed debug traces and can see no real
difference between the two cases.  The AML does not change either.  I am
continuing to investigate this.

Index: Interpreter/amfldio.c
===================================================================
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/Subsystem/Interpreter/amfldio.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 amfldio.c
--- Interpreter/amfldio.c	2000/12/21 06:56:40	1.1.1.4
+++ Interpreter/amfldio.c	2000/12/30 03:41:38
@@ -541,6 +541,7 @@
     ACPI_STATUS             Status = AE_OK;
     UINT32                  MergedValue;
     UINT32                  CurrentValue;
+    UINT32                  BitMask;
 
 
     /* Start with the new bits  */
@@ -549,6 +550,30 @@
 
     /* Check if update rule needs to be applied (not if mask is all ones) */
 
+    switch (BitGranularity) {
+    case 32:
+	BitMask = 0xffffffff;
+	break;
+    case 16:
+	BitMask = 0xffff;
+	break;
+    case 8:
+	BitMask = 0xff;
+	break;
+    case 0:
+	panic("BitGranularity = 0!");
+	BitMask = 0;
+	break;
+    default:
+	BitMask = (1UL << BitGranularity) - 1;
+	break;
+    }
+    /*
+     * If we are given the same or more bits than required, then write
+     * the bits that we are given as-is
+     */
+    if ((Mask & BitMask) == BitMask)
+	goto aligned;
 
     /* Decode the update rule */
 
@@ -590,6 +615,7 @@
         Status = AE_AML_OPERAND_VALUE;
     }
 
+aligned:
 
     /* Write the merged value */
 
Index: Interpreter/amregion.c
===================================================================
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/Subsystem/Interpreter/amregion.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 amregion.c
--- Interpreter/amregion.c	2000/12/21 06:56:41	1.1.1.4
+++ Interpreter/amregion.c	2000/12/29 19:42:17
@@ -250,7 +250,7 @@
     case ADDRESS_SPACE_READ:
 
         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
-            ("Read (%d width) Address=%p\n", BitWidth, Address));
+            ("Read (%d width) Address=%p\n", BitWidth, (u_int32_t)Address));
 
         switch (BitWidth)
         {
@@ -274,7 +274,7 @@
 
         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
             ("Write (%d width) Address=%p Value %X\n",
-            BitWidth, Address, *Value));
+            BitWidth, (u_int32_t)Address, *Value));
 
         switch (BitWidth)
         {
@@ -344,8 +344,8 @@
     case ADDRESS_SPACE_READ:
 
         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
-            ("Read(%d width) Address=%p\n", BitWidth, Address));
+            ("Read(%d width) Address=%p\n", BitWidth, (u_int32_t)Address));
 
         switch (BitWidth)
         {
         /* I/O Port width */
@@ -376,7 +397,7 @@
 
         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
             ("Write(%d width) Address=%p Value %X\n",
-            BitWidth, Address, *Value));
+            BitWidth, (u_int32_t)Address, *Value));
 
         switch (BitWidth)
         {

A sample from dmesg(8):
...
FreeBSD 5.0-CURRENT #43: Sun Dec 31 20:11:07 PST 2000
    peter@mobile.wemm.org:/home/src/sys/compile/MOBILE
Timecounter "i8254"  frequency 1193148 Hz
Timecounter "TSC"  frequency 843700763 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (843.70-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 134152192 (131008K bytes)
avail memory = 125992960 (123040K bytes)
...
acpi0: <SONY   K2      > on motherboard
acpi_tz0: <thermal zone> on acpi0
acpi_tz0: current temperature 65.9C
acpi_button0: <Control Method Power Button Device> on acpi0
acpi_pcib0: <Host-PCI bridge> on acpi0
pci0: <PCI bus> on acpi_pcib0
...
intpm0: PM I/O mapped 8000 
...
pccbb0: <RF5C478 PCI-CardBus Bridge> at device 12.0 on pci0
pccbb0: PCI Memory allocated: 18020000
pci_cfgintr_unique: hard-routed to irq 9
pci_cfgintr: 0:12 INTA routed to irq 9
cardbus0: <Cardbus bus (newcard)> on pccbb0
...
acpi_ec0: <embedded controller> on acpi0
acpi_cmbat0: <Control method Battery> on acpi0
acpi_cmbat1: <Control method Battery> on acpi0
acpi_acad0: <AC adapter> on acpi0
acpi_acad0: On Line
acpi_pr0: <processor device> on acpi0
acpi_pr0: supported power states: C0 (0us) C1 (0us) C2 (10us)
acpi_pr0: supported throttling states: 100% 87% 75% 62% 50% 37% 25% 12%
acpi_timer0: <24-bit timer at 3.579545MHz> on acpi0
...
dc0: <Abocom FE2500 10/100BaseTX> port 0x3000-0x30ff mem 0x18040000-0x1805ffff,0x18022000-0x180223ff irq 9 at device 0.0 on cardbus0
dc0: Ethernet address: 00:e0:98:8e:e5:d0
miibus0: <MII bus> on dc0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
...

All of the expected functionality works.. Power buttons cause a shutdown
etc.

How do we let Intel know about their bug?  There is an empty comment that
talks about doing this change but it had obviously not been implemented.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5

