kernel/linux.git/drivers/input/touchscreen/st1232.c, branch v5.15.208

Input: st1232 - increase "wait ready" timeout

2021-11-18T18:17:01+00:00

[ Upstream commit 2667f6b7af99e81958fa97c03bb519fcb09d0055 ] I have a ST1633 touch controller which fails to probe due to a timeout waiting for the controller to become ready. Increasing the minimum delay to 100ms ensures that the probe sequence completes successfully. The ST1633 datasheet says nothing about the maximum delay here and the ST1232 I2C protocol document says "wait until" with no notion of a timeout. Since this only runs once during probe, being generous with the timout seems reasonable and most likely the device will become ready eventually. (It may be worth noting that I saw this issue with a PREEMPT_RT patched kernel which probably has tighter wakeups from usleep_range() than other preemption models.) Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by: John Keeping Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin

Input: st1232 - fix NORMAL vs. IDLE state handling

2021-02-23T17:35:33+00:00

NORMAL (0x0) and IDLE (0x4) are really two different states. Hence you cannot check for both using a bitmask, as that checks for IDLE only, breaking operation for devices that are in NORMAL state. Fix the wait function to report either state as ready. Fixes: 6524d8eac258452e ("Input: st1232 - add IDLE state as ready condition") Signed-off-by: Geert Uytterhoeven Reviewed-by: Michael Tretter Link: https://lore.kernel.org/r/20210223090201.1430542-1-geert+renesas@glider.be Signed-off-by: Dmitry Torokhov

Input: st1232 - add IDLE state as ready condition

2021-02-19T19:03:44+00:00

The st1232 can switch from NORMAL to IDLE state after the configured idle time (by default 8 s). If the st1232 is not reset during probe, it might already be ready but in IDLE state. Since it does not enter NORMAL state in this case, probe fails. Fix the wait function to report the IDLE state as ready, too. Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by: Michael Tretter Link: https://lore.kernel.org/r/20210219110556.1858969-1-m.tretter@pengutronix.de Signed-off-by: Dmitry Torokhov

Input: st1232 - wait until device is ready before reading resolution

2021-01-02T06:19:03+00:00

According to the st1232 datasheet, the host has to wait for the device to change into Normal state before accessing registers other than the Status Register. If the reset GPIO is wired, the device is powered on during driver probe, just before reading the resolution. However, the latter may happen before the device is ready, leading to a probe failure: st1232-ts 1-0055: Failed to read resolution: -6 Fix this by waiting until the device is ready, by trying to read the Status Register until it indicates so, or until timeout. On Armadillo 800 EVA, typically the first read fails with an I2C transfer error, while the second read indicates the device is ready. Fixes: 3a54a215410b1650 ("Input: st1232 - add support resolution reading") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20201229162601.2154566-4-geert+renesas@glider.be Signed-off-by: Dmitry Torokhov

Input: st1232 - do not read more bytes than needed

2021-01-02T06:19:02+00:00

st1232_ts_read_data() already reads ts->read_buf_len bytes (8 or 20 bytes) from the touchscreen controller. This was fine when it was used to read touch point coordinates only, but is overkill for reading the touchscreen resolution, which just needs 3 bytes. Optimize transfers by passing the wanted number of bytes. Fixes: 3a54a215410b1650 ("Input: st1232 - add support resolution reading") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20201229162601.2154566-3-geert+renesas@glider.be Signed-off-by: Dmitry Torokhov

Input: st1232 - fix off-by-one error in resolution handling

2021-01-02T06:19:00+00:00

Before, the maximum coordinates were fixed to (799, 479) or (319, 479), depending on touchscreen controller type. The driver was changed to read the actual values from the touchscreen controller, but did not take into account the returned values are not the maximum coordinates, but the touchscreen resolution (e.g. 800 and 480). Fix this by subtracting 1. Fixes: 3a54a215410b1650 ("Input: st1232 - add support resolution reading") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20201229162601.2154566-2-geert+renesas@glider.be Signed-off-by: Dmitry Torokhov

Input: st1232 - add support resolution reading

2020-11-12T01:54:12+00:00

Hard-coding resolution for st1633 device was wrong. Some of LCDs like YTS700TLBC-02-100C has assembled Sitronix st1633 touchcontroller too. But the resolution is not 320x480 as was hard-coded. Add new function which reads correct resolution directly from register. Signed-off-by: Andrej Valek Link: https://lore.kernel.org/r/20201103073949.12198-1-andrej.valek@siemens.com Signed-off-by: Dmitry Torokhov

Input: st1232 - switch to using MT-B protocol

2019-10-29T04:04:27+00:00

Switch the driver to the slotted variant of multitouch protocol (MT-B) with in-kernel tracking of the contacts. Tested-by: Matthias Fend Signed-off-by: Dmitry Torokhov

Input: st1232 - note that the receive buffer is DMA-safe

2019-10-29T04:04:16+00:00

The receiving buffer is allocated separately from the main driver data structure, and is naturally DMA-safe, so mark it as such when building I2C transfer message. Tested-by: Matthias Fend Signed-off-by: Dmitry Torokhov

Input: st1232 - do not set parent device explicitly

2019-10-29T04:03:55+00:00

devm_input_allocate_device() already sets parent device for us. Tested-by: Matthias Fend Signed-off-by: Dmitry Torokhov