@@ -55,6 +55,9 @@#define ETP_MK_DATA_OFFSET 33 /* For high precision reports */#define ETP_MAX_REPORT_LEN 39+/* quirks to control the device */+#define ETP_QUIRK_SET_QUICK_WAKEUP_DEV BIT(0)+/* The main device structure */structelan_tp_data{structi2c_client*client;
@@ -99,8 +102,50 @@ struct elan_tp_data {boolbaseline_ready;u8clickpad;boolmiddle_button;++unsignedlongquirks;/* Various quirks */+};+++staticconststructelan_i2c_quirks{+__u16ic_type;+__u16product_id;+__u32quirks;+}elan_i2c_quirks[]={+{0x0D,ETP_PRODUCT_ID_DELBIN,+ETP_QUIRK_SET_QUICK_WAKEUP_DEV},+{0x10,ETP_PRODUCT_ID_VOXEL,+ETP_QUIRK_SET_QUICK_WAKEUP_DEV},+{0x14,ETP_PRODUCT_ID_MAGPIE,+ETP_QUIRK_SET_QUICK_WAKEUP_DEV},+{0x14,ETP_PRODUCT_ID_BOBBA,+ETP_QUIRK_SET_QUICK_WAKEUP_DEV},+{0,0}};+/*+*elan_i2c_lookup_quirk:returnanyquirksassociatedwithaelani2cdevice+*@ic_type:the16-bitictype+*@product_id:the16-bitproductID+*+*Returns:au32quirksvalue.+*/+staticu32elan_i2c_lookup_quirk(constu16ic_type,constu16product_id)+{+u32quirks=0;+intn;++for(n=0;elan_i2c_quirks[n].ic_type;n++)+if(elan_i2c_quirks[n].ic_type==ic_type&&+(elan_i2c_quirks[n].product_id==product_id))+quirks=elan_i2c_quirks[n].quirks;++if((ic_type>=0x0D)&&(product_id>=0x123))+quirks|=ETP_QUIRK_SET_QUICK_WAKEUP_DEV;++returnquirks;+}+staticintelan_get_fwinfo(u16ic_type,u8iap_version,u16*validpage_count,u32*signature_address,u16*page_size){
Hi Jingle,
On Fri, Feb 26, 2021 at 03:35:37PM +0800, jingle.wu wrote:
quoted hunk
@@ -273,10 +318,12 @@ static int __elan_initialize(struct elan_tp_data *data) bool woken_up = false; int error;- error = data->ops->initialize(client);- if (error) {- dev_err(&client->dev, "device initialize failed: %d\n", error);- return error;+ if (!(data->quirks & ETP_QUIRK_SET_QUICK_WAKEUP_DEV)) {+ error = data->ops->initialize(client);+ if (error) {+ dev_err(&client->dev, "device initialize failed: %d\n", error);+ return error;+ }
So data->ops->initialize(client) essentially performs reset of the
controller (we may want to rename it even) and as far as I understand
you would want to avoid resetting the controller on newer devices,
right?
My question is how behavior of older devices differ from the new ones
(are they stay in "undefined" state at power up) and whether it is
possible to determine if controller is in operating mode. For example,
what would happen on older devices if we call elan_query_product() below
without resetting the controller?
I also think that while I can see us skipping reset in resume paths we
probably want to keep it in probe as we really do not know the state of
the device (was it powered up properly earlier, etc).
HI Dmitry:
So data->ops->initialize(client) essentially performs reset of the
controller (we may want to rename it even) and as far as I understand
you would want to avoid resetting the controller on newer devices,
right?
-> YES
My question is how behavior of older devices differ from the new ones
(are they stay in "undefined" state at power up) and whether it is
possible to determine if controller is in operating mode. For example,
what would happen on older devices if we call elan_query_product() below
without resetting the controller?
-> But there may be other problems, because ELAN can't test all the older devices ,
-> so use quirk to divide this part.
I also think that while I can see us skipping reset in resume paths we
probably want to keep it in probe as we really do not know the state of
the device (was it powered up properly earlier, etc).
-> In this part, at PROBE state will be called data->ops->initialize(client) function.
-> Because quirk's setting (data->quirks = elan_i2c_lookup_quirk(data->ic_type, data->product_id);)
-> is after data->ops->initialize(client) and elan_query_product() function.
THANKS
JINGLE
-----Original message-----
From:Dmitry Torokhov [off-list ref]
To:jingle.wu [off-list ref]
Cc:linux-kernel@vger.kernel.org,linux-input@vger.kernel.org,phoenix@emc.com.tw,dave.wang@emc.com.tw,josh.chen@emc.com.tw
Date:Mon, 01 Mar 2021 13:31:31
Subject:Re: [PATCH] Input: elan_i2c - Reduce the resume time for new devices
Hi Jingle,
On Fri, Feb 26, 2021 at 03:35:37PM +0800, jingle.wu wrote:
quoted hunk
@@ -273,10 +318,12 @@ static int __elan_initialize(struct elan_tp_data *data) bool woken_up = false; int error;- error = data->ops->initialize(client);- if (error) {- dev_err(&client->dev, "device initialize failed: %d\n", error);- return error;+ if (!(data->quirks & ETP_QUIRK_SET_QUICK_WAKEUP_DEV)) {+ error = data->ops->initialize(client);+ if (error) {+ dev_err(&client->dev, "device initialize failed: %d\n", error);+ return error;+ }
So data->ops->initialize(client) essentially performs reset of the
controller (we may want to rename it even) and as far as I understand
you would want to avoid resetting the controller on newer devices,
right?
My question is how behavior of older devices differ from the new ones
(are they stay in "undefined" state at power up) and whether it is
possible to determine if controller is in operating mode. For example,
what would happen on older devices if we call elan_query_product() below
without resetting the controller?
I also think that while I can see us skipping reset in resume paths we
probably want to keep it in probe as we really do not know the state of
the device (was it powered up properly earlier, etc).
Hi Jingle,
On Tue, Mar 02, 2021 at 09:04:57AM +0800, jingle.wu wrote:
HI Dmitry:
So data->ops->initialize(client) essentially performs reset of the
controller (we may want to rename it even) and as far as I understand
you would want to avoid resetting the controller on newer devices,
right?
-> YES
My question is how behavior of older devices differ from the new ones
(are they stay in "undefined" state at power up) and whether it is
possible to determine if controller is in operating mode. For example,
what would happen on older devices if we call elan_query_product() below
without resetting the controller?
-> But there may be other problems, because ELAN can't test all the older devices ,
-> so use quirk to divide this part.
OK, but could you please tell me what exactly was changed in the newer
parts behavior regarding need to reset after powering them on?
Thanks.
--
Dmitry
HI Dmitry:
In this case (in the newer parts behavior regarding need to reset after
powering them on), it is consistent with the original driver behavior with
any new or old device
(be called data->ops->initialize(client) : usleep(100) , etc.. , because
this times "data->quirks" is equal 0 at probe state.)
THANKS
JINGLE
-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Friday, March 05, 2021 8:55 AM
To: jingle.wu
Cc: linux-kernel; linux-input; phoenix; dave.wang; josh.chen
Subject: Re: [PATCH] Input: elan_i2c - Reduce the resume time for new dev
ices
Hi Jingle,
On Tue, Mar 02, 2021 at 09:04:57AM +0800, jingle.wu wrote:
HI Dmitry:
So data->ops->initialize(client) essentially performs reset of the
controller (we may want to rename it even) and as far as I understand
you would want to avoid resetting the controller on newer devices,
right?
-> YES
My question is how behavior of older devices differ from the new ones
(are they stay in "undefined" state at power up) and whether it is
possible to determine if controller is in operating mode. For example,
what would happen on older devices if we call elan_query_product()
below without resetting the controller?
-> But there may be other problems, because ELAN can't test all the
-> older devices , so use quirk to divide this part.
OK, but could you please tell me what exactly was changed in the newer parts
behavior regarding need to reset after powering them on?
Thanks.
--
Dmitry
Hi Jingle,
On Fri, Mar 05, 2021 at 09:24:05AM +0800, jingle wrote:
HI Dmitry:
In this case (in the newer parts behavior regarding need to reset after
powering them on), it is consistent with the original driver behavior with
any new or old device
(be called data->ops->initialize(client) : usleep(100) , etc.. , because
this times "data->quirks" is equal 0 at probe state.)
You misunderstood my question. I was asking what specifically, if
anything, was changed in the firmware to allow skipping reset/sleep part
of device initialization on newer parts during resume process. Because
of there were no specific changes I would say let's not do a quirk and
change the driver to skip reset on resume.
Thanks.
--
Dmitry
HI Dmitry:
1. You mean to let all devices ignore skipping reset/sleep part of device
initialization?
2. The test team found that some old firmware will have errors (invalid
report etc...), so ELAN can only ensure that the new device can meet the
newer parts.
Thanks
jingle
-----Original Message-----
From: 'Dmitry Torokhov' [mailto:dmitry.torokhov@gmail.com]
Sent: Friday, March 05, 2021 9:31 AM
To: jingle
Cc: 'linux-kernel'; 'linux-input'; 'phoenix'; 'dave.wang'; 'josh.chen'
Subject: Re: [PATCH] Input: elan_i2c - Reduce the resume time for new dev
ices
Hi Jingle,
On Fri, Mar 05, 2021 at 09:24:05AM +0800, jingle wrote:
HI Dmitry:
In this case (in the newer parts behavior regarding need to reset
after powering them on), it is consistent with the original driver
behavior with any new or old device (be called
data->ops->initialize(client) : usleep(100) , etc.. , because this
times "data->quirks" is equal 0 at probe state.)
You misunderstood my question. I was asking what specifically, if anything,
was changed in the firmware to allow skipping reset/sleep part of device
initialization on newer parts during resume process. Because of there were
no specific changes I would say let's not do a quirk and change the driver
to skip reset on resume.
Thanks.
--
Dmitry
Hi Jingle,
On Fri, Mar 05, 2021 at 09:50:35AM +0800, jingle wrote:
HI Dmitry:
1. You mean to let all devices ignore skipping reset/sleep part of device
initialization?
2. The test team found that some old firmware will have errors (invalid
report etc...), so ELAN can only ensure that the new device can meet the
newer parts.
I see. OK, fair enough.
I would prefer if we were more explicit about when we skip resetting the
device, what do you think about the version of your patch below?
Thanks.
--
Dmitry
Input: elan_i2c - reduce the resume time for new devices
From: Jingle Wu <redacted>
Newer controllers, such as Voxel, Delbin, Magple, Bobba and others, do not
need to be reset after issuing power-on command, and skipping reset saves
at least 100ms from resume time.
Note that if first attempt of re-initializing device fails we will not be
skipping reset on the subsequent ones.
Signed-off-by: Jingle Wu <redacted>
Link: https://lore.kernel.org/r/20210226073537.4926-1-jingle.wu@emc.com.tw
Patchwork-Id: 12105967
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/elan_i2c.h | 5 +++
drivers/input/mouse/elan_i2c_core.c | 58 +++++++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 10 deletions(-)
@@ -46,6 +46,9 @@#define ETP_FINGER_WIDTH 15#define ETP_RETRY_COUNT 3+/* quirks to control the device */+#define ETP_QUIRK_QUICK_WAKEUP BIT(0)+/* The main device structure */structelan_tp_data{structi2c_client*client;
@@ -90,8 +93,38 @@ struct elan_tp_data {boolbaseline_ready;u8clickpad;boolmiddle_button;++u32quirks;/* Various quirks */};+staticu32elan_i2c_lookup_quirks(u16ic_type,u16product_id)+{+staticconststruct{+u16ic_type;+u16product_id;+u32quirks;+}elan_i2c_quirks[]={+{0x0D,ETP_PRODUCT_ID_DELBIN,ETP_QUIRK_QUICK_WAKEUP},+{0x10,ETP_PRODUCT_ID_VOXEL,ETP_QUIRK_QUICK_WAKEUP},+{0x14,ETP_PRODUCT_ID_MAGPIE,ETP_QUIRK_QUICK_WAKEUP},+{0x14,ETP_PRODUCT_ID_BOBBA,ETP_QUIRK_QUICK_WAKEUP},+};+u32quirks=0;+inti;++for(i=0;ARRAY_SIZE(elan_i2c_quirks);i++){+if(elan_i2c_quirks[i].ic_type==ic_type&&+elan_i2c_quirks[i].product_id==product_id){+quirks=elan_i2c_quirks[i].quirks;+}+}++if(ic_type>=0x0D&&product_id>=0x123)+quirks|=ETP_QUIRK_QUICK_WAKEUP;++returnquirks;+}+staticintelan_get_fwinfo(u16ic_type,u8iap_version,u16*validpage_count,u32*signature_address,u16*page_size){
Hi Dmitry:
1. missing "i<"
+ u32 quirks = 0;
+ int i;
+
+ for (i = 0; ARRAY_SIZE(elan_i2c_quirks); i++) {
-> for (i = 0; i<ARRAY_SIZE(elan_i2c_quirks); i++) {
2. elan_resume () funtion are different with at Chromeos driver.
@@ -1384,7 +1422,7 @@ static int __maybe_unused elan_resume(struct device
*dev)
goto err;
}
- error = elan_initialize(data);
+ error = elan_initialize(data, data->quirks &
ETP_QUIRK_QUICK_WAKEUP);
if (error)
dev_err(dev, "initialize when resuming failed: %d\n",
error);
-> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ref
-> s/heads/chromeos-5.4/drivers/input/mouse/elan_i2c_core.c#1434
-> error = elan_initialize(data); this code is in elan_reactivate()
function at Chromeos driver.
-> Will this change affect cherrypick from linux kernel to chromeos?
THANKS
JINGLE
-----Original Message-----
From: 'Dmitry Torokhov' [mailto:dmitry.torokhov@gmail.com]
Sent: Monday, March 08, 2021 11:18 AM
To: jingle
Cc: 'linux-kernel'; 'linux-input'; 'phoenix'; 'dave.wang'; 'josh.chen'
Subject: Re: [PATCH] Input: elan_i2c - Reduce the resume time for new dev
ices
Hi Jingle,
On Fri, Mar 05, 2021 at 09:50:35AM +0800, jingle wrote:
HI Dmitry:
1. You mean to let all devices ignore skipping reset/sleep part of
device initialization?
2. The test team found that some old firmware will have errors
(invalid report etc...), so ELAN can only ensure that the new device
can meet the newer parts.
I see. OK, fair enough.
I would prefer if we were more explicit about when we skip resetting the
device, what do you think about the version of your patch below?
Thanks.
--
Dmitry
Input: elan_i2c - reduce the resume time for new devices
From: Jingle Wu <redacted>
Newer controllers, such as Voxel, Delbin, Magple, Bobba and others, do not
need to be reset after issuing power-on command, and skipping reset saves
at least 100ms from resume time.
Note that if first attempt of re-initializing device fails we will not be
skipping reset on the subsequent ones.
Signed-off-by: Jingle Wu <redacted>
Link: https://lore.kernel.org/r/20210226073537.4926-1-jingle.wu@emc.com.tw
Patchwork-Id: 12105967
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/elan_i2c.h | 5 +++
drivers/input/mouse/elan_i2c_core.c | 58
+++++++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 10 deletions(-)
@@ -46,6 +46,9 @@#define ETP_FINGER_WIDTH 15#define ETP_RETRY_COUNT 3+/* quirks to control the device */+#define ETP_QUIRK_QUICK_WAKEUP BIT(0)+/* The main device structure */structelan_tp_data{structi2c_client*client;
@@ -90,8 +93,38 @@ struct elan_tp_data {boolbaseline_ready;u8clickpad;boolmiddle_button;++u32quirks;/* Various quirks */};+staticu32elan_i2c_lookup_quirks(u16ic_type,u16product_id)+{+staticconststruct{+u16ic_type;+u16product_id;+u32quirks;+}elan_i2c_quirks[]={+{0x0D,ETP_PRODUCT_ID_DELBIN,ETP_QUIRK_QUICK_WAKEUP},+{0x10,ETP_PRODUCT_ID_VOXEL,ETP_QUIRK_QUICK_WAKEUP},+{0x14,ETP_PRODUCT_ID_MAGPIE,ETP_QUIRK_QUICK_WAKEUP},+{0x14,ETP_PRODUCT_ID_BOBBA,ETP_QUIRK_QUICK_WAKEUP},+};+u32quirks=0;+inti;++for(i=0;ARRAY_SIZE(elan_i2c_quirks);i++){+if(elan_i2c_quirks[i].ic_type==ic_type&&+elan_i2c_quirks[i].product_id==product_id){+quirks=elan_i2c_quirks[i].quirks;+}+}++if(ic_type>=0x0D&&product_id>=0x123)+quirks|=ETP_QUIRK_QUICK_WAKEUP;++returnquirks;+}+staticintelan_get_fwinfo(u16ic_type,u8iap_version,u16
Hi Jingle,
On Mon, Mar 08, 2021 at 04:56:14PM +0800, jingle wrote:
Hi Dmitry:
1. missing "i<"
+ u32 quirks = 0;
+ int i;
+
+ for (i = 0; ARRAY_SIZE(elan_i2c_quirks); i++) {
-> for (i = 0; i<ARRAY_SIZE(elan_i2c_quirks); i++) {
Yes, you are right of course. Was this the only issue with the updated
patch? Did it work for you otherwise?
quoted hunk
2. elan_resume () funtion are different with at Chromeos driver.
@@ -1384,7 +1422,7 @@ static int __maybe_unused elan_resume(struct device
*dev)
goto err;
}
- error = elan_initialize(data);
+ error = elan_initialize(data, data->quirks &
ETP_QUIRK_QUICK_WAKEUP);
if (error)
dev_err(dev, "initialize when resuming failed: %d\n",
error);
-> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ref
-> s/heads/chromeos-5.4/drivers/input/mouse/elan_i2c_core.c#1434
-> error = elan_initialize(data); this code is in elan_reactivate()
function at Chromeos driver.
-> Will this change affect cherrypick from linux kernel to chromeos?
Yes, we would need to adjust the patch for Chrome OS and have
elan_reactivate() to call elan_initialize() with appropriate argument.
Thanks.
--
Dmitry