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

[Devin Steffler <devinsteffler at gmail.com>]

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

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

I'm not really sure where to go from here. For this laptop, this might be a
suitable workaround for me as I'm only using ACPICA at the moment to read
battery information and for system shutdown. However, this might not be an
acceptable workaround for other devices (or if I end up needing other ACPI
functionality in the future that depends on this). I also suspect that my
OSL might be missing something that is causing this.

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)? 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?

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?

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

Thanks,
Devin

On Tue, Sep 28, 2021 at 3:04 PM Devin Steffler <devinsteffler(a)gmail.com>
wrote:

> Hello,
>
> I am using ACPICA to read battery information in QNX. That part is working
> great so far. However, now some code that is being used to make beeps via
> the PC speaker stopped working.
>
> Strangely, this code stops working on a few devices only after ACPICA
> runs. It works fine if I don't start ACPICA. The code is using I/O ports
> 0x43, 0x42, and 0x61 to generate beeps. This seems to be an industry
> standard way to make beeps on x86 based PCs using a Programmable Interval
> Timer (PIT).
>
> What could my ACPICA be doing (or failing to do) that could cause the
> beeps to stop working with the code below? Is the PIT being disabled
> somehow? I guess I'll need to learn more about the PIT and how to check its
> status to see if it's being disabled after ACPICA runs.
>
> Here's example code for QNX to generate a beep using the PC speaker:
> // -----------------------------------------------
> #include <sys/neutrino.h>
> #include <hw/inout.h>
> #include <unistd.h>
>
> int main(void) {
>     ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions
>
>     // start a beep
>     int freq = 1000;
>     int scale = 1193046 / freq;
>     out8(0x43, 0xb6);
>     out8(0x42, scale & 0xff);
>     out8(0x42, scale >> 8);
>     out8(0x61, in8(0x61) | 3);
>
>     // let the beep play for a second
>     delay(1000);
>
>     // stop the beep
>     out8(0x61, in8(0x61) & ~3);
>
>     return 0;
> }
> // -----------------------------------------------
>
> Thanks,
> Devin
>

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