On Fri, Nov 17, 2017 at 04:27:39PM +0800, Chris Chiu wrote: > On Thu, Nov 16, 2017 at 9:07 PM, Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Thu, Nov 16, 2017 at 12:01:24PM +0000, Daniel Drake wrote: > >> On Thu, Nov 16, 2017 at 11:52 AM, Mika Westerberg > >> <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > >> > Please first check the signal with some analyzator if it works as > >> > expected and let's then figure out what needs to be fixed and where ;-) > >> > >> It works fine under Windows, so I think it's already clear that there > >> is a Linux bug to be solved here. > > > > Can you remove all the "debugging" patches and hacks and then add > > "i2c_hid.debug=1" to the kernel command line. > > > > Then reproduce the issue and send me full dmesg and acpidump of the > > system. Thanks. > > Hi Mika, > Here's the dmesg log which stops at 214th seconds and no more > further output and archive of "acpidump -b" output files FYI. Thanks! The dmesg is not complete, I wonder if you can make the buffer a bit bigger by increasing CONFIG_LOG_BUF_SHIFT (or get it from /var/log/messages or so). I would like to see i2c-hid init and related messages. >From the acpidump related to the i2c-hid device, the system provides custom I2C timings via FMCN ACPI method but it misses one value (sda_hold). Not sure if if has anything to do with the problem, though. Adding Jarkko in case he has any ideas. BTW, is this the same machine which has problems in S3 suspend/resume? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html