Hi Rudolf,

You're correct. Simply writing 0xa0 to 0xb2 will cause this.

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.

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.

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.

Unfortunately, I don't see any option in the BIOS relating to clock gating or C11 power states.

Should I pursue allowing the write but then disable the clock gating separately? I'm not sure how to do that yet.

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."
-------------------------------------------------

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. 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.

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". Either that, or just block 0xa0 writes to 0xb2 (but that feels like the wrong approach).

Thanks,

Devin

On Thu, Sep 30, 2021 at 1:12 PM Rudolf Marek <r.marek@assembler.cz> wrote:

On 30. 09. 21 15:53, Devin Steffler wrote:
> Hello,
>
> Will Miles suggested that I monitor AcpiOsRead* and AcpiOsWrite* calls. I observed the following:
> ./test_sound # it plays fine
> ./acpica
> AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> AcpiOsReadPort: read 0x0 from 0x1804 with width 16
> AcpiOsWritePort: write 0xa0 to 0xb2 with width 8

This is likely the SMI_CMD and ACPI_ENABLE see my other mail.

> AcpiOsReadPort: read 0x1 from 0x1804 with width 16
> ./test_sound # it stops working
>
> To check if that write to 0xb2 is related, I modified AcpiOsWritePort to return AE_OK on all writes to Address 0xb2 without doing the actual write. I also modified AcpiOsReadPort to do a "fake read" of 1 when reading from port 0x1804 if there was a previous write to 0xb2. When I do this, then the beep continues to work and reading battery information via ACPI also continues to work (at least on this laptop, I haven't tested other devices yet).

Try vice versa, do not enable/use the ACPICA at all and write 0xa0 to 0xb2 to see if it breaks it.

> Looking at the PCH datasheet for the Intel i5 11357G CPU (what I'm using at the moment), it looks like writing to 0xb2 will trigger an SMI and set "APMC_EN =1" and is reported via APM_STS. Does this mean that it's supposed to activate power management and enable SMI interrupts for BIOS controlled power management (i.e. to be executed by ACPICA via SMI interrupt handlers)?

It tells BIOS, hey I'm ACPI aware OS stop messing around. And basically BIOS runs some unknown code in SMM when you just write to 0xb2 the 0xA0 command.
This unknown code can possibly enable the 8254 clock gating.

>I'm not sure why that would break the PC speaker. Could it be that my OSL interrupt handling is broken and BIOS was relying on it to re-enable the devices needed to use the PC speaker?

The PC speaker does not do anything with IRQs. The PIT has no architecturally defined way to be disabled. I don't know what Intel smokes but lets not inhale, intel invented the clock gating to make programers life more miserable (problem for TSC/lapic clock calibration when you have no HPET)

> Or could APMC_EN=1 also "turn off some devices (that the PC speaker requires) to save power as they won't be used by this OS"? Should I instead be looking at the ACPI tables for this laptop to see if something is being turned off to save power and figure out how to turn them back on via ACPI calls?

This is likely not the problem. The ACPI tables do not instruct the hardware, because you commented out above write. Also most hardware for chipset is memory mapped, not IOport mapped. Try what I wrote above. If it breaks, it confirms that BIOS is doing something behind the scene which is not even ACPICA related.

> The same section (22.4.5 SMI#/SCI Generation) in the datasheet also states things like the following:
> "The SCI is a level-mode interrupt that is typically handled by an ACPI-aware operating
> system. In non-APIC systems (which is the default), the SCI IRQ is routed to one of
> the 8259 interrupts (IRQ 9, 10, or 11). The 8259 interrupt controller must be
> programmed to level mode for that interrupt."

I don't think it is problem with SCI. See above.

The 8254 clock gating will slow down the PIT frequency 16x and it will stop legacy IRQ 0 (on PIC/IOAPIC) generation as a symptom of clock gating. This is not documented but it behaves like that. Yes again intel did not stop the counter completely to detect it but slowed down. Sigh.

Maybe it also affects PC speaker that it generates waveforms too slowly. You can also try to search BIOS option in setup menu for clock gating or try to disable C11 power state in there.

Yes it is mess.

Thanks,
Rudolf