kernel/linux.git/drivers/input/touchscreen/elants_i2c.c, branch v6.3

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

2023-01-10T04:25:25+00:00

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 Cc: Douglas Anderson Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20230102181842.718010-46-jic23@kernel.org Signed-off-by: Dmitry Torokhov

Input: elants_i2c - delay longer with reset asserted

2022-12-09T02:19:48+00:00

The elan touchscreen datasheet says that the reset GPIO only needs to be asserted for 500us in order to reset the regulator. The problem is that some boards need a level shifter between the signals on the GPIO controller and the signals on the touchscreen. All of these extra components on the line can slow the transition of the signals. On one board, we measured the reset line and saw that it took almost 1.8ms to go low. Even after we bumped up the "drive strength" of the signal from the default 2mA to 8mA we still saw it take 421us for the signal to go low. In order to account for this let's lengthen the amount of time that we keep the reset asserted. Let's bump it up from 500us to 5000us. That's still a relatively short amount of time and is much safer. It should be noted that this fixes real problems. Case in point: 1. The touchscreen power rail may be shared with another device (like an eDP panel). That means that at probe time power might already be on. 2. In probe we grab the reset GPIO and assert it (make it low). 3. We turn on power (a noop since it was already on). 4. We wait 500us. 5. We deassert the reset GPIO. With the above case and only a 500us delay we saw only a partial reset asserted, which is bad. Giving it 5ms is overkill but feels safer in case someone else has a different level shifter setup. Note that bumping up the delay to 5000 means that some configs yell about using udelay(). We'll change to using usleep_range(). We give a small range here because: - This isn't a delay that happens very often so we don't need to worry about giving a big range to allow for power efficiency. - usleep_range() is known to almost always pick the upper bound and delay that long and we really don't want to slow down the power on of the touchscreen that much. Signed-off-by: Douglas Anderson Reviewed-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20221208180603.v2.5.I6edfb3f459662c041563a54e5b7df727c27caaba@changeid Signed-off-by: Dmitry Torokhov

Input: elants_i2c - delete some dead code

2022-11-29T23:02:46+00:00

We shuffled the error handling around so this condition is dead code now. The "error" variable is always zero. Signed-off-by: Dan Carpenter Reviewed-by: Douglas Anderson Reviewed-by: Mattijs Korpershoek Link: https://lore.kernel.org/r/Y33BD9xkRC9euIdO@kili Signed-off-by: Dmitry Torokhov

Input: elants_i2c - don't set wake_capable and wake_irq

2022-11-22T21:59:27+00:00

The i2c-core will now handle setting the wake_irq and wake capability for DT and ACPI systems. Signed-off-by: Raul E Rangel Link: https://lore.kernel.org/r/20220929093200.v6.12.I031ffbe411e1bae20bf16a1876da5baf444c7928@changeid Signed-off-by: Dmitry Torokhov

Input: elants_i2c - use PM subsystem to manage wake irq

2022-11-22T21:58:48+00:00

The Elan I2C touchscreen driver is currently manually managing the wake IRQ. This change removes the explicit enable_irq_wake/disable_irq_wake and instead relies on the PM subsystem. This is done by calling dev_pm_set_wake_irq. i2c_device_probe already calls dev_pm_set_wake_irq when using device tree, and i2c_device_remove also already calls dev_pm_clear_wake_irq. There could be some device tree systems that have incorrectly declared `wake` capabilities, so this change will set the wake irq if one is missing. This matches the previous behavior. Signed-off-by: Raul E Rangel Link: https://lore.kernel.org/r/20220929093200.v6.3.I5862429ee3e4de0f9ad5ba01ce07ad99eec10cf0@changeid Signed-off-by: Dmitry Torokhov

Input: elants_i2c - properly handle the reset GPIO when power is off

2022-11-18T06:14:45+00:00

As can be seen in elants_i2c_power_off(), we want the reset GPIO asserted when power is off. The reset GPIO is active low so we need the reset line logic low when power is off to avoid leakage. We have a problem, though, at probe time. At probe time we haven't powered the regulators on yet but we have: devm_gpiod_get(&client->dev, "reset", GPIOD_OUT_LOW); While that _looks_ right, it turns out that it's not. The GPIOD_OUT_LOW doesn't mean to init the GPIO to low. It means init the GPIO to "not asserted". Since this is an active low GPIO that inits it to be high. Let's fix this to properly init the GPIO. Now after both probe and power off the state of the GPIO is consistent (it's "asserted" or level low). Once we fix this, we can see that at power on time we no longer to assert the reset GPIO as the first thing. The reset GPIO is _always_ asserted before powering on. Let's fix powering on to account for this. Fixes: afe10358e47a ("Input: elants_i2c - wire up regulator support") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20221117123805.1.I9959ac561dd6e1e8e1ce7085e4de6167b27c574f@changeid Signed-off-by: Dmitry Torokhov

Input: elants_i2c - do not check Remark ID on eKTH3900/eKTH5312

2021-12-20T09:01:05+00:00

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 Link: https://lore.kernel.org/r/1639619603-20616-1-git-send-email-johnny.chuang.emc@gmail.com Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2021-11-12T05:58:54+00:00

Prepare input updates for 5.16 merge window.

Input: elants_i2c - make use of devm_add_action_or_reset()

2021-09-23T04:56:47+00:00

The helper function devm_add_action_or_reset() will internally call devm_add_action(), and if devm_add_action() fails then it will execute the action mentioned and return the error code. So use devm_add_action_or_reset() instead of devm_add_action() to simplify the error handling, reduce the code. Signed-off-by: Cai Huoqing Link: https://lore.kernel.org/r/20210922125212.95-2-caihuoqing@baidu.com Signed-off-by: Dmitry Torokhov

Input: elants_i2c - switch to probe_new

2021-05-31T04:53:50+00:00

Now that we get rid of the usage of id argument at probe again, let's switch to the new i2c probe method; this will avoid for people misusing the possibly unassigned id pointer again. Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20210528071024.26450-2-tiwai@suse.de Signed-off-by: Dmitry Torokhov