Date: Thu, 28 Feb 2008 21:29:11 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: mismatch between FACP and chipset spec Message-ID: <47C70B87.5060301@icyb.net.ua> In-Reply-To: <47C6FACC.9090502@root.org> References: <47C67001.20101@icyb.net.ua> <47C6FACC.9090502@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C70B87.5060301>