From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-input@vger.kernel.org
Subject: Re: [PATCH] HID: i2c-hid: Send power-on command after reset
Date: Thu, 31 Oct 2019 14:23:14 +0800 [thread overview]
Message-ID: <FE23608B-596F-4494-B62D-2516B150DEF9@canonical.com> (raw)
In-Reply-To: <67ABE7E6-C9CF-4A37-96E9-C9D76ECC9DE1@canonical.com>
Hi Hans,
> On Oct 31, 2019, at 01:39, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
>
> Hi Hans,
>
>> On Oct 30, 2019, at 23:11, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 21-10-2019 09:17, Kai Heng Feng wrote:
>>> Hi Hans,
>>>> On Oct 21, 2019, at 5:47 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Before commit 67b18dfb8cfc ("HID: i2c-hid: Remove runtime power
>>>> management"), any i2c-hid touchscreens would typically be runtime-suspended
>>>> between the driver loading and Xorg or a Wayland compositor opening it,
>>>> causing it to be resumed again. This means that before this change,
>>>> we would call i2c_hid_set_power(OFF), i2c_hid_set_power(ON) before the
>>>> graphical session would start listening to the touchscreen.
>>>>
>>>> It turns out that at least some SIS touchscreens, such as the one found
>>>> on the Asus T100HA, need a power-on command after reset, otherwise they
>>>> will not send any events.
>>> As You-Sheng pointed out before, device may need a 60ms delay between ON and RESET command.
>>> Does adding the delay help?
>>
>> I just tried increasing the existing usleep between ON and RESET to:
>>
>> usleep_range(60000, 70000);
>>
>> And this does not help. Note that before we had quirks for devices with a SIS
>> screen needed, where we avoided the reset on resume and instead did just an
>> i2c_hid_set_power(client, I2C_HID_PWR_ON) for these.
>>
>> Which likely was to work around the same problem, these devices simply need a
>> i2c_hid_set_power(client, I2C_HID_PWR_ON) after rest to function.
>>
>> Assuming other devices do come up in the "ON" state after reset then this
>> will be a no-op for them and this should thus not impact their operation.
>>
>> Also I just noticed that 67b18dfb8cfc ("HID: i2c-hid: Remove runtime power management")
>> has been added to 5.4-rc# as a fix, so we really need to get this in place
>> to to not avoid regressing devices with a SIS touchscreen actually quite a
>> few devices including some quite popular ones uses a SIS touchscreen, here
>> is the list of devices I know about:
>
> I agree we should use this workaround since increasing delay doesn't work.
I just checked the spec again, seems like ON before RESET in probe is unnecessary.
Does removing the ON command in probe help?
>
> Kai-Heng
>
>>
>> Asus T100HA
>> Asus T200TA
>> Peaq 10.1" C1010 2-in-1
>> Toshiba Click Mini L9W-B
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>>> Fixes: 67b18dfb8cfc ("HID: i2c-hid: Remove runtime power management")
>>>> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> drivers/hid/i2c-hid/i2c-hid-core.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> index d9c55e30f986..04c088131e04 100644
>>>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>>>> @@ -447,8 +447,12 @@ static int i2c_hid_hwreset(struct i2c_client *client)
>>>> if (ret) {
>>>> dev_err(&client->dev, "failed to reset device.\n");
>>>> i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
>>>> + goto out_unlock;
>>>> }
>>>>
>>>> + /* At least some SIS devices need this after reset */
>>>> + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
>>>> +
>>>> out_unlock:
>>>> mutex_unlock(&ihid->reset_lock);
>>>> return ret;
>>>> --
>>>> 2.23.0
next prev parent reply other threads:[~2019-10-31 6:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-20 21:47 [PATCH] HID: i2c-hid: Send power-on command after reset Hans de Goede
2019-10-21 7:17 ` Kai Heng Feng
2019-10-30 15:11 ` Hans de Goede
2019-10-30 17:39 ` Kai-Heng Feng
2019-10-31 6:23 ` Kai-Heng Feng [this message]
2019-10-31 22:05 ` Hans de Goede
2019-11-02 19:35 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FE23608B-596F-4494-B62D-2516B150DEF9@canonical.com \
--to=kai.heng.feng@canonical.com \
--cc=benjamin.tissoires@redhat.com \
--cc=hdegoede@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).