The driver called pwm_config() and pwm_enable() separately. Today both
are wrappers for pwm_apply_might_sleep() and it's more effective to call
this function directly and only once. Also don't configure the
duty_cycle and period if the next operation is to disable the PWM so
configure the PWM in max77693_haptic_enable().
With the direct use of pwm_apply_might_sleep() the need to call
pwm_apply_args() in .probe() is now gone, too, so drop this one.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250630103851.2069952-2-u.kleine-koenig@baylibre.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some touch devices provide mechanical overlays with different objects
like buttons or clipped touchscreen surfaces.
In order to support these objects, add a series of helper functions
to the input subsystem to transform them into overlay objects via
device tree nodes.
These overlay objects consume the raw touch events and report the
expected input events depending on the object properties.
Note that the current implementation allows for multiple definitions
of touchscreen areas (regions that report touch events), but only the
first one will be used for the touchscreen device that the consumers
typically provide.
Should the need for multiple touchscreen areas arise, additional
touchscreen devices would be required at the consumer side.
There is no limitation in the number of touch areas defined as buttons.
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Link: https://lore.kernel.org/r/20241016-feature-ts_virtobj_patch-v11-2-b292a1bbb0a1@wolfvision.net
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Currently only F23 is correctly mapped for PS/2 keyboards.
According to this table:
https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf
- F24 and Zenkaku/Hankaku share the same scancode, but since in real world
Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the
scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is
currently not bound in xkeyboard-config, so it is (mostly*) unused anyway.
* Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for
some reason and it is actually used in a touchpad toggle shortcut, but this is
currently being fixed in both KDE and xkeyboard-config to make this less weird,
so it could directly be fixed to correctly handle the F24 keypress instead.
- The scancodes for F13-F22 are currently unmapped so there will probably be no
harm in mapping them. This would also fix the issue that some of these keys
can't be mapped as the target from userspace using the `setkeycodes` command.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Link: https://lore.kernel.org/r/20250722120438.28011-1-wse@tuxedocomputers.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Many controllers these days have started including grip buttons. As
there has been no particular assigned BTN_* constants for these, they've
been haphazardly assigned to BTN_TRIGGER_HAPPY*. Unfortunately, the
assignment of these has varied significantly between drivers.
Add and document new constants for these grip buttons.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20250702040102.125432-2-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Since dance pads can have both up/down or left/right pressed at the same time,
by design, they are not suitable for mapping the buttons to axes. Historically,
this driver mapped the D-pad to BTN_TRIGGER_HAPPY1-4 in these cases, and before
that as mouse buttons. However, BTN_DPAD_* exists for this and makes far more
sense than the arbitrary mapping it was before.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Link: https://lore.kernel.org/r/20250702034740.124817-1-vi@endrift.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
evdev has switched to match on EV_SYN instead of relying on non-zero
driver_info field to allow matching to all devices. Remove special
handling from input core.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Each input device has EV_SYN capability. This is enforced by the input
core which sets this capability bit unconditionally in
input_register_device().
Switch evdev matching from declaring non-zero id->driver_info to match
on EV_SYN so that special handling can be removed from
input_match_device() and "driver_info" field can be removed from
input_device_id structure.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The adp5589 support is based on legacy platform data and there's no
upstream platform using this device.
Moreover, recently, with
commit
480a8ad683 ("mfd: adp5585: Add Analog Devices ADP5585 core support")
we overlapped support for the adp5585 device (gpiochip part of it) but
since it actually makes sense for the device to be supported under MFD, we
can complement it and add the keymap support for it (properly based on FW
properties). And that is what
commit
04840c5363a6 ("Input: adp5585: Add Analog Devices ADP5585/89 support")
is doing.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-17-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for adding GPIs to the event FIFO. This is done by adding
irq_chip support. Like this, one can use the input gpio_keys driver as a
"frontend" device and input handler.
As part of this change, we now implement .request() and .free() as we can't
blindly consume all available pins as GPIOs (example: some pins can be
used for forming a keymap matrix).
Also note that the number of pins can now be obtained from the parent,
top level device. Hence the 'max_gpio' variable can be removed.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-15-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
The ADP558x family supports a built in keypad matrix decoder which can
be added as an Input device. In order to both support the Input and the
GPIO device, we need to create a bitmap of the supported pins and track
their usage since they can either be used as GPIOs (GPIs) or as part of
the keymap.
We also need to mark special pins busy in case some features are being
used (ex: pwm or reset events).
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-14-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
The ADP558x family of devices can be programmed to respond to some
especial events, In case of the unlock events, one can lock the keypad
and use KEYS or GPIs events to unlock it. For the reset events, one can
again use a combinations of GPIs/KEYs in order to generate an event that
will trigger the device to generate an output reset pulse.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-13-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add properties related to input events. These devices can act as
keyboards and can support events either via a keymap Matrix or through
GPIs. Note that the device needs to be an interrupt controller for GPIs
based events.
We specifically need a property specifying the pins used by the keymap
matrix since these devices have no requirement for rows and columns to be
contiguous without holes which is enforced by the standard input
properties.
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-11-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
Support the adp5589 I/O expander which supports up to 19 pins. We need
to add a chip_info based struct since accessing register "banks"
and "bits" differs between devices.
Also some register addresses are different.
While at it move ADP558X_GPIO_MAX defines to the main header file and
rename them. That information will be needed by the top level device in
a following change.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-9-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
There are some differences in the register map between the devices.
Hence, add a register structure per device. This will be needed in
following patches.
On top of that adp5585_fill_regmap_config() is renamed and reworked so
that the current struct adp5585_info act as template (they indeed
contain all the different data between variants) which can then be
complemented depending on the device (as identified by the id register).
This is done like this since a lot of the data is pretty much the same
between variants of the same device.
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-8-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
The only thing changing between variants is the regmap default
registers. Hence, instead of having a regmap configuration for every
variant (duplicating lots of fields), add a chip info type of structure
with a regmap ID to identify which defaults to use and populate
regmap_config at runtime given a template plus the id. Also note that
between variants, the defaults can be the same which means the chip info
structure can be used in more than one compatible.
This will also make it simpler adding new chips with more variants.
Also note that the chip info structures are deliberately not const as
they will also contain lots of members that are the same between the
different devices variants and so we will fill those at runtime.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20250701-dev-adp5589-fw-v7-6-b1fcfe9e9826@analog.com
Signed-off-by: Lee Jones <lee@kernel.org>
