Message-ID: <CAOhV88OFm2QzQ8Pm_Wo5D8fuUjns_Y58s4HXuC+dBN5wHOyqQA@mail.gmail.com>
Date:	Thu, 17 Dec 2015 09:34:38 -0800
From:	Nish Aravamudan <nish.aravamudan@...il.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:	Jiri Kosina <jikos@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andrew Duggan <aduggan@...aptics.com>,
	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	linux-input@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND] Lenovo Yoga 900 touchpad issues

On Thu, Dec 17, 2015 at 9:28 AM, Benjamin Tissoires
<benjamin.tissoires@...hat.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.tissoires@...hat.com> wrote:
>> > On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
>> >> Hi Jiri,
>> >>
>> >> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina <jikos@...nel.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists