From: Michael Zaidman <michael.zaidman@gmail.com>
To: jikos@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-i2c@vger.kernel.org, germain.hebert@ca.abb.com,
Enrik.Berkhan@inka.de,
Michael Zaidman <michael.zaidman@gmail.com>,
Guillaume Champagne <champagne.guillaume.c@gmail.com>
Subject: [PATCH v3 02/12] HID: ft260: improve i2c write performance
Date: Sun, 30 Oct 2022 22:33:53 +0200 [thread overview]
Message-ID: <20221030203403.4637-3-michael.zaidman@gmail.com> (raw)
In-Reply-To: <20221030203403.4637-1-michael.zaidman@gmail.com>
The patch improves the I2C write performance by 20 - 30 percent by
revising the sleep time in the ft260_hid_output_report_check_status()
in the following ways:
1. Reduce the wait time and start to poll earlier.
Sending a large amount of data at a low I2C clock rate saturates the
internal FT260 buffer and causes hiccups in status readiness, as shown
below in the log fragment. Aligning the status check wait time to the
worst case significantly reduces the write performance.
[Oct22 10:28] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.005296] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.013460] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003244] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000190] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.015324] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003491] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000202] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.016047] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.002768] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000150] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011389] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003467] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000191] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000172] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000131] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000241] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000190] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000196] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011314] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
[ +0.003334] ft260_hid_output_report_check_status: wait 1920 usec, len 38
[ +0.000227] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000204] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000198] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000147] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.011060] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0
Before:
$ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
40510 80 256 8 32
After:
$ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
52584 80 256 8 32
2. Do not sleep if the estimated I2C transfer time is below 2 ms since
the first xfer status query frequently takes around 1.5 ms, and the
following status queries take about 200us on average. So we usually
return from the routine after the first 1 - 3 status checks.
[Oct22 11:14] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.004270] ft260_xfer_status: bus_status 0x20, clock 100
[ +0.013889] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.000856] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000138] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.013352] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.001501] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000177] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.014477] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
[ +0.001377] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100
[ +0.000191] ft260_xfer_status: bus_status 0x40, clock 100
[ +0.013197] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0
Before:
$ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
28826 73 256 16 16
After:
$ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S
Fill block with increment via i2ctransfer by chunks
-------------------------------------------------------------------
data rate(bps) efficiency(%) data size(B) total IOs IO size(B)
-------------------------------------------------------------------
45138 73 256 16 16
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
---
drivers/hid/hid-ft260.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index a35201d68b15..44106cadd746 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -345,7 +345,7 @@ static int ft260_hid_output_report(struct hid_device *hdev, u8 *data,
static int ft260_hid_output_report_check_status(struct ft260_device *dev,
u8 *data, int len)
{
- int ret, usec, try = 3;
+ int ret, usec, try = 100;
struct hid_device *hdev = dev->hdev;
ret = ft260_hid_output_report(hdev, data, len);
@@ -356,10 +356,14 @@ static int ft260_hid_output_report_check_status(struct ft260_device *dev,
return ret;
}
- /* transfer time = 1 / clock(KHz) * 10 bits * bytes */
- usec = 10000 / dev->clock * len;
- usleep_range(usec, usec + 100);
- ft260_dbg("wait %d usec, len %d\n", usec, len);
+ /* transfer time = 1 / clock(KHz) * 9 bits * bytes */
+ usec = len * 9000 / dev->clock;
+ if (usec > 2000) {
+ usec -= 1500;
+ usleep_range(usec, usec + 100);
+ ft260_dbg("wait %d usec, len %d\n", usec, len);
+ }
+
do {
ret = ft260_xfer_status(dev);
if (ret != -EAGAIN)
--
2.34.1
next prev parent reply other threads:[~2022-10-30 20:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-30 20:33 [PATCH v3 00/12] HID: ft260: fixes and performance improvements Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 01/12] HID: ft260: ft260_xfer_status routine cleanup Michael Zaidman
2022-10-30 20:33 ` Michael Zaidman [this message]
2022-10-30 20:33 ` [PATCH v3 03/12] HID: ft260: support i2c writes larger than HID report size Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 04/12] HID: ft260: support i2c reads greater " Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 05/12] HID: ft260: improve i2c large reads performance Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 06/12] HID: ft260: do not populate /dev/hidraw device Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 07/12] HID: ft260: skip unexpected HID input reports Michael Zaidman
2022-10-30 20:33 ` [PATCH v3 08/12] HID: ft260: remove SMBus Quick command support Michael Zaidman
2022-10-30 20:34 ` [PATCH v3 09/12] HID: ft260: missed NACK from big i2c read Michael Zaidman
2022-10-30 20:34 ` [PATCH v3 10/12] HID: ft260: wake up device from power saving mode Michael Zaidman
2022-10-31 17:12 ` Enrik Berkhan
2022-10-30 20:34 ` [PATCH v3 11/12] HID: ft260: fix a NULL pointer dereference in ft260_i2c_write Michael Zaidman
2022-10-30 20:34 ` [PATCH v3 12/12] HID: ft260: missed NACK from busy device Michael Zaidman
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=20221030203403.4637-3-michael.zaidman@gmail.com \
--to=michael.zaidman@gmail.com \
--cc=Enrik.Berkhan@inka.de \
--cc=champagne.guillaume.c@gmail.com \
--cc=germain.hebert@ca.abb.com \
--cc=jikos@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@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).