* "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 @ 2015-01-31 15:01 Sebastien Bourdeauducq 2015-01-31 20:39 ` Benjamin Tissoires 0 siblings, 1 reply; 12+ messages in thread From: Sebastien Bourdeauducq @ 2015-01-31 15:01 UTC (permalink / raw) To: linux-input Hi, among the many problems that the Baytrail-based Thinkpad Tablet 10 has under Linux, the built-in Wacom digitizer does not work. I get the following messages in the kernel log (with i2c_hid.debug=1): [ 593.224249] i2c_hid i2c-WCOM0008:00: Fetching the HID descriptor [ 593.224259] i2c_hid i2c-WCOM0008:00: __i2c_hid_command: cmd=01 00 [ 593.243080] i2c_hid i2c-WCOM0008:00: HID Descriptor: 1e 00 00 01 ee 00 02 00 03 00 0a 00 00 00 00 00 04 00 05 00 6a 05 14 01 02 03 00 00 00 00 [ 593.243110] i2c_hid i2c-WCOM0008:00: Could not register for WCOM0008:00 interrupt, irq = -1, ret = -22 [ 593.253422] i2c_hid: probe of i2c-WCOM0008:00 failed with error -22 What should I look at? Sebastien ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-01-31 15:01 "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 Sebastien Bourdeauducq @ 2015-01-31 20:39 ` Benjamin Tissoires 2015-02-01 3:27 ` Sebastien Bourdeauducq 0 siblings, 1 reply; 12+ messages in thread From: Benjamin Tissoires @ 2015-01-31 20:39 UTC (permalink / raw) To: Sebastien Bourdeauducq; +Cc: linux-input, Mika Westerberg Hi, On Sat, Jan 31, 2015 at 10:01 AM, Sebastien Bourdeauducq <sb@m-labs.hk> wrote: > Hi, > > among the many problems that the Baytrail-based Thinkpad Tablet 10 has under > Linux, the built-in Wacom digitizer does not work. I get the following > messages in the kernel log (with i2c_hid.debug=1): > > [ 593.224249] i2c_hid i2c-WCOM0008:00: Fetching the HID descriptor > [ 593.224259] i2c_hid i2c-WCOM0008:00: __i2c_hid_command: cmd=01 00 > [ 593.243080] i2c_hid i2c-WCOM0008:00: HID Descriptor: 1e 00 00 01 ee 00 02 > 00 03 00 0a 00 00 00 00 00 04 00 05 00 6a 05 14 01 02 03 00 00 00 00 > [ 593.243110] i2c_hid i2c-WCOM0008:00: Could not register for WCOM0008:00 > interrupt, irq = -1, ret = -22 That means that your tablet is the first one we (maybe only I) see that uses a GPIO as an interrupt :) Mika sent a patch recently which should solve your problem. Can you give a try to the following patch? https://patchwork.kernel.org/patch/5709961/ > [ 593.253422] i2c_hid: probe of i2c-WCOM0008:00 failed with error -22 > > What should I look at? > So if you can test the above patch, that would help. If it does not work, we will need to check the DSDT of your tablet. Cheers, Benjamin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-01-31 20:39 ` Benjamin Tissoires @ 2015-02-01 3:27 ` Sebastien Bourdeauducq 2015-02-02 10:00 ` Mika Westerberg 0 siblings, 1 reply; 12+ messages in thread From: Sebastien Bourdeauducq @ 2015-02-01 3:27 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: linux-input, Mika Westerberg Hi, On Sunday, February 01, 2015 04:39 AM, Benjamin Tissoires wrote: > Mika sent a patch recently which should solve your problem. > Can you give a try to the following patch? > https://patchwork.kernel.org/patch/5709961/ With this patch and IRQF_TRIGGER_LOW | IRQF_ONESHOT, I get an interrupt flood and the kernel disables the interrupt line. I have reverted it to IRQF_TRIGGER_FALLING | IRQF_ONESHOT, and the i2c_hid initialization completes successfully. The next problem is that the tablet has product ID 0x0114 and this is not recognized by the wacom_wac driver. I have added those entries in it: static const struct wacom_features wacom_features_0x114 = { "Wacom ISDv4 114", 26202, 16325, 255, 0, TABLETPCE, WACOM_INTUOS_RES, WACOM_INTUOS_RES }; ... #define ANY_DEVICE_WACOM(prod) \ HID_DEVICE(HID_BUS_ANY, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\ .driver_data = (kernel_ulong_t)&wacom_features_##prod ... { ANY_DEVICE_WACOM(0x114) }, I am just guessing here and copied the existing entry for product ID 0x116. I don't know if those numbers are correct - also, should I have used the existing USB_DEVICE_WACOM macro instead of defining ANY_DEVICE_WACOM? After those changes, I'm able to move the mouse pointer only once (and to the correct position) using the stylus, after which the digitizer crashes and becomes inoperable until a reboot. Unloading and reloading i2c_hid results in a "failed to reset device" message. I have copied my DSDT entry below. Thanks, Sebastien Device (DIGI) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "WCOM0008") // _HID: Hardware ID Name (_CID, "PNP0C50") // _CID: Compatible ID Name (_DDN, "Digitizer") // _DDN: DOS Device Name Name (_UID, One) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBus (0x0009, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C3", 0x00, ResourceConsumer, , ) GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0038 } }) Return (RBUF) } Method (_STA, 0, NotSerialized) // _STA: Status { If (LEqual (And (COMP, 0x04), 0x04)) { Return (0x0F) } Else { Return (Zero) } } Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store ("Method _DSM begin", Debug) While (One) { Name (_T_0, Buffer (One) // _T_x: Emitted by ASL Compiler { 0x00 }) CopyObject (ToBuffer (Arg0), _T_0) If (LEqual (_T_0, Buffer (0x10) { /* 0000 */ 0xF7, 0xF6, 0xDF, 0x3C, 0x67, 0x42, 0x55, 0x45, /* 0008 */ 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE })) { While (One) { Name (_T_1, Zero) // _T_x: Emitted by ASL Compiler Store (ToInteger (Arg2), _T_1) If (LEqual (_T_1, Zero)) { While (One) { Name (_T_2, Zero) // _T_x: Emitted by ASL Compiler Store (ToInteger (Arg1), _T_2) If (LEqual (_T_2, One)) { Store ("Method _DSM Function Query", Debug) Return (Buffer (One) { 0x03 }) } Else { Return (Buffer (One) { 0x00 }) } Break } } Else { If (LEqual (_T_1, One)) { Store ("Method _DSM Function HID", Debug) Return (One) } Else { Return (Zero) } } Break } } Else { Return (Buffer (One) { 0x00 }) } Break } } } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-01 3:27 ` Sebastien Bourdeauducq @ 2015-02-02 10:00 ` Mika Westerberg 2015-02-02 13:19 ` Sebastien Bourdeauducq 0 siblings, 1 reply; 12+ messages in thread From: Mika Westerberg @ 2015-02-02 10:00 UTC (permalink / raw) To: Sebastien Bourdeauducq; +Cc: Benjamin Tissoires, linux-input On Sun, Feb 01, 2015 at 11:27:09AM +0800, Sebastien Bourdeauducq wrote: > Hi, > > On Sunday, February 01, 2015 04:39 AM, Benjamin Tissoires wrote: > >Mika sent a patch recently which should solve your problem. > >Can you give a try to the following patch? > >https://patchwork.kernel.org/patch/5709961/ > > With this patch and IRQF_TRIGGER_LOW | IRQF_ONESHOT, I get an interrupt > flood and the kernel disables the interrupt line. I have reverted it to > IRQF_TRIGGER_FALLING | IRQF_ONESHOT, and the i2c_hid initialization > completes successfully. That shouldn't happen :-( On all the panels I've tried, with or without GPIO, turning the interrupt to active low works. How about Windows, have you tried if it works there? > The next problem is that the tablet has product ID 0x0114 and this is not > recognized by the wacom_wac driver. I have added those entries in it: > > static const struct wacom_features wacom_features_0x114 = > { "Wacom ISDv4 114", 26202, 16325, 255, 0, > TABLETPCE, WACOM_INTUOS_RES, WACOM_INTUOS_RES }; > ... > #define ANY_DEVICE_WACOM(prod) \ > HID_DEVICE(HID_BUS_ANY, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\ > .driver_data = (kernel_ulong_t)&wacom_features_##prod > ... > { ANY_DEVICE_WACOM(0x114) }, > > I am just guessing here and copied the existing entry for product ID 0x116. > I don't know if those numbers are correct - also, should I have used the > existing USB_DEVICE_WACOM macro instead of defining ANY_DEVICE_WACOM? > > After those changes, I'm able to move the mouse pointer only once (and to > the correct position) using the stylus, after which the digitizer crashes > and becomes inoperable until a reboot. Unloading and reloading i2c_hid > results in a "failed to reset device" message. > > I have copied my DSDT entry below. > > Thanks, > Sebastien > > Device (DIGI) > { > Name (_ADR, Zero) // _ADR: Address > Name (_HID, "WCOM0008") // _HID: Hardware ID > Name (_CID, "PNP0C50") // _CID: Compatible ID > Name (_DDN, "Digitizer") // _DDN: DOS Device Name > Name (_UID, One) // _UID: Unique ID > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Name (RBUF, ResourceTemplate () > { > I2cSerialBus (0x0009, ControllerInitiated, 0x00061A80, > AddressingMode7Bit, "\\_SB.I2C3", > 0x00, ResourceConsumer, , > ) > GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000, > "\\_SB.GPO0", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0038 > } Yup, looks pretty much what I've seen. Can you send output of /sys/kernel/debug/gpio when after the kernel has disabled the interrupt? > }) > Return (RBUF) > } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 10:00 ` Mika Westerberg @ 2015-02-02 13:19 ` Sebastien Bourdeauducq 2015-02-02 13:48 ` Mika Westerberg 0 siblings, 1 reply; 12+ messages in thread From: Sebastien Bourdeauducq @ 2015-02-02 13:19 UTC (permalink / raw) To: Mika Westerberg; +Cc: Benjamin Tissoires, linux-input [-- Attachment #1: Type: text/plain, Size: 987 bytes --] On Monday, February 02, 2015 06:00 PM, Mika Westerberg wrote: >> With this patch and IRQF_TRIGGER_LOW | IRQF_ONESHOT, I get an interrupt >> flood and the kernel disables the interrupt line. I have reverted it to >> IRQF_TRIGGER_FALLING | IRQF_ONESHOT, and the i2c_hid initialization >> completes successfully. > > That shouldn't happen :-( With this computer nothing is normal. Every single component except the CPU, display and USB has major issues under Linux. > On all the panels I've tried, with or without GPIO, turning the > interrupt to active low works. How about Windows, have you tried if it > works there? Yes, the Wacom digitizer works fine under Windows. > Can you send output of /sys/kernel/debug/gpio when after the kernel has > disabled the interrupt? Attached. The kernel message I get is "byt_gpio INT33FC:00: Gpio 56 interrupt flood, disabling". I also get a "byt_gpio INT33FC:02: Gpio 18 interrupt flood, disabling" before which seems unrelated. Sebastien [-- Attachment #2: gpio.txt --] [-- Type: text/plain, Size: 16905 bytes --] GPIOs 338-381, platform/INT33FC:02, INT33FC:02: gpio-0 (Unrequested ) in lo pad-29 offset:0x1d0 mux:0 rise level down 20k gpio-1 (Unrequested ) in hi pad-33 offset:0x210 mux:0 fall level up 20k gpio-2 (Unrequested ) in hi pad-30 offset:0x1e0 mux:0 up 20k gpio-3 (Unrequested ) in hi pad-31 offset:0x1f0 mux:0 fall level up 20k gpio-4 (Unrequested ) in lo pad-32 offset:0x200 mux:0 rise down 20k gpio-5 (Unrequested ) in lo pad-34 offset:0x220 mux:1 down 20k gpio-6 (Unrequested ) out lo pad-36 offset:0x240 mux:0 gpio-7 (Unrequested ) in lo pad-35 offset:0x230 mux:1 down 20k gpio-8 (Unrequested ) in lo pad-38 offset:0x260 mux:0 rise level down 20k gpio-9 (ACPI:Event ) in hi pad-37 offset:0x250 mux:0 fall rise up 20k gpio-10 (Unrequested ) out lo pad-18 offset:0x120 mux:0 gpio-11 (Unrequested ) in lo pad-7 offset:0x070 mux:0 down 20k gpio-12 (Unrequested ) in hi pad-11 offset:0x0b0 mux:1 fall level gpio-13 (Unrequested ) in hi pad-20 offset:0x140 mux:0 down 20k gpio-14 (ACPI:Event ) in hi pad-17 offset:0x110 mux:1 fall rise up 20k gpio-15 (Unrequested ) in lo pad-1 offset:0x010 mux:1 rise level gpio-16 (Unrequested ) in hi pad-8 offset:0x080 mux:1 fall rise gpio-17 (Unrequested ) in hi pad-10 offset:0x0a0 mux:1 fall level up 20k gpio-18 (ACPI:Event ) in lo pad-19 offset:0x130 mux:1 up 20k gpio-19 (Unrequested ) in hi pad-12 offset:0x0c0 mux:0 up 20k gpio-20 (ACPI:OpRegion ) in out hi pad-0 offset:0x000 mux:1 gpio-21 (Unrequested ) in out hi pad-2 offset:0x020 mux:1 gpio-22 (ACPI:OpRegion ) in out hi pad-23 offset:0x170 mux:0 gpio-23 (Unrequested ) lo pad-39 offset:0x270 mux:0 gpio-24 (Unrequested ) lo pad-28 offset:0x1c0 mux:0 gpio-25 (Unrequested ) lo pad-27 offset:0x1b0 mux:0 gpio-26 (Unrequested ) lo pad-22 offset:0x160 mux:0 gpio-27 (Unrequested ) in hi pad-21 offset:0x150 mux:0 fall rise up 20k gpio-28 (Unrequested ) in hi pad-24 offset:0x180 mux:0 fall rise up 20k gpio-29 (Unrequested ) in out hi pad-25 offset:0x190 mux:0 gpio-30 (Unrequested ) in out hi pad-26 offset:0x1a0 mux:0 gpio-31 (Unrequested ) in lo pad-51 offset:0x330 mux:1 down 20k gpio-32 (Unrequested ) in lo pad-56 offset:0x380 mux:1 down 20k gpio-33 (Unrequested ) in lo pad-54 offset:0x360 mux:1 down 20k gpio-34 (Unrequested ) in lo pad-49 offset:0x310 mux:1 down 20k gpio-35 (Unrequested ) in lo pad-55 offset:0x370 mux:1 down 20k gpio-36 (Unrequested ) in lo pad-48 offset:0x300 mux:1 down 20k gpio-37 (Unrequested ) in lo pad-57 offset:0x390 mux:1 down 20k gpio-38 (Unrequested ) in lo pad-50 offset:0x320 mux:1 down 20k gpio-39 (Unrequested ) in lo pad-58 offset:0x3a0 mux:1 down 20k gpio-40 (Unrequested ) in lo pad-52 offset:0x340 mux:1 up 20k gpio-41 (Unrequested ) in lo pad-53 offset:0x350 mux:1 down 20k gpio-42 (Unrequested ) in lo pad-59 offset:0x3b0 mux:1 up 20k gpio-43 (Unrequested ) in lo pad-40 offset:0x280 mux:1 down 20k GPIOs 382-409, platform/INT33FC:01, INT33FC:01: gpio-0 (Unrequested ) in lo pad-19 offset:0x130 mux:2 gpio-1 (Unrequested ) in lo pad-18 offset:0x120 mux:2 gpio-2 (Unrequested ) in lo pad-17 offset:0x110 mux:2 gpio-3 (Unrequested ) lo pad-20 offset:0x140 mux:2 gpio-4 (Unrequested ) lo pad-21 offset:0x150 mux:2 gpio-5 (Unrequested ) lo pad-22 offset:0x160 mux:2 gpio-6 (Unrequested ) in lo pad-24 offset:0x180 mux:2 up 20k gpio-7 (Unrequested ) in lo pad-25 offset:0x190 mux:2 gpio-8 (Unrequested ) lo pad-23 offset:0x170 mux:0 gpio-9 (Unrequested ) in lo pad-16 offset:0x100 mux:2 down 20k gpio-10 (Unrequested ) in lo pad-14 offset:0x0e0 mux:2 down 20k gpio-11 (Unrequested ) in lo pad-15 offset:0x0f0 mux:2 down 20k gpio-12 (Unrequested ) lo pad-12 offset:0x0c0 mux:0 gpio-13 (Unrequested ) lo pad-26 offset:0x1a0 mux:1 gpio-14 (Unrequested ) lo pad-27 offset:0x1b0 mux:1 gpio-15 (Unrequested ) lo pad-1 offset:0x010 mux:0 gpio-16 (Unrequested ) in out lo pad-4 offset:0x040 mux:0 gpio-17 (Unrequested ) lo pad-8 offset:0x080 mux:0 gpio-18 (Unrequested ) lo pad-11 offset:0x0b0 mux:0 gpio-19 (Unrequested ) in out lo pad-0 offset:0x000 mux:0 gpio-20 (Unrequested ) in out lo pad-3 offset:0x030 mux:0 gpio-21 (Unrequested ) lo pad-6 offset:0x060 mux:0 gpio-22 (Unrequested ) in out lo pad-10 offset:0x0a0 mux:0 gpio-23 (Unrequested ) lo pad-13 offset:0x0d0 mux:0 gpio-24 (Unrequested ) in out lo pad-2 offset:0x020 mux:0 gpio-25 (Unrequested ) in out lo pad-5 offset:0x050 mux:0 gpio-26 (Unrequested ) lo pad-9 offset:0x090 mux:0 gpio-27 (Unrequested ) lo pad-7 offset:0x070 mux:0 down 20k GPIOs 410-511, platform/INT33FC:00, INT33FC:00: gpio-0 (Unrequested ) lo pad-85 offset:0x550 mux:0 gpio-1 (reset ) in out hi pad-89 offset:0x590 mux:0 gpio-2 (Unrequested ) in hi pad-93 offset:0x5d0 mux:0 fall rise up 20k gpio-3 (Unrequested ) out lo pad-96 offset:0x600 mux:0 gpio-4 (Unrequested ) in hi pad-99 offset:0x630 mux:0 fall rise up 20k gpio-5 (Unrequested ) in hi pad-102 offset:0x660 mux:0 fall rise up 20k gpio-6 (Unrequested ) in hi pad-98 offset:0x620 mux:0 fall rise up 20k gpio-7 (Unrequested ) in hi pad-101 offset:0x650 mux:2 up 20k gpio-8 (Unrequested ) in hi pad-34 offset:0x220 mux:1 down 20k gpio-9 (Unrequested ) in lo pad-37 offset:0x250 mux:1 down 20k gpio-10 (Unrequested ) in out lo pad-36 offset:0x240 mux:0 gpio-11 (Unrequested ) in lo pad-38 offset:0x260 mux:1 down 20k gpio-12 (Unrequested ) in lo pad-39 offset:0x270 mux:1 down 20k gpio-13 (Unrequested ) in lo pad-35 offset:0x230 mux:1 down 20k gpio-14 (Unrequested ) in hi pad-40 offset:0x280 mux:1 down 20k gpio-15 (Unrequested ) in hi pad-84 offset:0x540 mux:1 down 20k gpio-16 (Unrequested ) in lo pad-62 offset:0x3e0 mux:3 down 20k gpio-17 (Unrequested ) in lo pad-61 offset:0x3d0 mux:3 up 20k gpio-18 (Unrequested ) in lo pad-64 offset:0x400 mux:3 up 20k gpio-19 (Unrequested ) in lo pad-59 offset:0x3b0 mux:3 up 20k gpio-20 (Unrequested ) in hi pad-54 offset:0x360 mux:3 up 20k gpio-21 (Unrequested ) in lo pad-56 offset:0x380 mux:3 up 20k gpio-22 (Unrequested ) in lo pad-60 offset:0x3c0 mux:3 up 20k gpio-23 (Unrequested ) in lo pad-55 offset:0x370 mux:3 up 20k gpio-24 (Unrequested ) in lo pad-63 offset:0x3f0 mux:3 up 20k gpio-25 (Unrequested ) in lo pad-57 offset:0x390 mux:3 up 20k gpio-26 (Unrequested ) in hi pad-51 offset:0x330 mux:3 down 20k gpio-27 (Unrequested ) in lo pad-50 offset:0x320 mux:1 down 20k gpio-28 (Unrequested ) in lo pad-53 offset:0x350 mux:1 up 20k gpio-29 (Unrequested ) in lo pad-47 offset:0x2f0 mux:1 up 20k gpio-30 (Unrequested ) in lo pad-52 offset:0x340 mux:1 up 20k gpio-31 (Unrequested ) in hi pad-49 offset:0x310 mux:1 up 20k gpio-32 (Unrequested ) in lo pad-48 offset:0x300 mux:1 up 20k gpio-33 (Unrequested ) in lo pad-43 offset:0x2b0 mux:1 down 20k gpio-34 (Unrequested ) in lo pad-46 offset:0x2e0 mux:1 up 20k gpio-35 (Unrequested ) in lo pad-41 offset:0x290 mux:1 up 20k gpio-36 (Unrequested ) in lo pad-45 offset:0x2d0 mux:1 up 20k gpio-37 (Unrequested ) in lo pad-42 offset:0x2a0 mux:1 up 20k gpio-38 (80860F14:01 cd ) in hi pad-58 offset:0x3a0 mux:0 fall rise gpio-39 (Unrequested ) in lo pad-44 offset:0x2c0 mux:1 up 20k gpio-40 (Unrequested ) in lo pad-95 offset:0x5f0 mux:1 down 20k gpio-41 (Unrequested ) in hi pad-105 offset:0x690 mux:1 up 20k gpio-42 (Unrequested ) in hi pad-70 offset:0x460 mux:0 up 20k gpio-43 (Unrequested ) in hi pad-68 offset:0x440 mux:0 up 20k gpio-44 (Unrequested ) in hi pad-67 offset:0x430 mux:0 up 20k gpio-45 (Unrequested ) in hi pad-66 offset:0x420 mux:0 up 20k gpio-46 (Unrequested ) in hi pad-69 offset:0x450 mux:0 up 20k gpio-47 (Unrequested ) in hi pad-71 offset:0x470 mux:0 up 20k gpio-48 (Unrequested ) in hi pad-65 offset:0x410 mux:0 up 20k gpio-49 (Unrequested ) in hi pad-72 offset:0x480 mux:0 up 20k gpio-50 (Unrequested ) in hi pad-86 offset:0x560 mux:0 up 20k gpio-51 (Unrequested ) in out hi pad-90 offset:0x5a0 mux:0 gpio-52 (Unrequested ) in out lo pad-88 offset:0x580 mux:0 gpio-53 (Unrequested ) out lo pad-92 offset:0x5c0 mux:0 gpio-54 (Unrequested ) in out hi pad-103 offset:0x670 mux:0 gpio-55 (Unrequested ) out lo pad-77 offset:0x4d0 mux:0 gpio-56 (? ) in lo pad-79 offset:0x4f0 mux:0 up 20k gpio-57 (Unrequested ) in lo pad-83 offset:0x530 mux:1 up 20k gpio-58 (Unrequested ) in out lo pad-78 offset:0x4e0 mux:0 gpio-59 (ACPI:OpRegion ) in out lo pad-81 offset:0x510 mux:0 gpio-60 (ACPI:OpRegion ) in out hi pad-80 offset:0x500 mux:0 gpio-61 (Unrequested ) in lo pad-82 offset:0x520 mux:1 down 20k gpio-62 (Unrequested ) in lo pad-13 offset:0x0d0 mux:1 down 20k gpio-63 (Unrequested ) in lo pad-12 offset:0x0c0 mux:1 down 20k gpio-64 (Unrequested ) in lo pad-15 offset:0x0f0 mux:1 down 20k gpio-65 (Unrequested ) in lo pad-14 offset:0x0e0 mux:1 down 20k gpio-66 (Unrequested ) in hi pad-17 offset:0x110 mux:1 up 20k gpio-67 (Unrequested ) in lo pad-18 offset:0x120 mux:1 up 20k gpio-68 (Unrequested ) in lo pad-19 offset:0x130 mux:1 up 20k gpio-69 (Unrequested ) in lo pad-16 offset:0x100 mux:1 down 20k gpio-70 (Unrequested ) in lo pad-2 offset:0x020 mux:1 up 20k gpio-71 (Unrequested ) in lo pad-1 offset:0x010 mux:1 up 20k gpio-72 (Unrequested ) in hi pad-0 offset:0x000 mux:1 up 20k gpio-73 (Unrequested ) in hi pad-4 offset:0x040 mux:1 gpio-74 (Unrequested ) in lo pad-6 offset:0x060 mux:1 up 20k gpio-75 (Unrequested ) in lo pad-7 offset:0x070 mux:1 up 20k gpio-76 (Unrequested ) in hi pad-9 offset:0x090 mux:1 up 20k gpio-77 (Unrequested ) in hi pad-8 offset:0x080 mux:1 gpio-78 (Unrequested ) in lo pad-33 offset:0x210 mux:1 up 2k gpio-79 (Unrequested ) in lo pad-32 offset:0x200 mux:1 up 2k gpio-80 (Unrequested ) in lo pad-31 offset:0x1f0 mux:1 up 2k gpio-81 (Unrequested ) in lo pad-30 offset:0x1e0 mux:1 up 2k gpio-82 (Unrequested ) in lo pad-29 offset:0x1d0 mux:1 up 2k gpio-83 (Unrequested ) in lo pad-27 offset:0x1b0 mux:1 up 2k gpio-84 (Unrequested ) in lo pad-25 offset:0x190 mux:1 up 2k gpio-85 (Unrequested ) in lo pad-28 offset:0x1c0 mux:1 up 2k gpio-86 (Unrequested ) in lo pad-26 offset:0x1a0 mux:1 up 2k gpio-87 (Unrequested ) in lo pad-23 offset:0x170 mux:1 up 2k gpio-88 (Unrequested ) in lo pad-21 offset:0x150 mux:1 up 2k gpio-89 (Unrequested ) in lo pad-20 offset:0x140 mux:1 up 2k gpio-90 (Unrequested ) in lo pad-24 offset:0x180 mux:1 up 2k gpio-91 (Unrequested ) in lo pad-22 offset:0x160 mux:1 up 2k gpio-92 (Unrequested ) in lo pad-5 offset:0x050 mux:0 up 2k gpio-93 (Unrequested ) in lo pad-3 offset:0x030 mux:0 up 2k gpio-94 (ACPI:Event ) in hi pad-10 offset:0x0a0 mux:0 fall rise down 20k gpio-95 (Unrequested ) in out hi pad-11 offset:0x0b0 mux:0 gpio-96 (Unrequested ) in lo pad-106 offset:0x6a0 mux:1 down 20k gpio-97 (Unrequested ) in lo pad-87 offset:0x570 mux:1 down 20k gpio-98 (Unrequested ) lo pad-91 offset:0x5b0 mux:0 gpio-99 (Unrequested ) in lo pad-104 offset:0x680 mux:1 down 20k gpio-100 (Unrequested ) lo pad-97 offset:0x610 mux:0 gpio-101 (Unrequested ) lo pad-100 offset:0x640 mux:0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 13:19 ` Sebastien Bourdeauducq @ 2015-02-02 13:48 ` Mika Westerberg 2015-02-02 15:32 ` Sébastien Bourdeauducq 0 siblings, 1 reply; 12+ messages in thread From: Mika Westerberg @ 2015-02-02 13:48 UTC (permalink / raw) To: Sebastien Bourdeauducq; +Cc: Benjamin Tissoires, linux-input On Mon, Feb 02, 2015 at 09:19:51PM +0800, Sebastien Bourdeauducq wrote: > On Monday, February 02, 2015 06:00 PM, Mika Westerberg wrote: > >>With this patch and IRQF_TRIGGER_LOW | IRQF_ONESHOT, I get an interrupt > >>flood and the kernel disables the interrupt line. I have reverted it to > >>IRQF_TRIGGER_FALLING | IRQF_ONESHOT, and the i2c_hid initialization > >>completes successfully. > > > >That shouldn't happen :-( > > With this computer nothing is normal. Every single component except the CPU, > display and USB has major issues under Linux. We need to get one here then. Can you point me to the exact model? > >On all the panels I've tried, with or without GPIO, turning the > >interrupt to active low works. How about Windows, have you tried if it > >works there? > > Yes, the Wacom digitizer works fine under Windows. > > >Can you send output of /sys/kernel/debug/gpio when after the kernel has > >disabled the interrupt? > > Attached. The kernel message I get is "byt_gpio INT33FC:00: Gpio 56 > interrupt flood, disabling". > > I also get a "byt_gpio INT33FC:02: Gpio 18 interrupt flood, disabling" > before which seems unrelated. > gpio-56 (? ) in lo pad-79 offset:0x4f0 mux:0 up 20k This explains, it is low all the time. Since it has 20k internal pull-up configured, I'm guessing something (the digitizer) drives it low like it still has something to report. Do you see in the dmesg if the i2c-hid.c is able to read reports from the device? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 13:48 ` Mika Westerberg @ 2015-02-02 15:32 ` Sébastien Bourdeauducq 2015-02-02 15:42 ` Benjamin Tissoires 2015-02-02 15:57 ` Mika Westerberg 0 siblings, 2 replies; 12+ messages in thread From: Sébastien Bourdeauducq @ 2015-02-02 15:32 UTC (permalink / raw) To: Mika Westerberg; +Cc: Benjamin Tissoires, linux-input On 02/02/2015 09:48 PM, Mika Westerberg wrote: > On Mon, Feb 02, 2015 at 09:19:51PM +0800, Sebastien Bourdeauducq wrote: >> With this computer nothing is normal. Every single component except the CPU, >> display and USB has major issues under Linux. > > We need to get one here then. Can you point me to the exact model? That's a Lenovo Thinkpad Tablet 10, P/N 20C3001VHH. What would be the plan for you to get one? > Since it has 20k internal pull-up configured, I'm guessing something > (the digitizer) drives it low like it still has something to report. Do > you see in the dmesg if the i2c-hid.c is able to read reports from the > device? When I made the interrupt falling edge sensitive, i2c-hid was able to read the first report as I could move the mouse cursor once using the stylus. A possible scenario is: 1) the digitizer is holding the interrupt line low after booting 2) enumerating or otherwise initializing the digitizer causes it to release the interrupt line 3) using the stylus queues several reports in the device and it asserts the interrupt line again. However, with the interrupt configured as edge sensitive, only the first of those reports are retrieved and subsequent ones are lost, with the interrupt line stuck. Maybe the interrupt should be level sensitive and enabled only after certain parts of the device initialization have taken place. Sébastien -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 15:32 ` Sébastien Bourdeauducq @ 2015-02-02 15:42 ` Benjamin Tissoires 2015-02-02 15:55 ` Sébastien Bourdeauducq 2015-02-02 15:57 ` Mika Westerberg 1 sibling, 1 reply; 12+ messages in thread From: Benjamin Tissoires @ 2015-02-02 15:42 UTC (permalink / raw) To: Sébastien Bourdeauducq; +Cc: Mika Westerberg, linux-input On Mon, Feb 2, 2015 at 10:32 AM, Sébastien Bourdeauducq <sb@m-labs.hk> wrote: > On 02/02/2015 09:48 PM, Mika Westerberg wrote: >> On Mon, Feb 02, 2015 at 09:19:51PM +0800, Sebastien Bourdeauducq wrote: >>> With this computer nothing is normal. Every single component except the CPU, >>> display and USB has major issues under Linux. >> >> We need to get one here then. Can you point me to the exact model? > > That's a Lenovo Thinkpad Tablet 10, P/N 20C3001VHH. What would be the > plan for you to get one? > >> Since it has 20k internal pull-up configured, I'm guessing something >> (the digitizer) drives it low like it still has something to report. Do >> you see in the dmesg if the i2c-hid.c is able to read reports from the >> device? > > When I made the interrupt falling edge sensitive, i2c-hid was able to > read the first report as I could move the mouse cursor once using the > stylus. > > A possible scenario is: > 1) the digitizer is holding the interrupt line low after booting > 2) enumerating or otherwise initializing the digitizer causes it to > release the interrupt line > 3) using the stylus queues several reports in the device and it asserts > the interrupt line again. However, with the interrupt configured as edge > sensitive, only the first of those reports are retrieved and subsequent > ones are lost, with the interrupt line stuck. There has been a patch floating around last year which tried to pull all the available reports after the IRQ was triggered. I rejected it for the sake of not breaking existing devices, but maybe your device needs it. http://www.spinics.net/lists/linux-input/msg31342.html Cheers, Benjamin > > Maybe the interrupt should be level sensitive and enabled only after > certain parts of the device initialization have taken place. > > Sébastien > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 15:42 ` Benjamin Tissoires @ 2015-02-02 15:55 ` Sébastien Bourdeauducq 0 siblings, 0 replies; 12+ messages in thread From: Sébastien Bourdeauducq @ 2015-02-02 15:55 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: Mika Westerberg, linux-input On 02/02/2015 11:42 PM, Benjamin Tissoires wrote: > There has been a patch floating around last year which tried to pull > all the available reports after the IRQ was triggered. I rejected it > for the sake of not breaking existing devices, but maybe your device > needs it. > http://www.spinics.net/lists/linux-input/msg31342.html Thanks, but no, it still doesn't work. I just noticed another thing: when I use the stylus the first time (and it successfully moves the cursor), it prints: i2c_hid_get_input: incomplete report (76/8194) Sébastien -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 15:32 ` Sébastien Bourdeauducq 2015-02-02 15:42 ` Benjamin Tissoires @ 2015-02-02 15:57 ` Mika Westerberg 2015-02-03 8:53 ` Sébastien Bourdeauducq 1 sibling, 1 reply; 12+ messages in thread From: Mika Westerberg @ 2015-02-02 15:57 UTC (permalink / raw) To: Sébastien Bourdeauducq; +Cc: Benjamin Tissoires, linux-input On Mon, Feb 02, 2015 at 11:32:19PM +0800, Sébastien Bourdeauducq wrote: > On 02/02/2015 09:48 PM, Mika Westerberg wrote: > > On Mon, Feb 02, 2015 at 09:19:51PM +0800, Sebastien Bourdeauducq wrote: > >> With this computer nothing is normal. Every single component except the CPU, > >> display and USB has major issues under Linux. > > > > We need to get one here then. Can you point me to the exact model? > > That's a Lenovo Thinkpad Tablet 10, P/N 20C3001VHH. What would be the > plan for you to get one? Thanks. We've been purchasing these problematic devices from time to time and then trying to enable what we can in the mainline kernel. I'll ask my boss if I can order one of these as well. > > Since it has 20k internal pull-up configured, I'm guessing something > > (the digitizer) drives it low like it still has something to report. Do > > you see in the dmesg if the i2c-hid.c is able to read reports from the > > device? > > When I made the interrupt falling edge sensitive, i2c-hid was able to > read the first report as I could move the mouse cursor once using the > stylus. > > A possible scenario is: > 1) the digitizer is holding the interrupt line low after booting > 2) enumerating or otherwise initializing the digitizer causes it to > release the interrupt line > 3) using the stylus queues several reports in the device and it asserts > the interrupt line again. However, with the interrupt configured as edge > sensitive, only the first of those reports are retrieved and subsequent > ones are lost, with the interrupt line stuck. That seems plausible explanation. > Maybe the interrupt should be level sensitive and enabled only after > certain parts of the device initialization have taken place. The device should respond to reset by asserting an interrupt. You could try so that you only enable the interrupt in i2c_hid_parse() right before i2c_hid_hwreset() is called. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-02 15:57 ` Mika Westerberg @ 2015-02-03 8:53 ` Sébastien Bourdeauducq 2015-02-03 11:25 ` Mika Westerberg 0 siblings, 1 reply; 12+ messages in thread From: Sébastien Bourdeauducq @ 2015-02-03 8:53 UTC (permalink / raw) To: Mika Westerberg; +Cc: Benjamin Tissoires, linux-input On 02/02/2015 11:57 PM, Mika Westerberg wrote: >> > Maybe the interrupt should be level sensitive and enabled only after >> > certain parts of the device initialization have taken place. > The device should respond to reset by asserting an interrupt. You could > try so that you only enable the interrupt in i2c_hid_parse() right > before i2c_hid_hwreset() is called. No luck. There is no more interrupt flood and the device is detected and its report descriptor retrieved, but then no events at all are received when using the stylus. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 2015-02-03 8:53 ` Sébastien Bourdeauducq @ 2015-02-03 11:25 ` Mika Westerberg 0 siblings, 0 replies; 12+ messages in thread From: Mika Westerberg @ 2015-02-03 11:25 UTC (permalink / raw) To: Sébastien Bourdeauducq; +Cc: Benjamin Tissoires, linux-input On Tue, Feb 03, 2015 at 04:53:14PM +0800, Sébastien Bourdeauducq wrote: > On 02/02/2015 11:57 PM, Mika Westerberg wrote: > >> > Maybe the interrupt should be level sensitive and enabled only after > >> > certain parts of the device initialization have taken place. > > The device should respond to reset by asserting an interrupt. You could > > try so that you only enable the interrupt in i2c_hid_parse() right > > before i2c_hid_hwreset() is called. > > No luck. There is no more interrupt flood and the device is detected and > its report descriptor retrieved, but then no events at all are received > when using the stylus. If you now check the GPIO status in /sys/kernel/debug/gpio, does it show 'high'? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-02-03 11:25 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-31 15:01 "i2c_hid: Could not register for interrupt, irq = -1" on Thinkpad Tablet 10 Sebastien Bourdeauducq 2015-01-31 20:39 ` Benjamin Tissoires 2015-02-01 3:27 ` Sebastien Bourdeauducq 2015-02-02 10:00 ` Mika Westerberg 2015-02-02 13:19 ` Sebastien Bourdeauducq 2015-02-02 13:48 ` Mika Westerberg 2015-02-02 15:32 ` Sébastien Bourdeauducq 2015-02-02 15:42 ` Benjamin Tissoires 2015-02-02 15:55 ` Sébastien Bourdeauducq 2015-02-02 15:57 ` Mika Westerberg 2015-02-03 8:53 ` Sébastien Bourdeauducq 2015-02-03 11:25 ` Mika Westerberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.