[Devel] Re: Question about ACPICA, QNX and making beeps

[Devin Steffler <devinsteffler at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6924 bytes --]

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(a)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
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 7949 bytes --]