Do you expect that the audio passthrough issues on Intel (e.g. NUC11PAHi)
The audio passthrough issue has been reported to Intel driver people but no one's in a hurry to fix it.
May I ask you which machine you own yourself or plan to purchase?
I own an Asrock J4105B-ITX (Gemini Lake) board. I plan to upgrade it at some point to a Tiger Lake based mini-ITX board (most likely Celeron 6305 or Pentium Gold 7505) when they are available.
Current work-in-progress HDR code from lrusak's git repo (which I use for my LE builds) does not work on AMD. No idea when or if it will ever work.
But the biggest concern should be AMD's linux GPU driver quality, which is kinda crap. I encountered some nasty issues when testing LE on Athlon 200GE APU with Vega graphics.
The audio passthrough issues on Intel are nothing compared to general crappiness of AMD drivers.
You are using the wrong branch 
I've used HDR on my AMD vega-m. It's very much WIP though. AMD drivers also don't expose the colorimetry property yet so there is no way to flag bt2020 to the monitor (this is apparently going to be implemented this year though).
Also, the AMD drivers (IMO) are some of the best.
Can a machine ever be too fast?
Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.
You are using the wrong branch
I used this one. Is it the right one? HDR worked on Gemini Lake and (reportedly) on Tiger Lake. Didn't work on Athlon 200GE.
Also, the AMD drivers (IMO) are some of the best.
Ok, but I can make a list of weird issues that are exclusive to AMD and not present on Intel.
Like this issue for example which I reported to AMD almost a year ago and it is still not fixed.
Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.
the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.
Once you can play everything at 4k60, the best platform then becomes the one which is most power efficient. IMHO.
Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC's like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC's. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up.
the Intel NUC7CJYH was the perfect platform IMO as it can do 4k60 with native HDMI 2.0 and it has a TDP of 10w.
Agreed. Its old enough that its price is a great value these days compared to newer NUCs. I have a ODROID H2+ which is very similar. I just can't use it d/t the audio issue for now.
Partially yes. But I also understand where Deezle is coming from. There is a difference running Kodi with just plain estuary w/ a tiny video library vs my Aeon Nox with alot of eye candy and a massive library to boot. SBC's like Vero 4k+ (which actually does everything playerwise i need) and others are not significantly faster except probably the I/O which helps a bit then when I was using a Zotac MAG more then 10 years ago. Its very noticeable while using the actual GUI compared to the more expensive x86 NUC's. Just need the software/drivers to finally get with the times because HW that was released about 3.5 years ago is capable of it. And thats just the GUI not to mention other possibilities like Deezle wanting to use it as a pic viewer and his SBC getting choked up
I just see a bit more benefit these days upgrading back end hardware (network, NAS etc) rather than trying to load up everything on a front end device, as an example look at how well the Netflix app works on your average Smart TV, there's not a lot of front end processing power required, because all the heavy lifting is done at the back end.
I still like Kodi, it's great for what it is don't get me wrong, but there's a lot of other UI's out there that get by just fine on potato SoC's too, and running x86 as a HTPC has always felt like too much overkill to me.
Well I had some time to work on the PN50 today.
I got stuck trying to setup my ir remote.
ir-keytable returns No devices found
and in dmesg it shows
[ 3.338380] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[ 3.338382] ite_cir: Using model: ITE8708 CIR transceiver
[ 3.338385] ite-cir 00:02: IR PNP Port not valid!Using LibreELEC (community): nightly-20210313-c5d7822
Any ideas?
PS Just saw 10.0 Beta 1 has been released. dmesg output is the same
I know my answer is not what you have asked for: But have you ever considered using a Flirc?
In case you don‘t know what a Flirc is:
A Flirc is a small USB plug which translates signals from any IR remote into keyboard presses. Makes it pretty easy to create a working keyboard.xml and the best is you don‘t have to hassle with ir-keytables. 
I have also tried following the same methodology described in
📡 Getting the Fintek IR receiver to work with Linux | @GregNau – Apps and Blog
&
Getting the IR receiver to work with Haswell NUCs - The NUC Blog
So for the PN50 I figure the commands should be:
modprobe -r ite-cir
echo "auto" > "/sys/bus/acpi/devices/ITE8708:00/physical_node/resources"
modprobe ite-cirAfter this, dmesg output remains the same:
[ 997.359200] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[ 997.359203] ite_cir: Using model: ITE8708 CIR transceiver
[ 997.359207] ite-cir 00:02: IR PNP Port not valid!and ir-keytable still returns No devices found.
1. There is one more direction to look at, that is this mail thread I found, regarding the PN50 specifically:
ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
Sadly, this mail thread never resolved to something, as far as I can tell. I am not sure, but I think it indicates the cir module in the PN50 is somewhat different than what the driver expects.
2. The /sys/bus/acpi/devices/ITE8708:00/physical_node/resources has the following contents:
state = active
io 0x280-0x28f
irq 10
dma disabledHowever, /proc/interrupts doesn't show IRQ 10 as being used:
pn50:~ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 38 0 0 0 IR-IO-APIC 2-edge timer
8: 0 0 1 0 IR-IO-APIC 8-edge rtc0
9: 0 1 0 0 IR-IO-APIC 9-fasteoi acpi
11: 0 0 0 0 IR-IO-APIC 11-edge AMDI0010:01
25: 0 0 0 0 PCI-MSI 4096-edge AMD-Vi
26: 0 0 0 0 IR-PCI-MSI 20480-edge PCIe PME
27: 0 0 0 0 IR-PCI-MSI 34816-edge PCIe PME
28: 0 0 0 0 IR-PCI-MSI 36864-edge PCIe PMESuccess
[ 4.677490] ite_cir: Auto-detected model: ITE8708 CIR transceiver
[ 4.677492] ite_cir: Using model: ITE8708 CIR transceiver
[ 4.677492] ite_cir: TX-capable: 1
[ 4.677493] ite_cir: Sample period (ns): 8680
[ 4.677493] ite_cir: TX carrier frequency (Hz): 38000
[ 4.677494] ite_cir: TX duty cycle (%): 33
[ 4.677494] ite_cir: RX low carrier frequency (Hz): 0
[ 4.677494] ite_cir: RX high carrier frequency (Hz): 0
[ 4.758949] rc rc0: lirc_dev: driver ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter
[ 4.759098] ite_cir: driver has been successfully loadedI am attaching the kernel patch I made
linux-9999-pn50.patch.txt
It was that email thread I posted earlier
ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
where the answer was hiding, but it took a lot of effort from my part.
First time building LibreELEC, first time writing a patch and so on.
ir-keytable now works correctly 
I'll need some help pushing this, at least as a patch to libreelec project, and possibly to the linux drivers. Can anyone help with this? pinging chewitt
As far as I can tell after digging through dozens of forums/posts/reddits this is the first publicly documented instance of the IR module in the PN50 actually working
If you'd like to learn sending something upstream I'm always happy to coach on the process - it's not that hard and we can review to spot the normal ettiquette mistakes before you send the patch. If not, I'd deferr to HiassofT who will understand what the change does - I don't code
I was thinking of a double approach:
1. Do a pull request on the LibreELEC github, with the above patch, so that it hopefuly becomes a part of the future stable LE 10.0
That way I can soon go back to using nightlies to further test the PN50 (at least until the next beta), instead of having to compile my own builds.
2. In addition, try to push this upstream to the appropriate linux mailing list, so that it becomes a part of the kernel drivers at some point, and possibly also backported (if that's an option). I'm not really sure how long that's going to take.
So for 1 I guess I'll do a PR on github. Does that sound good?
And for 2 I'll start by dropping an email on the linux-media list
Start with 2, and also send the email to Sean Young (he's the IR remote maintainer). When he acceptet your patch create a PR for LibreELEC, ideally with a link to the linux media patchwork URL.
so long,
Hias
Yes, I see what you mean.
According to that email thread it's the motherboard that is reporting the wrong register length of 16 in the ACPI tables
(while the device is still supposed to have an register length of 8 )
So by changing the register length to 16 in the driver, I am borking every other motherboard with correct ACPI tables, and possibly the PN50 in case a BIOS update fixes the value in the future.
I'll try your approach.
* It's a mystery to me how this ended up being an issue. It seems ASUS has been using the same ITE8708 since ages ago.
This thread has provided me many ideas on how to tackle my problem with my new PN62S, which appears to be the Intel version of the PN50. Looking for info on the ITE8708 led me here. While I still have not solved my issue yet, in appreciation of the work done so far, I thought I could share some of what I've tried/learned over the last week, which may trigger someone else's solution to their problem.
When I received my PN62S, the first thing I did before I even installed an OS was updated to the latest BIOS. I'm ultimately using this as a MythTV frontend, but started with a 20.04 Xubuntu minimal install to see what worked, and what didn't. I've updated the kernel to a 5.10. IR is one of the reasons I chose this unit. I use FLIRC on my main machine, but for something this tiny, I wanted to try and keep it more elegant. So when it wanted to play rough, I accepted the challenge.
I downloaded and installed Windows 10 on an old drive just to see if things truly worked, and they did. Without installing anything extra, a Microsoft remote "just worked". I confirmed my address space as 8 bytes (0x0680 - 0x0687) and IRQ (10) requirements from this side. Oh, and the Windows driver? From 2006 according to it's properties! So all of this is pointing me to your length issue as being an ASUS issue. Sure, a patch to ite-cir may work around it, but ultimately I think a BIOS update would be the proper solution (I'll get to that shortly).
So inspired by your conversation, I thought maybe updating the driver with your corrections might solve my issue. I've tried the length correction, the != correction, and both together with no change. Which didn't entirely surprise me because my problem seems to start at a lower level. The kernel seems to be aware enough that the device exists, but nothing in dmesg even hints at an attempt to load the driver. If I could get as far as your dmesg output, I'm sure the patch would solve my issue.
j@frontend:~$ lsmod | grep cir
ite_cir 28672 0
rc_core 61440 3 ite_cir,cec
j@frontend:~$ sudo ls -l /sys/bus/acpi/devices/ITE8708\:00/physical_node/
total 0
-r--r--r-- 1 root root 4096 Apr 28 19:47 ari_enabled
-rw-r--r-- 1 root root 4096 Apr 28 19:47 broken_parity_status
-r--r--r-- 1 root root 4096 Apr 28 19:47 class
-rw-r--r-- 1 root root 256 Apr 28 19:47 config
-r--r--r-- 1 root root 4096 Apr 28 19:47 consistent_dma_mask_bits
-rw-r--r-- 1 root root 4096 Apr 28 19:47 d3cold_allowed
-r--r--r-- 1 root root 4096 Apr 28 19:47 device
-r--r--r-- 1 root root 4096 Apr 28 19:47 dma_mask_bits
lrwxrwxrwx 1 root root 0 Apr 28 19:47 driver -> ../../../bus/pci/drivers/skl_uncore
-rw-r--r-- 1 root root 4096 Apr 28 19:47 driver_override
-rw-r--r-- 1 root root 4096 Apr 28 19:47 enable
lrwxrwxrwx 1 root root 0 Apr 28 19:47 firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ITE8708:00
-r--r--r-- 1 root root 4096 Apr 28 19:47 index
-r--r--r-- 1 root root 4096 Apr 28 19:47 irq
-r--r--r-- 1 root root 4096 Apr 28 19:47 label
drwxr-xr-x 2 root root 0 Apr 28 19:47 link
-r--r--r-- 1 root root 4096 Apr 28 19:47 local_cpulist
-r--r--r-- 1 root root 4096 Apr 28 19:47 local_cpus
-r--r--r-- 1 root root 4096 Apr 28 19:47 modalias
-rw-r--r-- 1 root root 4096 Apr 28 19:47 msi_bus
-rw-r--r-- 1 root root 4096 Apr 28 19:47 numa_node
drwxr-xr-x 2 root root 0 Apr 28 19:47 power
--w--w---- 1 root root 4096 Apr 28 19:47 remove
--w------- 1 root root 4096 Apr 28 19:47 rescan
-r--r--r-- 1 root root 4096 Apr 28 19:47 resource
-r--r--r-- 1 root root 4096 Apr 28 19:47 revision
lrwxrwxrwx 1 root root 0 Apr 28 19:47 subsystem -> ../../../bus/pci
-r--r--r-- 1 root root 4096 Apr 28 19:47 subsystem_device
-r--r--r-- 1 root root 4096 Apr 28 19:47 subsystem_vendor
-rw-r--r-- 1 root root 4096 Apr 28 19:47 uevent
-r--r--r-- 1 root root 4096 Apr 28 19:47 vendorWhat became key to me here is that in the relevant /sys/bus/acpi folder for this device is that I have no resources file (resource is something completely different). I also think because the BIOS marks that memory area as motherboard resources, it gets picked up by another driver when ite-cir doesn't grab it. So the lack of resources led me to investigate ACPI in the BIOS, thinking that it wasn't providing me the right information.
So lately I've been learning about ACPI and more specifically the DSDT table provided in the BIOS. And this is where it might lead to a fix for your length issue. Deep in this table (over 64k lines!), from my BIOS, is the definition for this device. I'd be interested to compare this against the definition in a PN50 ( 
After this I'm going to download the PN50 and see if there's anyway I can find the DSDT table in it!)
Device (CR00)
{
Name (_ADR, Zero) // _ADR: Address
Name (VBAN, 0x0680)
Name (VIRQ, 0x0A)
Name (UIDN, Zero)
Name (_HID, EisaId ("ITE8708")) // _HID: Hardware ID
Method (_UID, 0, NotSerialized) // _UID: Unique ID
{
Return (UIDN) /* \_SB_.PCI0.CR00.UIDN */
}
Method (_STA, 0, Serialized) // _STA: Status
{
If ((CIRE == Zero))
{
Return (Zero)
}
Return (0x0F)
}
Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0000, // Range Minimum
0x0000, // Range Maximum
0x01, // Alignment
0x08, // Length
_Y10)
IRQNoFlags (_Y11)
{}
DMA (Compatibility, NotBusMaster, Transfer8, )
{}
})
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MIN, IOPL) // _MIN: Minimum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MAX, IOPH) // _MAX: Maximum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y11._INT, IRQ) // _INT: Interrupts
IOPL = VBAN /* \_SB_.PCI0.CR00.VBAN */
IOPH = VBAN /* \_SB_.PCI0.CR00.VBAN */
IRQ = (One << VIRQ) /* \_SB_.PCI0.CR00.VIRQ */
Return (BUF0) /* \_SB_.PCI0.CR00._CRS.BUF0 */
}
}My length is defined as 0x08. If you were to check your DSDT table (see below for useful links), would it say that, or would it say 0x10? If this was the case, then I think this should be pointed out somehow to ASUS. An updated BIOS with a fix to this table could make the problem go away if this is the root cause.
Now in addition to finding this info, I've also learned that in addition to disassembling this and other ACPI tables, they can be modified and recompiled. Once recompiled, depending on your kernel build (and many may be built for this ... mine was, out of the box), the recompiled table can be loaded at boot time to be used instead of the one provided by the BIOS. It can be built into the kernel too apparently, but that's a lot more work.
I've tested this process with a couple things, like preventing the address from being reserved by the motherboard, in case that was preventing the right driver from grabbing it, and making sure the _STA method returned 0x0F, regardless of the BIOS setting for enabling CIR (CIRE). None of these fixed my problem, but showed me that a fix might be possible to implement.
If there is more interest in my pursuit, I can go into more detail, but I feel like I have probably already dragged on long enough for now. I've got a lot more to learn, but I'll leave you with some of the links (I've got a lot of open tabs right now!) I've found useful around working with ACPI:
Learned something potentially important about version number in this one:
ACPI AML debug and override ACPI tables using initrd - Programmer Sought
Getting my customized DSDT loaded in Xubuntu:
boot - Including a custom ACPI DSDT with (K)Ubuntu 18.04 (RC1) - Ask Ubuntu
So shortly after my last post, I found one of my open tabs contained this: ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
which seems to confirm what I was saying about the length in the PN50 DSDT table being 0x10, instead of 0x08. So, as an alternative to using the ite-cir patch (not trying to discredit the work done on that ... just giving another option), I'll walk through how I would approach this ACPI table.
Before you start this process though, check the following:
cat /boot/config-$(uname -r) | grep ACPI_TABLE_UPGRADE
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=yIf your kernel has this configuration, it will allow the loading of an updated ACPI table from a file (DSDT in this case). If not already present, you can build a kernel that can, but that goes against this being a "quick" fix. If it doesn't have this config, then the rest of this post won't be relevant.
Now, retrieve the DSDT table. I've made a new folder to try and keep the clutter down. (Can I ask a favour here ... could someone attach their DSDT file for a PN50 here? I'd like to compare it against my PN62S to see if I can figure out why the kernel really doesn't like my CIR. Thanks)
mkdir acpi
cd acpi
sudo cp /sys/firmware/acpi/tables/DSDT ./
sudo chown j:j DSDT // or be prepared to use sudo more oftenNow you need iasl, the ACPI Source Language compiler/decompiler. I was initially able to install a package (acpica-tools) on my system which contains this, but the version available in that package found errors during the ACPI compilation process. So I built the latest version from GitHub - acpica/acpica: The ACPI Component Architecture (ACPICA) project provides an open-source operating system-independent implementation of the Advanced Configuration and Power Interface specification (ACPI). For detailed project information and downloads, go to https://www.acpica.org. For ACPICA contributor and source code licensing information, go to and it didn't have a problem compiling a new ACPI table 
Once you have it installed, use it to disassemble the current DSDT table.
j@frontend:~/acpi$ iasl DSDT
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation
File appears to be binary: found 95539 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file DSDT, Length 0x449FF (281087) bytes
ACPI: DSDT 0x0000000000000000 0449FF (v02 ALASKA A M I 01072009 INTL 20160527)
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
Warning - Emitting ASL code "External (CIRE)"
This is a conflicting declaration with some other declaration within the ASL code.
This external declaration may need to be deleted in order to recompile the dsl file.
Warning - Emitting ASL code "External (COME)"
This is a conflicting declaration with some other declaration within the ASL code.
This external declaration may need to be deleted in order to recompile the dsl file.
Warning - Emitting ASL code "External (ESPC)"
This is a conflicting declaration with some other declaration within the ASL code.
This external declaration may need to be deleted in order to recompile the dsl file.
Warning - Emitting ASL code "External (PSON)"
This is a conflicting declaration with some other declaration within the ASL code.
This external declaration may need to be deleted in order to recompile the dsl file.
Disassembly completed
ASL Output: DSDT.dsl - 2051852 bytesThere's now a text file, DSDT.dsl, in the current folder, which is the source code for the DSDT table. This is the file that will be edited later to change the length reported to the kernel. I slightly overstated the file size last time, but my file is 62,293 lines.
I think there's a lot of clutter in this file. I suspect there's a lot of code in here meant for other machines, new code without looking for old code, etc., which possibly accounts for a lot of these errors. "Case" in point ... if I try to recompile what I just decompiled, without making any changes, it finds errors (using the -ve option only displays errors, otherwise they're hard to find among the 209 warnings and 536 remarks!). Several times there are Case statements for the same value.
j@frontend:~/acpi$ iasl -ve DSDT.dsl
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation
DSDT.dsl 61533: Case (0x03)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61489: Case (0x03)
DSDT.dsl 61537: Case (0x03)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61489: Case (0x03)
DSDT.dsl 61541: Case (0x30)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61497: Case (0x30)
DSDT.dsl 61569: Case (0x78)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61561: Case (0x78)
DSDT.dsl 61577: Case (0xA0)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61573: Case (0xA0)
DSDT.dsl 61639: Case (0x03)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61606: Case (0x03)
DSDT.dsl 61642: Case (0x03)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61606: Case (0x03)
DSDT.dsl 61645: Case (0x30)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61612: Case (0x30)
DSDT.dsl 61666: Case (0x78)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61660: Case (0x78)
DSDT.dsl 61672: Case (0xA0)
Error 6022 - Case value already specified ^
Original Case value below:
DSDT.dsl 61669: Case (0xA0)
ASL Input: DSDT.dsl - 2051852 bytes 29862 keywords 62295 source lines
Compilation failed. 10 Errors, 209 Warnings, 536 Remarks
No AML files were generated due to compiler error(s)Editing the file and removing the redundant Case statements solves this problem. That gave me a file that would compile:
j@frontend:~/acpi$ iasl -ve DSDT.dsl
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20210331
Copyright (c) 2000 - 2021 Intel Corporation
ASL Input: DSDT.dsl - 2050902 bytes 29847 keywords 62260 source lines
AML Output: DSDT.aml - 280440 bytes 24941 opcodes 4906 named objects
Compilation successful. 0 Errors, 209 Warnings, 536 Remarks, 618 OptimizationsThe DSDT.aml file is technically the new DSDT table that can be loaded by the kernel, although this one doesn't have any changes in it yet.
So go back to the editor and make the necessary changes. I haven't tried leaving the version as-is, but from what I've read it needs to be larger than the hardware version for this to work. So changing mine from 0x01072009 to 0x0107200A has worked in the past. Obviously, you will need to choose your value accordingly. This is located at the very start of the file (line 21).
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20210331 (64-bit version)
* Copyright (c) 2000 - 2021 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of DSDT, Thu Apr 29 15:14:50 2021
*
* Original Table Header:
* Signature "DSDT"
* Length 0x000449FF (281087)
* Revision 0x02
* Checksum 0xDD
* OEM ID "ALASKA"
* OEM Table ID "A M I "
* OEM Revision 0x01072009 (17244169)
* Compiler ID "INTL"
* Compiler Version 0x20160527 (538314023)
*/
DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)If you search for ITE8708, the device we're after, you should be led to it's definition in the file. Change the value on line 31 to 0x08.
Device (CR00)
{
Name (_ADR, Zero) // _ADR: Address
Name (VBAN, 0x0680)
Name (VIRQ, 0x0A)
Name (UIDN, Zero)
Name (_HID, EisaId ("ITE8708")) // _HID: Hardware ID
Method (_UID, 0, NotSerialized) // _UID: Unique ID
{
Return (UIDN) /* \_SB_.PCI0.CR00.UIDN */
}
Method (_STA, 0, Serialized) // _STA: Status
{
If ((CIRE == Zero))
{
Return (Zero)
}
Return (0x0F)
}
Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0000, // Range Minimum
0x0000, // Range Maximum
0x01, // Alignment
0x08, // Length
_Y10)
IRQNoFlags (_Y11)
{}
DMA (Compatibility, NotBusMaster, Transfer8, )
{}
})
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MIN, IOPL) // _MIN: Minimum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MAX, IOPH) // _MAX: Maximum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y11._INT, IRQ) // _INT: Interrupts
IOPL = VBAN /* \_SB_.PCI0.CR00.VBAN */
IOPH = VBAN /* \_SB_.PCI0.CR00.VBAN */
IRQ = (One << VIRQ) /* \_SB_.PCI0.CR00.VIRQ */
Return (BUF0) /* \_SB_.PCI0.CR00._CRS.BUF0 */
}
}Save the file and recompile it (iasl -ve DSDT.dsl). There shouldn't be any errors. Now the DSDT.aml file should contain the correct information to report to the kernel when loaded. Move this file to the /boot folder.
sudo cp DSDT.aml /bootNow the boot loader should be able to access the revised DSDT as the machine starts. Without getting into the various ways that boot loaders work (because I need to brush up on that myself), I have only interrupted my GRUB loader and manually added the acpi statement to the end:
initrd /boot/initrd.img-5.10.0-1023-oem
acpi /boot/DSDT.amlThe advantage of being able to load an .aml file is that if the config of the boot loader is such that the necessary statement is added automatically, upgrading a kernel shouldn't require any changes related to this. And if a BIOS update resolves the issue, then removing this from the boot process is all that it takes to clean up.
After booting, I can find evidence of the new table in dmesg. My new version number is present.
j@frontend:~$ dmesg | grep DSDT
[ 0.010373] ACPI: DSDT 0x0000000028A7C000 044778 (v02 ALASKA A M I 0107200A INTL 20210331)
[ 0.259601] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC used to handle transactions
[ 0.318901] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC initialization completeHope someone can find this useful. I've tried to be detailed enough, so it may look long, but once it's been done a couple times, I can make a change in a few minutes without rebuilding a driver or kernel, and reverting even quicker.
