mismatch between FACP and chipset spec

[Andriy Gapon]

on 28/02/2008 20:17 Nate Lawson said the following:
> Andriy Gapon wrote:
>> As some of you probably already know I have a motherboard based on
>> 440BX/PIIX4E chipset:
>> http://www.geocities.com/SiliconValley/3686/delta_mp2.html
>>
>> Here's some info from ACPI tables:
>>         PM1a_EVT_BLK=0x4000-0x4003
>>         PM1a_CNT_BLK=0x4040-0x4041
>>         PM_TMR_BLK=0x4008-0x400b
>>
>> I know that in my case 0x4000 is a base address of "Power Management IO
>> Space" (as defined by PIIX4 specification).
>> I see that descriptions of the registers and their bits match between
>> ACPI specification and PIIX4 specification for registers in PM1a_EVT_BLK
>> (PMSTS and PMEN registers in PIIX4 parlance) and PM_TMR_BLK (PMTMP
>> register in PIIX4 parlance).
>> But addresses given for PM1a_CNT_BLK are not documented at all! On the
>> other hand ACPI description of that register perfectly matches
>> description of PIIX4 PMCNTRL register that is located at 0x4004 with a
>> given base address. So, this is 0x4040 vs. 0x4004, looks like a possible
>> typo/mistake by an author of ACPI tables for this motherboard.
> 
> 440BX is pretty old, and typos like that were common back then.  ACPI 
> was less used and drivers would just hardcode 0x4004 or whatever.
> 
>> Question: is there any way I can way override the address of
>> PM1a_CNT_BLK? My guess is that there is zero chance that there would be
>> any BIOS updates for this old and exotic motherboard (MP2-BX-X).
> 
> No generic way.  You'd have to add a quirk to acpi.c/acpi_quirks and use 
> that to override FADT.
> 
>> I think that this register is mostly useful for BM_RLD bit which is used
>> in C3 support. I don't use C3 (there is an errata for C3 with this
>> chipset and there is no PM2_CNT register defined anyway), but I am
>> curios anyway.
> 
> Seems like a lot of effort for no gain.  Since you are getting good at 
> debugging, can we get you newer hardware to play with?  :)

Nate,

thank you for pointing me to acpi_quirks and for confirming my doubts
over worthwhileness of this endeavor. And thanks for the compliment too :-)
As to the question that followed it - I am very "selfish" when it comes
to my FreeBSD contributions. That is, I use FreeBSD for a variety of
applications and my contributions are what I really need here and now.
And sometimes I really do need something, and sometimes it's just an "itch".
But I am thinking about getting a laptop soon. Of course I will install
FreeBSD on it, so it might be that something useful for other people
will come of it. Maybe someday (when I get a lot of free time) I will
even consider taking on hibernation.

>> And a mostly unrelated question. From the following code it seems that
>> linux won't go even into C2 state if there is any bus master activity
>> detected (but I am not what would happen with "demotion"/"promotion"):
>> http://lxr.linux.no/linux/drivers/acpi/processor_idle.c#L389
> 
> I don't think so.  I think cx->demotion.threshold.bm is a flag that says 
> whether the idle state the CPU is entering requires bus mastering 
> awareness.  It will probably only be set for C3.

Got it.


-- 
Andriy Gapon