From owner-acpi-jp@jp.FreeBSD.org Sat Nov 23 01:45:05 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id gAMGj5d85166;
	Sat, 23 Nov 2002 01:45:05 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id gAMGik283896;
	Sat, 23 Nov 2002 01:44:46 +0900 (JST)
	(envelope-from robert.moore@intel.com)
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id gAMGeDn13300;
	Fri, 22 Nov 2002 16:40:13 GMT
Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.27 2002/10/16 23:46:59 dmccart Exp $) with SMTP id gAMGlE100796;
	Fri, 22 Nov 2002 16:47:17 GMT
Received: from FMSMSX016.fm.intel.com ([132.233.42.195])
 by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002112208450707540
 ; Fri, 22 Nov 2002 08:45:07 -0800
Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <W6R5FNNB>; Fri, 22 Nov 2002 08:44:40 -0800
Message-ID: <B9ECACBD6885D5119ADC00508B68C1EA0D19B937@orsmsx107.jf.intel.com>
From: "Moore, Robert" <robert.moore@intel.com>
To: "'John Baldwin'" <jhb@freebsd.org>,
   "Moore, Robert"
	 <robert.moore@intel.com>
Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, current@freebsd.org,
   acpi-jp@jp.FreeBSD.org
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Fri, 22 Nov 2002 08:44:29 -0800
X-Sequence: acpi-jp 1972
Subject: [acpi-jp 1972] RE: Call for testers: acpica-unix-20021118.ta
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: robert.moore@intel.com
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+021111

Yes.  The spec appears to be ambiguous on this point.

I will change the GPE initialization so that if either the address or the
length are zero, the block is not supported.

This will appear in the next release of the code.

Bob


-----Original Message-----
From: John Baldwin [mailto:jhb@FreeBSD.org] 
Sent: Friday, November 22, 2002 7:58 AM
To: Moore, Robert
Cc: Mitsuru IWASAKI; current@FreeBSD.org; acpi-jp@jp.FreeBSD.org
Subject: RE: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.ta


On 22-Nov-2002 Moore, Robert wrote:
> 
> Unfortunately, the ACPI specification also says this:
> 
> "Each register block contains two registers of equal length: GPEx_STS and
> GPEx_EN (where x is 0 or 1). The length of the GPE0_STS and GPE0_EN
> registers is equal to half the GPE0_LEN. The length of the GPE1_STS and
> GPE1_EN registers is equal to half the GPE1_LEN. If a generic register
block
> is not supported then its respective block pointer and block length values
> in the FADT table contain zeros. The GPE0_LEN and GPE1_LEN do not need to
be
> the same size."
> 
> 
> I guess that we will have to code it this way -- if EITHER the GPE1_BLK or
> GPE1_BLK_LEN is zero, there is no GPE1.  Likewise with the GPE0 block.

Well, if you look at page 102 of the spec in the description of the FADT
fields, it says for GPE0_BLK and GPE1_BLK both that "if this register block
is not supported, this field contains zero", by which I take it to mean that
GPE[01]_BLK_LEN's values are undefined if the corresponding GPE[01]_BLK
values
are zero.

> Bob
> 
> 
> 
> -----Original Message-----
> From: Moore, Robert [mailto:robert.moore@intel.com] 
> Sent: Thursday, November 21, 2002 3:00 PM
> To: 'acpi-jp@jp.FreeBSD.org'; John Baldwin
> Cc: current@freebsd.org; Mitsuru IWASAKI
> Subject: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.tar .gz
> 
> 
> 
>       DSDT=0x3ffbf77
>       INT_MODEL=PIC
>       SCI_INT=9
>       SMI_CMD=0xb1, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
>       PM1a_EVT_BLK=0x1000-0x1003
>       PM1a_CNT_BLK=0x1004-0x1005
>       PM2_CNT_BLK=0x1030-0x1030
>       PM2_TMR_BLK=0x1008-0x100b
>       PM2_GPE0_BLK=0x1018-0x101b
>       P_LVL2_LAT=200ms, P_LVL3_LAT=2000ms
>       FLUSH_SIZE=0, FLUSH_STRIDE=0
>       DUTY_OFFSET=1, DUTY_WIDTH=3
>       DAY_ALRM=72, MON_ALRM=73, CENTURY=50
>       Flags={WBINVD,PROC_C1,SLP_BUTTON,TMR_VAL_EXT}
> 
> Juli, John,
> 
> This is interesting that no GPE1 information shows up.
> 
> It may be the case that GPE1_BLK is zero, but GPE1_BLK_LEN is not zero in
> the FADT.
> 
> According to the ACPI spec, only (GPE1_BLK == 0) indicates that there is
no
> GPE1 block;  It may be that if GPE1_BLK_LEN is non-zero, but GPE1_BLK is
> zero, the CA code is not handling this correctly.  I will investigate and
> report back.
> 
> Bob

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
