Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Nov 2002 08:44:29 -0800
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
Subject:   RE: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.ta
Message-ID:  <B9ECACBD6885D5119ADC00508B68C1EA0D19B937@orsmsx107.jf.intel.com>

next in thread | raw e-mail | index | archive | help
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/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9ECACBD6885D5119ADC00508B68C1EA0D19B937>