Created attachment 191851 [details] DSDT I'm using a HP Omni 10 tablet with a Baytrail soc. The tablet has the usual home, power and volume buttons. The home + power buttons are working as expected but the volume buttons are not working. They are connected to a CrystalCove device, it seems to be very similar to the Asus T100TA: https://bugzilla.kernel.org/show_bug.cgi?id=90521 The volume buttons are detected ok but no interrupts are registered. Also when I try to register/read them manually via /sys/class/gpio the value will remain 0. Many thanks in advance! interrupts: CPU0 CPU1 CPU2 CPU3 16: 0 0 0 0 BYT-GPIO 6 home 158: 0 0 0 0 BYT-GPIO 16 power 207: 0 0 0 0 IO-APIC 67-fasteoi Crystal Cove 212: 0 0 0 0 Crystal Cove 5 gpio_crystalcove 213: 0 0 0 0 Crystal Cove 0 volume_down 214: 0 0 0 0 Crystal Cove 1 volume_up dsdt button array: GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullDefault, 0x0000, "\\_SB.GPO2", 0x00, ResourceConsumer, , ) { // Pin list 0x0010 } GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullDefault, 0x0000, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0006 } GpioInt (Edge, ActiveBoth, Exclusive, 0x80, 0x0000, "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, , ) { // Pin list 0x0001 } GpioInt (Edge, ActiveBoth, Exclusive, 0x80, 0x0000, "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, , ) { // Pin list 0x0000 } })
Also tested kernel v4.1.12 and v4.3 with the same result.
Created attachment 191961 [details] dmesg dmesg from startup to button detection.
Enabled: # Other I2C/SMBus bus drivers CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_BUS=y # Pin controllers CONFIG_PINCTRL_BAYTRAIL=y # MFD GPIO expanders CONFIG_GPIO_CRYSTAL_COVE=y # Multifunction device drivers CONFIG_INTEL_SOC_PMIC=y But there isn't even any I2C traffic generated from pushing the volume rocker, the other buttons do. Maybe this chip is actually disabled or sleeping or something? With Windows the volume rocker is working just fine. Help or suggestions would be really welcome! :)
Note that the DSDT you've attached has two PBUF entries for _CRS. Please, try to boot with modified DSDT with removed the first one.
(In reply to Pavel Bludov from comment #4) > Note that the DSDT you've attached has two PBUF entries for _CRS. > Please, try to boot with modified DSDT with removed the first one. Hi Palev, Thanks for your reply. Could you please be a little more specific? My knowledge about DSDT disassembly is limited and I can't seem to find where you are referring to. Thanks in advance!
Take a look at http://git.ao2.it/Teclast-X98-Air-3G_C6J6_custom_DSDT.git/ The Makefile contains commands to compile/decompile DSDT. All commits are self-explaining. The DSDT/SSDT tables are here: /sys/firmware/acpi/tables You can simple cp them as root user. Also there is a lot of "Mac-on-PC" forums about this issue in the web.
Hi Pavel, Thanks again for all the information but I was actually wondering where you saw the duplicate PBUF / CSR entry in the disassembly. Maybe you have line numbers or another pointer?
Hi, I think you where referring to the Device (TBAD) declaration at line 11104. It has two ResourceTemplates of which the first one (RBUF) is unconditionally returned. For testing I switched it to PBUF and resolved all the warnings and remarks but that didn't help. Also changing the pull type did not work.
(In reply to jjmeijer88 from comment #7) > Maybe you have line numbers or another pointer? The lines are 10830-10890. I was a bit wrong: they are PBUF and RBUF. The last one (PBUF) is not referenced. Please, try to replace Return (RBUF) with Return (PBUF)
(In reply to Pavel Bludov from comment #9) > (In reply to jjmeijer88 from comment #7) > > Maybe you have line numbers or another pointer? > > The lines are 10830-10890. I was a bit wrong: they are PBUF and RBUF. > The last one (PBUF) is not referenced. Please, try to replace > Return (RBUF) > with > Return (PBUF) Thanks, I tried it but it didn't help. The first template also makes more sense because I don't have a mute switch (the 5th gpio declaration in the Windows button array). Is there anything I could change to the configuration of the pins or is there a way to check it's actually a different pin number? I could imagine there are more people who need to determine pin numbers for black box devices.
I made a strange observation and I hope maybe it will trigger someone... In Grub2 if I hold vol+/vol- for a couple of seconds the cursor will start moving up. Is there some way I can use this to my advantage? It would be really nice to have the volume rocker working in Linux.
Hi, I decided to give it another go and found something strange: if I remove the buttons in the DSDT file from the Windows button array declaration these GPIO will start generating interrupts: ...... 212: 0 0 0 0 Crystal Cove 5 gpio_crystalcove 213: 0 0 0 10 Crystal Cove 0 214: 0 0 0 12 Crystal Cove 1 ...... But of course now these interrupts are not mapped anymore to the correct actions. I'm not sure if there is a conflict somewhere or the buttons get mis-configured by the soc button array driver or something completely different.
I removed both gpio_keys and soc_button_array modules and wrote my own little module. It just attach some handlers to the irq of all four buttons writing logging events with printk: static irqreturn_t handler(int irq, void *dummy) { printk(KERN_ALERT "Button event!\n"); return IRQ_HANDLED; } #define IRQ_BUTTON_FLAGS (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_SHARED) irq = gpio_to_irq(gpio); request_irq(irq, handler, IRQ_BUTTON_FLAGS, name, button_dev); This works fine for home + power but vol + / - returns always -22 (EINVAL). I did validate the GPIO numbers with /sys/class/gpio: I can manually read the GPIO values. Another problem is that at some random boots the button interrupts are not fired anyway. Some help or tips to provide better debug logs would be very welcome.
I Cc'ed this to Hans, who probably knows and possibly even fixed this if it wasn't working.
(In reply to Andy Shevchenko from comment #14) > I Cc'ed this to Hans, who probably knows and possibly even fixed this if it > wasn't working. I don't have any memory of fixing this. But I just checked and I do have an "Acer Iconia W4-820" tablet which also has its volume buttons connected to gpio 0 + 1 on the crystal-cove pmic and there the volume buttons work fine. So either there is something special about the HP Omni 10 tablet, or this has been fixed in the mean time.
Closed based on the comment #15. If it is reproducible on the new kernels (v6.1.y as of today), feel free to reopen with a new information provided.