Hi Devin, On 01. 10. 21 21:08, Devin Steffler wrote: > Hi Rudolf, > > You're correct. Simply writing 0xa0 to 0xb2 will cause this. Great. (or not so). > I'm having a hard time figuring out what 0xb2 is. It seems like an I/O port that causes an SMI and sets APMC_EN=1. That's all that I could find so far. I have no idea yet what the bits in 0xa0 do. This is a software API to perform various functions not by ACPICA bytecode but by the machine code. It is kind of "backdoor" for BIOS programmers often misused. It was heavily used during APM era, but remained there. The whole system managemement mode is another mess. The SMI is more privileged than os, so it is ring -1 (OS is ring 0). Basically this allows BIOS to do "behind the scene" operation. 0xA0 is just API, it is invoke command "A0" in BIOS. And by a convention this command is to instruct BIOS that ACPICA aware OS is being used. To figure out what is really done, you would need to 1) get support for Mr. Lenovo - but not the ordinary support 2) unpack and disassemble/reverse engineer the BIOS to see what 0xA0 is really doing > Is this telling the BIOS that I have an APM aware OS (not ACPI)? If that's the case, then I have a feeling that my ACPICA should be instead doing something to say "I'm not APM aware" so that it doesn't try to do this. Or is being "APM aware" required for ACPI functionality since it's the successor to APM? On this system reading battery information works fine without this write to 0xb2. I would have to test on other devices as well to check if that's always the case or not. The A0 command tels the contrary it says to OS, I'm ACPI aware OS. And someone at Mr. Lenovo probably was clever to realize that they can maybe switch off something because legacy OS is not in use... > As a side note, in case it's relevant, I am setting the following in my ACPICA: > #define ACPI_OS_NAME                    "Microsoft Windows NT" > > That was done arbitrarily or perhaps out of laziness/lack of testing support. The comment above ACPI_OS_NAME suggests that it's obsolete anyways. Yes there are another horror stories for this. Basically BIOS programmers were testing on what ACPICA/OS they run with and do different things.Depending what OS was told. > Unfortunately, I don't see any option in the BIOS relating to clock gating or C11 power states. Thats bad. Try some more general power saving options. Does the behavior change if laptop is plugged to AC? > Should I pursue allowing the write but then disable the clock gating separately? I'm not sure how to do that yet. Yes you can try it out. But it is tricky. > > I started to learn about clock gating. I wanted to see if I could confirm that clock gating happens when 0xa0 is written to 0xb2. I stumbled on the following information from Intel: > Datasheet: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-2.pdf > ------------------------------------------------- > 30.2.20 ITSS Power Reduction Control (ITSSPRC)—Offset 3300h > Power controls for the entire interrupt and timer subsystem. > Bit 2: > "8254 Static Clock Gating Enable (CGE8254): When set, the 8254 timer is > disabled statically. This bit shall be set by BIOS if the 8254 feature is not needed in > the system or before BIOS hands off the system that supports C11. Normal operation > of 8254 requires this bit to 0." > ------------------------------------------------- Yes this is it. Unfortunately the register placement is not stable/same across systems. Intel tends to put it to various places. So like Apollo lake has it elsewhere etc. You need to look to a documentation which matches 100% your system. You can try to check this by comparing the PCI ids of various devices and checking them against datasheets. You can try to look to coreboot sources or some other opensource uefi implementation if they have support for your systems to see how the p2sb is done. > Unfortunately, I haven't been able to get access to that bit yet. The P2SB Bridge is hidden. I've found a way to get the SBREG_BAR from the P2SB Bridge in the QNX BSP. Yes. But maybe it is for another chipset. See above. >However, using it to read the ITSSPRC still returns 0xFFFFFFFF. I was hoping that I could clear that bit if it is getting set to test if that makes the PC speaker work >again. Hm 0xffffffff sounds way suspicious. I don't know what other bits do but it looks like you are looking to wrong place. Possible errors: 1) you did not map correct memory region 2) you did not map it uncached 3) you did not enable decoding of the region (maybe the P2SB has also command register where you might need to enable BAR decoding) 4) you did not use proper compiler things like "volatile" or compiler barriers and/or your access has been optimized out by the compiler 5) you did not read the register using correct register length > Part of this is a learning exercise for me, but part of it is also to get a proper fix for this system. If this is just an "APM thing" that shouldn't be enabled to begin with on my system, then I guess I need to figure out how to tell BIOS that this OS is "not APM aware". The ACPICA does correct thing. See above. >Either that, or just block 0xa0 writes to 0xb2 (but that feels like the wrong approach). Yes this is wrong approach, because BIOS will often generate SMIs and SCIs for many events. I'm afraid you need to do the write to 0xb2. Giving it more thoughts the clock gating might not be the only or correct problem to solve. If it is a laptop, I suspect that the legacy speaker goes to sound codec somehow and then to laptop speakers, and maybe BIOS switches off the sound codec (like puts it to D3 sleep). I don't know how the sound codec routing is usually done. You need to check it yourself. Do you have schematics of that system to check what the beeping output from the chipset really does? Thanks, Rudolf