Created attachment 302931 [details] dmesg log from 5.19.9 After upgrading kernel 5.19.10 from 5.19.9, the built-in keyboard of GPD Win Max2 does not work. I revert the commit(37c81d9f1d1b1458894454efcb857f6a769b6bc4) and rebuilt the kernel. The built-in keyboard of my laptop works again.
Created attachment 302932 [details] dmesg log from 5.19.10
Created attachment 302933 [details] acpidump -b
Created attachment 302934 [details] acpidump.output.log
(FYI this is the first Ryzen 6000 system that I've seen with an AMI BIOS) I see the date as 9/3/22, which is very recent. The DSDT for your BIOS sets up the _CRS using this macro: IRQNoFlags () {1} This macro expands as ActiveHigh, Edge-Triggered (https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_Language_Reference.html#irqnoflags-interrupt-resource-descriptor-macro) Other systems (including AMD's reference systems) set it up using this macro: IRQ (Edge, ActiveLow, Exclusive, ) {1} or this one: IRQ (Edge, ActiveLow, Shared, ) {1} In both cases this code triggers the override behavior in the kernel that 37c81d9f (in 5.19.y) and 9946e39f (in mainline) avoided for Zen systems that use the ActiveLow IRQ. You'll notice in your dmesg that "ACPI: IRQ 1 override to edge, low" happens on the older (working) kernel. As mentioned in 9946e39f there is a low level change in Ryzen 6000 that requires ActiveLow going forward for the keyboard IRQ. Fundamentally I think what is going on here is an BIOS bug from GPD. They should not be using the IRQNoFlags macro, but should instead use the modern extended IRQ descriptors or the IRQ macro. I will start some internal conversations at AMD to try to encourage the people who talk to the BIOS vendors to move to the modern extended IRQ descriptor syntax. The question ends up being what should we do about this for your system in Linux? There is a second system that popped up later that the Zen heuristic fails. If we pull the heuristic we're definitely going to have a list of systems that need to be added to the table. If we keep the heuristic we're going to have yours and another system to add to the table. Do you have a good contact to GPD that they could fix this in the BIOS for you? That's the best avenue in my opinion if possible.
(In reply to Mario Limonciello (AMD) from comment #4) > (FYI this is the first Ryzen 6000 system that I've seen with an AMI BIOS) > > I see the date as 9/3/22, which is very recent. > > The DSDT for your BIOS sets up the _CRS using this macro: > IRQNoFlags () {1} > > This macro expands as ActiveHigh, Edge-Triggered > (https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ > ACPI_Source_Language_Reference.html#irqnoflags-interrupt-resource-descriptor- > macro) > > Other systems (including AMD's reference systems) set it up using this macro: > IRQ (Edge, ActiveLow, Exclusive, ) {1} > or this one: > IRQ (Edge, ActiveLow, Shared, ) {1} > > In both cases this code triggers the override behavior in the kernel that > 37c81d9f (in 5.19.y) and 9946e39f (in mainline) avoided for Zen systems that > use the ActiveLow IRQ. > > You'll notice in your dmesg that "ACPI: IRQ 1 override to edge, low" happens > on the older (working) kernel. As mentioned in 9946e39f there is a low level > change in Ryzen 6000 that requires ActiveLow going forward for the keyboard > IRQ. > > Fundamentally I think what is going on here is an BIOS bug from GPD. They > should not be using the IRQNoFlags macro, but should instead use the modern > extended IRQ descriptors or the IRQ macro. > > I will start some internal conversations at AMD to try to encourage the > people who talk to the BIOS vendors to move to the modern extended IRQ > descriptor syntax. > > The question ends up being what should we do about this for your system in > Linux? There is a second system that popped up later that the Zen heuristic > fails. If we pull the heuristic we're definitely going to have a list of > systems that need to be added to the table. If we keep the heuristic we're > going to have yours and another system to add to the table. > > Do you have a good contact to GPD that they could fix this in the BIOS for > you? That's the best avenue in my opinion if possible. Ok, thanks, I will try to contact GPD.
Created attachment 302938 [details] patched dsdt.aml I patched the DSDT and upload it, maybe someone will use it before GPD fix. https://wiki.archlinux.org/title/DSDT#Using_modified_code
Hello Mario, Continuing from here: https://bugzilla.kernel.org/show_bug.cgi?id=216118#c10 I have GPD Win Max2 with AMD 6800U and I have tested the same as with 5.19.10 keyboard stops working. Here are the files you requested for. Win Max 2 dmesg Linux 6.0 https://paste.kodi.tv/axufamigec Win Max 2 dmesg Linux 5.19.9 https://paste.kodi.tv/jokaxeregu acpidump https://paste.kodi.tv/uvuqugilit In case needed. I will try to establish communication with GPD and see what they have to say. Thank you for the insight of the BIOS. Regards,
Update: Using updated Bios fixes this issue on 5.19.16 and 6.0 Version used: ARN28_Bios_Release_V1.03.02-221018 Tested on my device.