Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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? -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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 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
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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, 0x,
\\_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)
}
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
On Mon, Feb 2, 2015 at 10:32 AM, Sébastien Bourdeauducq s...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
Hi, On Sat, Jan 31, 2015 at 10:01 AM, Sebastien Bourdeauducq s...@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 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c_hid: Could not register for interrupt, irq = -1 on Thinkpad Tablet 10
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, 0x,
\\_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)
{
/* */ 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
}
}
}
--
To unsubscribe from this list: send
