Date: Fri, 22 Nov 2002 16:07:58 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: "Moore, Robert" <robert.moore@intel.com> Cc: acpi-jp@jp.FreeBSD.org, current@FreeBSD.org, Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Subject: RE: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.ta Message-ID: <XFMail.20021122160758.jhb@FreeBSD.org> In-Reply-To: <B9ECACBD6885D5119ADC00508B68C1EA0D19B937@orsmsx107.jf.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Nov-2002 Moore, Robert wrote:
> 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.
Thanks.
> 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/
--
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?XFMail.20021122160758.jhb>