Input: Switch i2c drivers back to use .probe()

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 (

Input: Switch i2c drivers back to use .probe()

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230517164645.162294-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()

SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of

Input: st1232 - switch to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr()

SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: John Keeping <john@metanate.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-61-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - Convert to i2c's .probe_new()

.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.

Signed-off-by: Uwe Kleine-König <u.kleine-k

Input: st1232 - Convert to i2c's .probe_new()

.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20221118224540.619276-260-uwe@kleine-koenig.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - prefer asynchronous probing

The device may take up to 100ms to become responsive during probe, so
prefer asynchronous probing to avoid delaying the rest of the system.

Suggested-by:

Input: st1232 - prefer asynchronous probing

The device may take up to 100ms to become responsive during probe, so
prefer asynchronous probing to avoid delaying the rest of the system.

Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20211007111217.1935858-1-john@metanate.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - increase "wait ready" timeout

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 100m

Input: st1232 - increase "wait ready" timeout

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 <john@metanate.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - increase "wait ready" timeout

[ Upstream commit 2667f6b7af99e81958fa97c03bb519fcb09d0055 ]

I have a ST1633 touch controller which fails to probe due to a timeout
waiting for the con

Input: st1232 - increase "wait ready" timeout

[ 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 <john@metanate.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Input: st1232 - fix NORMAL vs. IDLE state handling

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,
breaki

Input: st1232 - fix NORMAL vs. IDLE state handling

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 <geert+renesas@glider.be>
Reviewed-by: Michael Tretter <m.tretter@pengutronix.de>
Link: https://lore.kernel.org/r/20210223090201.1430542-1-geert+renesas@glider.be
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - add IDLE state as ready condition

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 a

Input: st1232 - add IDLE state as ready condition

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 <m.tretter@pengutronix.de>
Link: https://lore.kernel.org/r/20210219110556.1858969-1-m.tretter@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

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

According to the st1232 datasheet, the host has to wait for the device
to change into Normal state before accessing registers oth

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

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 <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201229162601.2154566-4-geert+renesas@glider.be
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - do not read more bytes than needed

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

Input: st1232 - do not read more bytes than needed

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 <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201229162601.2154566-3-geert+renesas@glider.be
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

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

Before, the maximum coordinates were fixed to (799, 479) or (319, 479),
depending on touchscreen controller type. The driver was changed

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

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 <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201229162601.2154566-2-geert+renesas@glider.be
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - add support resolution reading

Hard-coding resolution for st1633 device was wrong. Some of LCDs like
YTS700TLBC-02-100C has assembled Sitronix st1633 touchcontroller too. But
the res

Input: st1232 - add support resolution reading

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 <andrej.valek@siemens.com>
Link: https://lore.kernel.org/r/20201103073949.12198-1-andrej.valek@siemens.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - switch to using MT-B protocol

Switch the driver to the slotted variant of multitouch protocol (MT-B)
with in-kernel tracking of the contacts.

Tested-by: Matthias Fend <Matthias.Fend

Input: st1232 - switch to using MT-B protocol

Switch the driver to the slotted variant of multitouch protocol (MT-B)
with in-kernel tracking of the contacts.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

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

The receiving buffer is allocated separately from the main driver
data structure, and is naturally DMA-safe, so mark it as such when
building

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

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 <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - do not set parent device explicitly

devm_input_allocate_device() already sets parent device for us.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Tor

Input: st1232 - do not set parent device explicitly

devm_input_allocate_device() already sets parent device for us.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - do not allocate fingers data separately

The finger structure size is quite small and allocating it together with
the main driver structure will not increase likelyhood of allocation

Input: st1232 - do not allocate fingers data separately

The finger structure size is quite small and allocating it together with
the main driver structure will not increase likelyhood of allocation
failing, but reduces number of objects needing to be tracked by the
allocator and devm.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - do not reset the chip too early

We should not be putting the chip into reset while interrupts are enabled
and ISR may be running. Fix this by installing a custom devm action and
powe

Input: st1232 - do not reset the chip too early

We should not be putting the chip into reset while interrupts are enabled
and ISR may be running. Fix this by installing a custom devm action and
powering off the device/resetting GPIO line from there. This ensures proper
ordering.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - rely on I2C core to configure wakeup interrupt

When I2C client is created with I2C_CLIENT_WAKE flag (which happens
either because we have "wakeup-source" device property or the flag

Input: st1232 - rely on I2C core to configure wakeup interrupt

When I2C client is created with I2C_CLIENT_WAKE flag (which happens
either because we have "wakeup-source" device property or the flag
was passed in when creating an I2C client manually), I2C core will
take care of configuring interrupt as wakeup source on suspend.

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - do not unconditionally configure as wakeup source

Do not unconditionally configure the touchscreen as wakeup source but
rather rely on I2C core to do that when requested (either via

Input: st1232 - do not unconditionally configure as wakeup source

Do not unconditionally configure the touchscreen as wakeup source but
rather rely on I2C core to do that when requested (either via
"wakeup-source" device property, or when creating a client with
I2C_CLIENT_WAKE flag).

Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - simplify parsing of read buffer

Avoid complex 2-variable loop when parsing touchscreen data to make the
code clearer.

Acked-by: Martin Kepplinger <martink@posteo.de>
Tested-by: Matt

Input: st1232 - simplify parsing of read buffer

Avoid complex 2-variable loop when parsing touchscreen data to make the
code clearer.

Acked-by: Martin Kepplinger <martink@posteo.de>
Tested-by: Matthias Fend <Matthias.Fend@wolfvision.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - fix reporting multitouch coordinates

For Sitronix st1633 multi-touch controller driver the coordinates reported
for multiple fingers were wrong, as it was always taking LSB of coordi

Input: st1232 - fix reporting multitouch coordinates

For Sitronix st1633 multi-touch controller driver the coordinates reported
for multiple fingers were wrong, as it was always taking LSB of coordinates
from the first contact data.

Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Reviewed-by: Martin Kepplinger <martink@posteo.de>
Cc: stable@vger.kernel.org
Fixes: 351e0592bfea ("Input: st1232 - add support for st1633")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204561
Link: https://lore.kernel.org/r/1566209314-21767-1-git-send-email-dixitparmar19@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - handle common DT bindings

This is required to specify generic touchscreen properties via DT.

Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
Reviewed-by: Rob Herring <ro

Input: st1232 - handle common DT bindings

This is required to specify generic touchscreen properties via DT.

Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - switch to gpiod API

Use devm_gpiod_get_optional() and gpiod_set_value_cansleep() instead
of the old API. The st1232_ts_power() now passes on the inverted "poweron"
value to reflect t

Input: st1232 - switch to gpiod API

Use devm_gpiod_get_optional() and gpiod_set_value_cansleep() instead
of the old API. The st1232_ts_power() now passes on the inverted "poweron"
value to reflect the correct logical value.

Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - add Martin as module author

This adds myself as an author of the st1232 driver module as Tony's
email address doesn't seem to work anymore.

Signed-off-by: Martin Kepplinger <martin.

Input: st1232 - add Martin as module author

This adds myself as an author of the st1232 driver module as Tony's
email address doesn't seem to work anymore.

Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...

Input: st1232 - add support for st1633

Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver. A protocol spec can be found here:
www.ampdisplay.com/documents/pdf/AM-320480B

Input: st1232 - add support for st1633

Add support for the Sitronix ST1633 touchscreen controller to the st1232
driver. A protocol spec can be found here:
www.ampdisplay.com/documents/pdf/AM-320480B6TZQW-TC0H.pdf

Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

show more ...