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