On Thu, Dec 17, 2015 at 9:28 AM, Benjamin Tissoires <benjamin.tissoi...@redhat.com> wrote: > On Dec 17 2015 or thereabouts, Nish Aravamudan wrote: >> Hi Benjamin, >> >> On Thu, Dec 17, 2015 at 1:53 AM, Benjamin Tissoires >> <benjamin.tissoi...@redhat.com> wrote: >> > On Dec 16 2015 or thereabouts, Nish Aravamudan wrote: >> >> Hi Jiri, >> >> >> >> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina <ji...@kernel.org> wrote: >> >> > On Wed, 16 Dec 2015, Mika Westerberg wrote: >> >> > >> >> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail >> >> >> > settings >> >> >> > to not use HTML.] >> >> >> > >> >> >> > I have recently purchased a Lenovo Yoga 900 and most everything is >> >> >> > working >> >> >> > with a slightly modified 4.4-rc5 >> >> >> > (https://lkml.org/lkml/2015/11/30/441 applied >> >> >> > to enable the touchpad itself), I am seeing two issues: >> >> >> > >> >> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r >> >> >> > i2c-hid; >> >> >> > modprobe i2c-hid` "fixes" it. >> >> >> > >> >> >> > The kernel emits: >> >> >> > >> >> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device. >> >> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61 >> >> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61 >> >> >> > >> >> >> > During the resume. So perhaps this is a timing issue (given that once >> >> >> > resumed, the >> >> >> > module reload does work?). >> >> >> >> >> >> Linus noticed this as well and Jiri suggested the below patch which >> >> >> seemed to fix the issue (although it increased resume time a bit). >> >> >> >> >> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but >> >> >> I'm still waiting for it (sloow big corporation bureaucracy takes some >> >> >> time to get things purchased outside). >> >> >> >> >> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c >> >> >> b/drivers/hid/i2c-hid/i2c-hid.c >> >> >> index 55d8f9d..52dd03a0 100644 >> >> >> --- a/drivers/hid/i2c-hid/i2c-hid.c >> >> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c >> >> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev) >> >> >> struct i2c_client *client = to_i2c_client(dev); >> >> >> struct i2c_hid *ihid = i2c_get_clientdata(client); >> >> >> struct hid_device *hid = ihid->hid; >> >> >> - int wake_status; >> >> >> + int wake_status, tries = 3; >> >> >> >> >> >> enable_irq(ihid->irq); >> >> >> - ret = i2c_hid_hwreset(client); >> >> >> + >> >> >> + do { >> >> >> + ret = i2c_hid_hwreset(client); >> >> >> + if (ret) >> >> >> + msleep(1000); >> >> >> + } while (tries-- > 0 && ret); >> >> >> + >> >> >> if (ret) >> >> >> return ret; >> >> > >> >> > As a possible alternative, please test the patch above on top of >> >> > for-next >> >> > branch of >> >> > >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git >> >> > >> >> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume >> >> > asynchronously") and knowing whether that changes something might be >> >> > interesting datapoint as well. >> >> >> >> What should I be looking for to be different wrt. that tree? Should I >> >> not see the failure to reset the device? Or would it be (relatively) >> >> speedier than the stock kernel? >> >> >> > >> > Basically, does the resume time gets better? Linus experienced something >> > like 9 secs of resume before this patch, and now I hope it should be >> > saner (the touchpad might still be a little bit long to respond). >> > >> > Also, we have a bug report concerning this laptop and it looks like the >> > i2c controller needs to be updated (see >> > https://bugzilla.redhat.com/show_bug.cgi?id=1275718). >> > >> > I am not entirely sure why those on the rhbz needs to update the i2c >> > controller while you don't have to, but it may also be worth checking if >> > the i2c patch series mentioned in this rhbz (comment #20) fixes by itself >> > the resume issue (without Jiri's patch). >> >> Yep, I applied the series from https://lkml.org/lkml/2015/11/30/441 >> already. Without that series, I don't have a working touchscreen and >> touchpad. Touchpad resume doesn't work with just that series. > > Oh, OK then. Now I start understanding the whole thing. > >> >> With that series + Jiri's patch it seems to resume pretty quickly. But >> I guess I don't see exactly what would change with the resume if the >> same loop is present on top of hid:for-next? Still on my list to test, >> though. > > The difference is that now, if the touchpad takes 5 seconds to resume, > it should not block the whole resume time given that it is run in its > own thread.
Ah, I see! Ok, will test and time with and without hid:for-next. >> Also, even with that series, there does appear maybe there is an I2C >> issue, though: >> >> i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18 > > I wouldn't worry too much about that. The device does not correctly answer, > but most of the time, this is harmless. > >> >> as I mentioned in my first e-mail; which might be affecting the IIO sensors? > > If iio-sensor-proxy works under gnome, there is no need to panic :) Heh, that's why I actually started digging into a separate thread, iio-sensor-proxy not working on this device :) -Nish -- 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
