- 15 Jan, 2022 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 5.17 merge window.
-
- 10 Jan, 2022 1 commit
-
-
Qinghua Jin authored
change 'postion' to 'position' Signed-off-by:
Qinghua Jin <qhjin.dev@gmail.com> Link: https://lore.kernel.org/r/20220106084215.355295-1-qhjin.dev@gmail.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 09 Jan, 2022 5 commits
-
-
Nikita Travkin authored
Zinitix BT532 is another touch controller that seem to implement the same interface as an already supported BT541. Add it to the driver. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20220106072840.36851-5-nikita@trvn.ruSigned-off-by:
-
Linus Walleij authored
The supply names of the Zinitix touchscreen were a bit confused, the new bindings rectifies this. To deal with old and new devicetrees, first check if we have "vddo" and in case that exists assume the old supply names. Else go and look for the new ones. We cannot just get the regulators since we would get an OK and a dummy regulator: we need to check explicitly for the old supply name. Use struct device *dev as a local variable instead of the I2C client since the device is what we are actually obtaining the resources from. Signed-off-by:
-
Linus Walleij authored
This converts the Zinitix BT4xx and BT5xx touchscreen bindings to YAML, fix them up a bit and extends them. We list all the existing BT4xx and BT5xx components with compatible strings. These are all similar, use the same bindings and work in similar ways. We rename the supplies from the erroneous vdd/vddo to the actual supply names vcca/vdd as specified on the actual component. It is long established that supplies shall be named after the supply pin names of a component. The confusion probably stems from that in a certain product the rails to the component were named vdd/vddo. Drop some notes on how OS implementations should avoid confusion by first looking for vddo, and if that exists assume the legacy binding pair and otherwise use vcca/vdd. Add reset-gpios as sometimes manufacturers pulls a GPIO line to the reset line on the chip. Add optional touchscreen-fuzz-x and touchscreen-fuzz-y properties. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Nikita Travkin authored
Since irq request is the last thing in the driver probe, it happens later than the input device registration. This means that there is a small time window where if the open method is called the driver will attempt to enable not yet available irq. Fix that by moving the irq request before the input device registration. Reviewed-by:
-
Hans de Goede authored
The power button on Cherry Trail systems with an AXP288 PMIC is connected to both the power button pin of the PMIC as well as to a power button GPIO on the Cherry Trail SoC itself. This leads to double power button event reporting which is a problem. Since reporting power button presses through the PMIC is not supported on all PMICs used on Cherry Trail systems, we want to keep the GPIO power button events, so the axp20x-pek code checks for the presence of a GPIO power button and in that case does not register its input-device. On most systems the GPIO power button also can wake-up the system from suspend, so the axp20x-pek driver would also not register its interrupt handler. But on some systems there was a bug causing wakeup by the GPIO power button handler to not work. Commit 9747070c ("Input: axp20x-pek - always register interrupt handlers") was added as a work around for this registering the axp20x-pek interrupts, but not the input-device on Cherry Trail systems. In the mean time the root-cause of the GPIO power button wakeup events not working has been found and fixed by the "pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins" patch, so this is no longer necessary. This reverts the workaround going back to only registering the interrupt handlers on systems where we also register the input-device. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20220106111647.66520-1-hdegoede@redhat.comSigned-off-by:
-
- 04 Jan, 2022 1 commit
-
-
Christophe JAILLET authored
bitmap_parselist() already clears the 'bits' bitmap, so there is no need to clear it when it is allocated. This just wastes some cycles. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/d6ee621b9dd75b92f8831db365cee58dc2025322.1640813136.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
- 31 Dec, 2021 2 commits
-
-
Leo L. Schwab authored
The spaceball.c module was not properly parsing the movement reports coming from the device. The code read axis data as signed 16-bit little-endian values starting at offset 2. In fact, axis data in Spaceball movement reports are signed 16-bit big-endian values starting at offset 3. This was determined first by visually inspecting the data packets, and later verified by consulting: http://spacemice.org/pdf/SpaceBall_2003-3003_Protocol.pdf If this ever worked properly, it was in the time before Git... Signed-off-by:
Leo L. Schwab <ewhac@ewhac.org> Link: https://lore.kernel.org/r/20211221101630.1146385-1-ewhac@ewhac.org Cc: stable@vger.kernel.org Signed-off-by:
-
Pavel Skripkin authored
Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization. This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device() call. So this patch moves dev->work initialization before registering input device Fixes: 5a6eb676 ("Input: appletouch - improve powersaving for Geyser3 devices") Reported-and-tested-by: syzbot+b88c5eae27386b252bbd@syzkaller.appspotmail.com Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/20211230141151.17300-1-paskripkin@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
-
- 20 Dec, 2021 6 commits
-
-
Johnny Chuang authored
The eKTH3900/eKTH5312 series do not support the firmware update rules of Remark ID. Exclude these two series from checking it when updating the firmware in touch controllers. Signed-off-by:
Johnny Chuang <johnny.chuang.emc@gmail.com> Link: https://lore.kernel.org/r/1639619603-20616-1-git-send-email-johnny.chuang.emc@gmail.comSigned-off-by:
-
Xiang wangx authored
The double `the' in a comment is repeated, thus it should be removed. Signed-off-by:
Xiang wangx <wangxiang@cdjrlc.com> Link: https://lore.kernel.org/r/20211216082735.11948-1-wangxiang@cdjrlc.comSigned-off-by:
-
Colin Ian King authored
Variable penup is assigned a value but penup is never read later, it is redundant and can be removed. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211205000525.153999-1-colin.i.king@gmail.comSigned-off-by:
-
Dario Binacchi authored
The open delay time has to be applied only on the first sample of the X/Y coordinates because on the following samples the ADC channel is not changed. Removing this time from the samples after the first one, "ti,coordinate-readouts" greater than 1, decreases the total acquisition time, allowing to increase the number of acquired coordinates in the time unit. Signed-off-by:
Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20211212125358.14416-4-dariobin@libero.itSigned-off-by:
-
Dario Binacchi authored
The Z2 step configuration doesn't erase the SEL_INP_SWC_3_0 bit-field before setting the ADC channel. This way its value could be corrupted by the ADC channel selected for the Z1 coordinate. Fixes: 8c896308 ("input: ti_am335x_adc: use only FIFO0 and clean up a little") Signed-off-by:
-
Dario Binacchi authored
As reported by the STEPCONFIG[1-16] registered field descriptions of the TI reference manual, for the ADC "in single ended, SEL_INM_SWC_3_0 must be 1xxx". Unlike the Y and Z coordinates, this bit has not been set for the step configuration registers used to sample the X coordinate. Fixes: 1b8be32e ("Input: add support for TI Touchscreen controller") Signed-off-by:
-
- 13 Dec, 2021 5 commits
-
-
Hans de Goede authored
Some Silead touchscreens have support for an active (battery powered) pen, add support for this. So far pen-support has only been seen on X86/ACPI (non devicetree) devs, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new properties are deliberately not added to the existing silead devicetree-bindings documentation. Signed-off-by:
-
Hans de Goede authored
Unfortunately, at the time of writing this commit message, we have been unable to get permission from Silead, or from device OEMs, to distribute the necessary Silead firmware files in linux-firmware. On a whole bunch of devices the UEFI BIOS code contains a touchscreen driver, which contains an embedded copy of the firmware. The fw-loader code has a "platform" fallback mechanism, which together with info on the firmware from drivers/platform/x86/touchscreen_dmi.c will use the firmware from the UEFI driver when the firmware is missing from /lib/firmware. This makes the touchscreen work OOTB without users needing to manually download the firmware. The firmware bundled with the original Windows/Android is usually newer then the firmware in the UEFI driver and it is better calibrated. This better calibration can lead to significant differences in the reported min/max coordinates. Add support for a new (optional) "silead,efi-fw-min-max" property which provides a set of alternative min/max values to use for the x/y axis when the EFI embedded firmware is used. The new property is only used on (x86) devices which do not use devicetree, IOW it is not used in actual devicetree files. The devicetree-bindings maintainers have requested properties like these to not be added to the devicetree-bindings, so the new property is deliberately not added to the existing silead devicetree-bindings documentation. Signed-off-by:
-
Hans de Goede authored
2 small fixes for pen support 1. Set the id.vendor field for the pen input_dev 2. Fix a typo in a comment Signed-off-by:
-
Hans de Goede authored
goodix_get_gpio_config() errors are fatal (abort probe()) so log them at KERN_ERR level rather then as debug messages. Signed-off-by:
-
José Expósito authored
The "id_buf" buffer is stored in "data->raw_info_block" and freed by "mxt_free_object_table" in case of error. Return instead of jumping to avoid a double free. Addresses-Coverity-ID: 1474582 ("Double free") Fixes: 068bdb67 ("Input: atmel_mxt_ts - fix the firmware update") Signed-off-by:José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20211212194257.68879-1-jose.exposito89@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
-
- 10 Dec, 2021 1 commit
-
-
José Expósito authored
Addresses-Coverity-ID: 1493934 ("Resource leak") Signed-off-by:
-
- 09 Dec, 2021 2 commits
-
-
Hans de Goede authored
Some Goodix touchscreens have support for a (Goodix) active pen, add support for this. The info on how to detect when a pen is down and to detect when the stylus buttons are pressed was lifted from the out of tree Goodix driver with pen support written by Adya: https://gitlab.com/AdyaAdya/goodix-touchscreen-linux-driver/ Since there is no way to tell if pen support is present, the registering of the pen input_dev is delayed till the first pen event is detected. This has been tested on a Trekstor Surftab duo W1, a Chuwi Hi13 and a Cyberbook T116 tablet. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=202161 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204513Signed-off-by:
-
Dmitry Torokhov authored
Sync up with the mainline to get the latest APIs and DT bindings.
-
- 07 Dec, 2021 5 commits
-
-
Hans de Goede authored
Add d->model mapping for the "9111" model, this fixes uses using a wrong config_len of 240 bytes while the "9111" model uses only 186 bytes of config. Signed-off-by:
-
Charles Keepax authored
When converting a rumble into a periodic effect, for compatibility, the magnitude is effectively calculated using: magnitude = max(strong_rubble / 3 + weak_rubble / 6, 0x7fff); The rumble magnitudes are both u16 and the resulting magnitude is s16. The max is presumably an attempt to limit the result of the calculation to the maximum possible magnitude for the s16 result, and thus should be a min. However in the case of strong = weak = 0xffff, the result of the first part of the calculation is 0x7fff, meaning that the min would be redundant anyway, so simply remove the current max. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20211130135039.13726-1-ckeepax@opensource.cirrus.comSigned-off-by:
-
Colin Ian King authored
Don't populate a couple of arrays on the stack but instead make them static const. Also makes the object code smaller by a few hundred bytes. Signed-off-by:
-
Hans de Goede authored
Unless the controller is not responding at boot or after suspend/resume, the driver never resets the controller on x86/ACPI platforms. The driver still requesting the reset pin at probe() though in case it needs it. Until now the driver has always requested the reset pin with GPIOD_IN as type. The idea being to put the pin in high-impedance mode to save power until the driver actually wants to issue a reset. But this means that just requesting the pin can cause issues, since requesting it in another mode then GPIOD_ASIS may cause the pinctrl driver to touch the pin settings. We have already had issues before due to a bug in the pinctrl-cherryview.c driver which has been fixed in commit 921daeec ("pinctrl: cherryview: Preserve CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs"). And now it turns out that requesting the reset-pin as GPIOD_IN also stops the touchscreen from working on the GPD P2 max mini-laptop. The behavior of putting the pin in high-impedance mode relies on there being some external pull-up to keep it high and there seems to be no pull-up on the GPD P2 max, causing things to break. This commit fixes this by requesting the reset pin as is when using the x86/ACPI code paths to lookup the GPIOs; and by not dropping it back into input-mode in case the driver does end up issuing a reset for error-recovery. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209061 Fixes: a7d4b171 ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices") Cc: stable@vger.kernel.org Signed-off-by:
-
Samuel Čavoj authored
The ASUS UM325UA suffers from the same issue as the ASUS UX425UA, which is a very similar laptop. The i8042 device is not usable immediately after boot and fails to initialize, requiring a deferred retry. Enable the deferred probe quirk for the UM325UA. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256Signed-off-by:
Samuel Čavoj <samuel@cavoj.net> Link: https://lore.kernel.org/r/20211204015615.232948-1-samuel@cavoj.netSigned-off-by:
-
- 29 Nov, 2021 5 commits
-
-
Alistair Francis authored
Improve the query device fields to be more verbose. Signed-off-by:
Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20211118123545.102872-1-alistair@alistair23.meSigned-off-by:
-
Andrea Righi authored
The array param[] in elantech_change_report_id() must be at least 3 bytes, because elantech_read_reg_params() is calling ps2_command() with PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but it's defined in the stack as an array of 2 bytes, therefore we have a potential stack out-of-bounds access here, also confirmed by KASAN: [ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0 [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118 [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110 [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020 [ 6.512436] Workqueue: events_long serio_handle_event [ 6.512453] Call Trace: [ 6.512462] show_stack+0x52/0x58 [ 6.512474] dump_stack+0xa1/0xd3 [ 6.512487] print_address_description.constprop.0+0x1d/0x140 [ 6.512502] ? __ps2_command+0x372/0x7e0 [ 6.512516] __kasan_report.cold+0x7d/0x112 [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0 [ 6.512539] ? __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [ 6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [ 6.512601] ? dev_printk_emit+0xa2/0xd3 [ 6.512612] ? dev_vprintk_emit+0xc5/0xc5 [ 6.512621] ? __kasan_check_write+0x14/0x20 [ 6.512634] ? mutex_lock+0x8f/0xe0 [ 6.512643] ? __mutex_lock_slowpath+0x20/0x20 [ 6.512655] ps2_command+0x52/0x90 [ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse] [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse] [ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse] [ 6.512863] ? ps2_command+0x7f/0x90 [ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse] [ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse] [ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse] [ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse] [ 6.513122] ? phys_pmd_init+0x30e/0x521 [ 6.513137] elantech_init+0x8a/0x200 [psmouse] [ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse] [ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse] [ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse] [ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse] [ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse] [ 6.513519] ? mutex_unlock+0x22/0x40 [ 6.513526] ? ps2_command+0x7f/0x90 [ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse] [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse] [ 6.513624] psmouse_connect+0x272/0x530 [psmouse] [ 6.513669] serio_driver_probe+0x55/0x70 [ 6.513679] really_probe+0x190/0x720 [ 6.513689] driver_probe_device+0x160/0x1f0 [ 6.513697] device_driver_attach+0x119/0x130 [ 6.513705] ? device_driver_attach+0x130/0x130 [ 6.513713] __driver_attach+0xe7/0x1a0 [ 6.513720] ? device_driver_attach+0x130/0x130 [ 6.513728] bus_for_each_dev+0xfb/0x150 [ 6.513738] ? subsys_dev_iter_exit+0x10/0x10 [ 6.513748] ? _raw_write_unlock_bh+0x30/0x30 [ 6.513757] driver_attach+0x2d/0x40 [ 6.513764] serio_handle_event+0x199/0x3d0 [ 6.513775] process_one_work+0x471/0x740 [ 6.513785] worker_thread+0x2d2/0x790 [ 6.513794] ? process_one_work+0x740/0x740 [ 6.513802] kthread+0x1b4/0x1e0 [ 6.513809] ? set_kthread_struct+0x80/0x80 [ 6.513816] ret_from_fork+0x22/0x30 [ 6.513832] The buggy address belongs to the page: [ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7 [ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000 [ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 6.513872] page dumped because: kasan: bad access detected [ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame: [ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse] [ 6.513941] this frame has 1 object: [ 6.513947] [32, 34) 'param' [ 6.513956] Memory state around the buggy address: [ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 [ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00 [ 6.513982] ^ [ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00 [ 6.514000] ================================================================== Define param[] in elantech_change_report_id() as an array of 3 bytes to prevent the out-of-bounds access in the stack. Fixes: e4c90627 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode") BugLink: https://bugs.launchpad.net/bugs/1945590Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Reviewed-by:
Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.comSigned-off-by:
-
Geert Uytterhoeven authored
Use the FIELD_PREP() helper, instead of open-coding the same operation. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/f8831b88346b36fc6e01e0910d0db6c94287d2b4.1637593297.git.geert+renesas@glider.beSigned-off-by:
-
Jeff LaBundy authored
Some automated builds report a stack frame size in excess of 2 kB for iqs626_probe(); the culprit appears to be the call to iqs626_parse_prop(). To solve this problem, specify noinline_for_stack for all of the iqs626_parse_*() helper functions which are called inside a for loop within iqs626_parse_prop(). As a result, a build with '-Wframe-larger-than' as low as 512 is free of any such warnings. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Jeff LaBundy <jeff@labundy.com> Link: https://lore.kernel.org/r/20211129004104.453930-1-jeff@labundy.comSigned-off-by:
-
Takashi Iwai authored
We've got a bug report about the non-working keyboard on ASUS ZenBook UX425UA. It seems that the PS/2 device isn't ready immediately at boot but takes some seconds to get ready. Until now, the only workaround is to defer the probe, but it's available only when the driver is a module. However, many distros, including openSUSE as in the original report, build the PS/2 input drivers into kernel, hence it won't work easily. This patch adds the support for the deferred probe for i8042 stuff as a workaround of the problem above. When the deferred probe mode is enabled and the device couldn't be probed, it'll be repeated with the standard deferred probe mechanism. The deferred probe mode is enabled either via the new option i8042.probe_defer or via the quirk table entry. As of this patch, the quirk table contains only ASUS ZenBook UX425UA. The deferred probe part is based on Fabio's initial work. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256Signed-off-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
-
- 12 Nov, 2021 1 commit
-
-
Dmitry Torokhov authored
Prepare input updates for 5.16 merge window.
-
- 10 Nov, 2021 5 commits
-
-
Johan Hovold authored
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 48735862 ("Input: iforce - use DMA-safe buffer when getting IDs from USB") Signed-off-by:
Johan Hovold <johan@kernel.org> Cc: stable@vger.kernel.org # 5.3 Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.orgSigned-off-by:
-
Alistair Francis authored
To make the code easier to read use macros for the bit masks. Signed-off-by:
-
Marek Vasut authored
Modern devices may redraw display at 60 Hz, make sure we have one input sample per one frame. Reduce sample period to 15ms, so we would get up to 66.6 samples per second, although realistically with all the jitter and extra scheduling wiggle room, we would end up just above 60 samples per second. This should be a good compromise between sampling too often and sampling too seldom. Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20211108114145.84118-1-marex@denx.deSigned-off-by:
-
Marek Vasut authored
Currently the ili210x driver implements a threaded interrupt handler which starts upon edge on the interrupt line, and then polls the touch controller for samples. Every time a sample is obtained from the controller, the thread function checks whether further polling is required, and if so, waits fixed amount of time before polling for next sample. The delay between consecutive samples can thus vary greatly, because the I2C transfer required to retrieve the sample from the controller takes different amount of time on different platforms. Furthermore, different models of the touch controllers supported by this driver require different delays during retrieval of samples too. Instead of waiting fixed amount of time before polling for next sample, determine how much time passed since the beginning of sampling cycle and then wait only the remaining amount of time within the sampling cycle. This makes the driver deliver samples with equal spacing between them. Signed-off-by:
-
Marek Vasut authored
The ili251x touch controller needs 5ms delay between sending I2C device address and register address, and, writing or reading register data. According to downstream ili251x example code, this 5ms delay is not required when reading touch samples out of the controller. Implement such a special case. Signed-off-by:
-
