* [PATCH 2/2] HID: wacom: Don't report anything prior to the tool entering range
From: Gerecke, Jason @ 2019-04-26 16:35 UTC (permalink / raw)
To: # v3.17+, Sasha Levin
Cc: linux-input, Ping Cheng, Aaron Armstrong Skomra, Jason Gerecke,
Aaron Armstrong Skomra
In-Reply-To: <CANRwn3Ru+7FGtsY=GaDa7pAJkuagdb6nFtvrFq1qhTWJR0rF9A@mail.gmail.com>
From: Jason Gerecke <jason.gerecke@wacom.com>
If the tool spends some time in prox before entering range, a series of
events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
have any clue about the pen whose data is being reported. We need to hold
off on reporting anything until the pen has entered range. Since we still
want to report events that occur "in prox" after the pen has *left* range
we use 'wacom-tool[0]' as the indicator that the pen did at one point
enter range and provide us/userspace with tool type and serial number
information.
Fixes: a48324de6d ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
Cc: <stable@vger.kernel.org> # 4.11+
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
---
Version of patch specifically targeted to stable v4.14.113
drivers/hid/wacom_wac.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 03b04bc742dd..e4aeffa56018 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1271,17 +1271,20 @@ static void wacom_intuos_pro2_bt_pen(struct wacom_wac *wacom)
input_report_abs(pen_input, ABS_Z, rotation);
input_report_abs(pen_input, ABS_WHEEL, get_unaligned_le16(&frame[11]));
}
- input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
- input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
- input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
- input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
- input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
+ if (wacom->tool[0]) {
+ input_report_abs(pen_input, ABS_PRESSURE, get_unaligned_le16(&frame[5]));
+ input_report_abs(pen_input, ABS_DISTANCE, range ? frame[13] : wacom->features.distance_max);
- input_report_key(pen_input, wacom->tool[0], prox);
- input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
- input_report_abs(pen_input, ABS_MISC,
- wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
+ input_report_key(pen_input, BTN_TOUCH, frame[0] & 0x01);
+ input_report_key(pen_input, BTN_STYLUS, frame[0] & 0x02);
+ input_report_key(pen_input, BTN_STYLUS2, frame[0] & 0x04);
+
+ input_report_key(pen_input, wacom->tool[0], prox);
+ input_event(pen_input, EV_MSC, MSC_SERIAL, wacom->serial[0]);
+ input_report_abs(pen_input, ABS_MISC,
+ wacom_intuos_id_mangle(wacom->id[0])); /* report tool id */
+ }
wacom->shared->stylus_in_proximity = prox;
--
2.21.0
^ permalink raw reply related
* gpio-keys-polled improvements v2
From: Enrico Weigelt, metux IT consult @ 2019-04-26 19:01 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
Hello folks,
here's v2 of my gpio-keys-polled queue.
changes v2:
* removed the change in mod_devicetable.h
(MODULE_DEVICE_TABLE_OF macro)
* reworked the patch for building w/o oftree, so it works
w/o the MODULE_DEVICE_TABLE_OF macro
have fun,
--mtx
^ permalink raw reply
* [PATCH v2 1/3] input: keyboard: gpio-keys-polled: use input name from pdata if available
From: Enrico Weigelt, metux IT consult @ 2019-04-26 19:01 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <1556305282-24148-1-git-send-email-info@metux.net>
Instead of hardcoding the input name to the driver name
('gpio-keys-polled'), allow the passing a name via platform data
('name' field was already present), but default to old behaviour
in case of NULL.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
drivers/input/keyboard/gpio_keys_polled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index edc7262..3312186 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -272,7 +272,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
input = poll_dev->input;
- input->name = pdev->name;
+ input->name = (pdata->name ? pdata->name : pdev->name);
input->phys = DRV_NAME"/input0";
input->id.bustype = BUS_HOST;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Enrico Weigelt, metux IT consult @ 2019-04-26 19:01 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <1556305282-24148-1-git-send-email-info@metux.net>
Support the recently introduced gpio lookup tables for
attaching to gpio lines. So, harcoded gpio numbers aren't
needed anymore.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
drivers/input/keyboard/gpio_keys_polled.c | 167 +++++++++++++++++++++---------
1 file changed, 119 insertions(+), 48 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 3312186..3f773b2 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -24,6 +24,7 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
+#include <linux/gpio/machine.h>
#include <linux/gpio_keys.h>
#include <linux/property.h>
@@ -227,6 +228,119 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
};
MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
+static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
+ struct device *dev,
+ int idx,
+ const char *desc)
+{
+ struct gpio_desc *gpiod;
+ struct fwnode_handle *child;
+ int x;
+
+ /* get the idx'th child node */
+ child = device_get_next_child_node(dev, NULL);
+ while (child && x) {
+ child = device_get_next_child_node(dev, child);
+ x--;
+ }
+
+ if (!child) {
+ dev_err(dev, "missing oftree child node #%d\n", idx);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpiod = devm_fwnode_get_gpiod_from_child(dev,
+ NULL,
+ child,
+ GPIOD_IN,
+ desc);
+ if (IS_ERR(gpiod)) {
+ if (PTR_ERR(gpiod) != -EPROBE_DEFER)
+ dev_err(dev,
+ "failed to get gpio: %ld\n",
+ PTR_ERR(gpiod));
+ fwnode_handle_put(child);
+ return gpiod;
+ }
+
+ return gpiod;
+}
+
+static struct gpio_desc *gpio_keys_polled_get_gpiod_legacy(
+ struct device *dev,
+ int idx,
+ const struct gpio_keys_button *button)
+{
+ /*
+ * Legacy GPIO number so request the GPIO here and
+ * convert it to descriptor.
+ */
+ unsigned int flags = GPIOF_IN;
+ struct gpio_desc *gpiod;
+ int error;
+
+ dev_info(dev, "hardcoded gpio IDs are deprecated.\n");
+
+ if (button->active_low)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ error = devm_gpio_request_one(dev, button->gpio,
+ flags, button->desc ? : DRV_NAME);
+ if (error) {
+ dev_err(dev,
+ "unable to claim gpio %u, err=%d\n",
+ button->gpio, error);
+ return ERR_PTR(error);
+ }
+
+ gpiod = gpio_to_desc(button->gpio);
+ if (!gpiod) {
+ dev_err(dev,
+ "unable to convert gpio %u to descriptor\n",
+ button->gpio);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return gpiod;
+}
+
+static struct gpio_desc *gpio_keys_polled_get_gpiod(
+ struct device *dev,
+ int idx,
+ const struct gpio_keys_button *button)
+{
+ struct gpio_desc *gpiod = NULL;
+ int error;
+
+ /* No legacy static platform data - use oftree */
+ if (!dev_get_platdata(dev)) {
+ return gpio_keys_polled_get_gpiod_fwnode(
+ dev, idx, button->desc);
+ }
+
+ gpiod = devm_gpiod_get_index(dev, NULL, idx, GPIOF_IN);
+
+ if (!IS_ERR(gpiod)) {
+ dev_info(dev, "picked gpiod idx %d from gpio table\n", idx);
+ gpiod_set_consumer_name(gpiod, button->desc ? : DRV_NAME);
+ return gpiod;
+ }
+
+ if (PTR_ERR(gpiod) != -ENOENT) {
+ dev_err(dev, "failed fetching gpiod #%d: %d\n",
+ idx, PTR_ERR(gpiod));
+ return gpiod;
+ }
+
+ /* Use legacy gpio id, if defined */
+ if (gpio_is_valid(button->gpio)) {
+ return gpio_keys_polled_get_gpiod_legacy(
+ dev, idx, button);
+ }
+
+ return ERR_PTR(-ENOENT);
+}
+
static int gpio_keys_polled_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -291,57 +405,14 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
if (button->wakeup) {
dev_err(dev, DRV_NAME " does not support wakeup\n");
- fwnode_handle_put(child);
return -EINVAL;
}
- if (!dev_get_platdata(dev)) {
- /* No legacy static platform data */
- child = device_get_next_child_node(dev, child);
- if (!child) {
- dev_err(dev, "missing child device node\n");
- return -EINVAL;
- }
-
- bdata->gpiod = devm_fwnode_get_gpiod_from_child(dev,
- NULL, child,
- GPIOD_IN,
- button->desc);
- if (IS_ERR(bdata->gpiod)) {
- error = PTR_ERR(bdata->gpiod);
- if (error != -EPROBE_DEFER)
- dev_err(dev,
- "failed to get gpio: %d\n",
- error);
- fwnode_handle_put(child);
- return error;
- }
- } else if (gpio_is_valid(button->gpio)) {
- /*
- * Legacy GPIO number so request the GPIO here and
- * convert it to descriptor.
- */
- unsigned flags = GPIOF_IN;
-
- if (button->active_low)
- flags |= GPIOF_ACTIVE_LOW;
-
- error = devm_gpio_request_one(dev, button->gpio,
- flags, button->desc ? : DRV_NAME);
- if (error) {
- dev_err(dev,
- "unable to claim gpio %u, err=%d\n",
- button->gpio, error);
- return error;
- }
-
- bdata->gpiod = gpio_to_desc(button->gpio);
- if (!bdata->gpiod) {
- dev_err(dev,
- "unable to convert gpio %u to descriptor\n",
- button->gpio);
- return -EINVAL;
- }
+ bdata->gpiod = gpio_keys_polled_get_gpiod(dev, i, button);
+
+ if (IS_ERR(bdata->gpiod)) {
+ dev_err(dev, "failed to fetch gpiod #%d\n", i);
+ return PTR_ERR(bdata->gpiod);
}
bdata->last_state = -1;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Enrico Weigelt, metux IT consult @ 2019-04-26 19:01 UTC (permalink / raw)
To: linux-kernel; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <1556305282-24148-1-git-send-email-info@metux.net>
we don't need to build in oftree probing stuff when oftree isn't
enabled at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
drivers/input/keyboard/gpio_keys_polled.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 3f773b2..65860bf 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -147,6 +147,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
static struct gpio_keys_platform_data *
gpio_keys_polled_get_devtree_pdata(struct device *dev)
{
+#ifdef CONFIG_OF
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
struct fwnode_handle *child;
@@ -200,6 +201,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
}
return pdata;
+#else /* CONFIG_OF */
+ return ERR_PTR(-ENOENT);
+#endif /* CONFIG_OF */
}
static void gpio_keys_polled_set_abs_params(struct input_dev *input,
@@ -222,11 +226,13 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
input_set_abs_params(input, code, min, max, 0, 0);
}
+#ifdef CONFIG_OF
static const struct of_device_id gpio_keys_polled_of_match[] = {
{ .compatible = "gpio-keys-polled", },
{ },
};
MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
+#endif /* CONFIG_OF */
static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
struct device *dev,
@@ -452,7 +458,9 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
.probe = gpio_keys_polled_probe,
.driver = {
.name = DRV_NAME,
+#ifdef CONFIG_OF
.of_match_table = gpio_keys_polled_of_match,
+#endif /* CONFIG_OF */
},
};
module_platform_driver(gpio_keys_polled_driver);
--
1.9.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: input: add GPIO controllable vibrator
From: Luca Weiss @ 2019-04-26 19:47 UTC (permalink / raw)
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT KEYBOARD, MOUSE, JOYSTICK , TOUCHSCREEN...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Luca Weiss
Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes for v5:
- Simply compatible property definition
- Remove reference to regulator schema
.../bindings/input/gpio-vibrator.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/gpio-vibrator.yaml
diff --git a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
new file mode 100644
index 000000000000..903475f52dbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/input/gpio-vibrator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO vibrator
+
+maintainers:
+ - Luca Weiss <luca@z3ntu.xyz>
+
+description: |+
+ Registers a GPIO device as vibrator, where the on/off capability is controlled by a GPIO.
+
+properties:
+ compatible:
+ const: gpio-vibrator
+
+ enable-gpios:
+ maxItems: 1
+
+ vcc-supply:
+ description: Regulator that provides power
+
+required:
+ - compatible
+ - enable-gpios
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ vibrator {
+ compatible = "gpio-vibrator";
+ enable-gpios = <&msmgpio 86 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <&pm8941_l18>;
+ };
--
2.21.0
^ permalink raw reply related
* [PATCH v5 2/3] Input: add a driver for GPIO controllable vibrators
From: Luca Weiss @ 2019-04-26 19:47 UTC (permalink / raw)
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT KEYBOARD, MOUSE, JOYSTICK , TOUCHSCREEN...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Luca Weiss
In-Reply-To: <20190426194747.22256-1-luca@z3ntu.xyz>
Provide a simple driver for GPIO controllable vibrators.
It will be used by the Fairphone 2.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/gpio-vibra.c | 209 ++++++++++++++++++++++++++++++++
3 files changed, 222 insertions(+)
create mode 100644 drivers/input/misc/gpio-vibra.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index e15ed1bb8558..6dfe9e2fe5b1 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
To compile this driver as a module, choose M here: the module
will be called gpio_decoder.
+config INPUT_GPIO_VIBRA
+ tristate "GPIO vibrator support"
+ depends on GPIOLIB || COMPILE_TEST
+ select INPUT_FF_MEMLESS
+ help
+ Say Y here to get support for GPIO based vibrator devices.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called gpio-vibra.
+
config INPUT_IXP4XX_BEEPER
tristate "IXP4XX Beeper support"
depends on ARCH_IXP4XX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b936c5b1d4ac..f38ebbdb05e2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
+obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.o
obj-$(CONFIG_INPUT_HISI_POWERKEY) += hisi_powerkey.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
diff --git a/drivers/input/misc/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
new file mode 100644
index 000000000000..b76c81015de9
--- /dev/null
+++ b/drivers/input/misc/gpio-vibra.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * GPIO vibrator driver
+ *
+ * Copyright (C) 2019 Luca Weiss <luca@z3ntu.xyz>
+ *
+ * Based on PWM vibrator driver:
+ * Copyright (C) 2017 Collabora Ltd.
+ *
+ * Based on previous work from:
+ * Copyright (C) 2012 Dmitry Torokhov <dmitry.torokhov@gmail.com>
+ *
+ * Based on PWM beeper driver:
+ * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/input.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+struct gpio_vibrator {
+ struct input_dev *input;
+ struct gpio_desc *gpio;
+ struct regulator *vcc;
+
+ struct work_struct play_work;
+ bool running;
+ bool vcc_on;
+};
+
+static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
+{
+ struct device *pdev = vibrator->input->dev.parent;
+ int err;
+
+ if (!vibrator->vcc_on) {
+ err = regulator_enable(vibrator->vcc);
+ if (err) {
+ dev_err(pdev, "failed to enable regulator: %d\n", err);
+ return err;
+ }
+ vibrator->vcc_on = true;
+ }
+
+ gpiod_set_value_cansleep(vibrator->gpio, 1);
+
+ return 0;
+}
+
+static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
+{
+ gpiod_set_value_cansleep(vibrator->gpio, 0);
+
+ if (vibrator->vcc_on) {
+ regulator_disable(vibrator->vcc);
+ vibrator->vcc_on = false;
+ }
+}
+
+static void gpio_vibrator_play_work(struct work_struct *work)
+{
+ struct gpio_vibrator *vibrator =
+ container_of(work, struct gpio_vibrator, play_work);
+
+ if (vibrator->running)
+ gpio_vibrator_start(vibrator);
+ else
+ gpio_vibrator_stop(vibrator);
+}
+
+static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
+ struct ff_effect *effect)
+{
+ struct gpio_vibrator *vibrator = input_get_drvdata(dev);
+
+ int level = effect->u.rumble.strong_magnitude;
+
+ if (!level)
+ level = effect->u.rumble.weak_magnitude;
+
+ if (level)
+ vibrator->running = true;
+ else
+ vibrator->running = false;
+
+ schedule_work(&vibrator->play_work);
+
+ return 0;
+}
+
+static void gpio_vibrator_close(struct input_dev *input)
+{
+ struct gpio_vibrator *vibrator = input_get_drvdata(input);
+
+ cancel_work_sync(&vibrator->play_work);
+ gpio_vibrator_stop(vibrator);
+ vibrator->running = false;
+}
+
+static int gpio_vibrator_probe(struct platform_device *pdev)
+{
+ struct gpio_vibrator *vibrator;
+ int err;
+
+ vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
+ if (!vibrator)
+ return -ENOMEM;
+
+ vibrator->input = devm_input_allocate_device(&pdev->dev);
+ if (!vibrator->input)
+ return -ENOMEM;
+
+ vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
+ err = PTR_ERR_OR_ZERO(vibrator->vcc);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to request regulator: %d\n",
+ err);
+ return err;
+ }
+
+ vibrator->gpio = devm_gpiod_get(&pdev->dev, "enable", GPIOD_OUT_LOW);
+ err = PTR_ERR_OR_ZERO(vibrator->gpio);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to request main gpio: %d\n",
+ err);
+ return err;
+ }
+
+ INIT_WORK(&vibrator->play_work, gpio_vibrator_play_work);
+
+ vibrator->input->name = "gpio-vibrator";
+ vibrator->input->id.bustype = BUS_HOST;
+ vibrator->input->close = gpio_vibrator_close;
+
+ input_set_drvdata(vibrator->input, vibrator);
+ input_set_capability(vibrator->input, EV_FF, FF_RUMBLE);
+
+ err = input_ff_create_memless(vibrator->input, NULL,
+ gpio_vibrator_play_effect);
+ if (err) {
+ dev_err(&pdev->dev, "Couldn't create FF dev: %d\n", err);
+ return err;
+ }
+
+ err = input_register_device(vibrator->input);
+ if (err) {
+ dev_err(&pdev->dev, "Couldn't register input dev: %d\n", err);
+ return err;
+ }
+
+ platform_set_drvdata(pdev, vibrator);
+
+ return 0;
+}
+
+static int __maybe_unused gpio_vibrator_suspend(struct device *dev)
+{
+ struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
+
+ cancel_work_sync(&vibrator->play_work);
+ if (vibrator->running)
+ gpio_vibrator_stop(vibrator);
+
+ return 0;
+}
+
+static int __maybe_unused gpio_vibrator_resume(struct device *dev)
+{
+ struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
+
+ if (vibrator->running)
+ gpio_vibrator_start(vibrator);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(gpio_vibrator_pm_ops,
+ gpio_vibrator_suspend, gpio_vibrator_resume);
+
+#ifdef CONFIG_OF
+static const struct of_device_id gpio_vibra_dt_match_table[] = {
+ { .compatible = "gpio-vibrator" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, gpio_vibra_dt_match_table);
+#endif
+
+static struct platform_driver gpio_vibrator_driver = {
+ .probe = gpio_vibrator_probe,
+ .driver = {
+ .name = "gpio-vibrator",
+ .pm = &gpio_vibrator_pm_ops,
+ .of_match_table = of_match_ptr(gpio_vibra_dt_match_table),
+ },
+};
+module_platform_driver(gpio_vibrator_driver);
+
+MODULE_AUTHOR("Luca Weiss <luca@z3ntu.xy>");
+MODULE_DESCRIPTION("GPIO vibrator driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpio-vibrator");
--
2.21.0
^ permalink raw reply related
* [PATCH v5 3/3] ARM: dts: msm8974-FP2: Add vibration motor
From: Luca Weiss @ 2019-04-26 19:47 UTC (permalink / raw)
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT KEYBOARD, MOUSE, JOYSTICK , TOUCHSCREEN...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Luca Weiss
In-Reply-To: <20190426194747.22256-1-luca@z3ntu.xyz>
Add a node describing the vibration motor on the Fairphone 2.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
index 643c57f84818..bf402ae39226 100644
--- a/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
@@ -50,6 +50,12 @@
};
};
+ vibrator {
+ compatible = "gpio-vibrator";
+ enable-gpios = <&msmgpio 86 GPIO_ACTIVE_HIGH>;
+ vcc-supply = <&pm8941_l18>;
+ };
+
smd {
rpm {
rpm_requests {
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] input: keyboard: gpio_keys_polled: use gpio lookup table
From: Sven Van Asbroeck @ 2019-04-26 20:16 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Linux Kernel Mailing List, Dmitry Torokhov, linux-input
In-Reply-To: <1556305282-24148-3-git-send-email-info@metux.net>
On Fri, Apr 26, 2019 at 3:03 PM Enrico Weigelt, metux IT consult
<info@metux.net> wrote:
>
> +static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
> + struct device *dev,
> + int idx,
> + const char *desc)
> +{
> + struct gpio_desc *gpiod;
> + struct fwnode_handle *child;
> + int x;
> +
> + /* get the idx'th child node */
> + child = device_get_next_child_node(dev, NULL);
> + while (child && x) {
> + child = device_get_next_child_node(dev, child);
> + x--;
> + }
x is uninitialized here.
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: input: add Elan 400 combo keyboard/touchpad over i2c
From: Rob Herring @ 2019-04-26 22:49 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jeffrey Hugo, mark.rutland, Lee Jones, bjorn.andersson,
Dmitry Torokhov, agross, David Brown, Jiri Kosina,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <CAO-hwJJ_BRRHL44yaZ=d_K-9iq1cyONn0rR+VW3ukW1M2Ma0ug@mail.gmail.com>
On Thu, Apr 18, 2019 at 11:35:42AM +0200, Benjamin Tissoires wrote:
> On Mon, Apr 15, 2019 at 6:11 PM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> >
> > The Elan 400 combo keyboard/touchpad over i2c device is a distinct device
> > from the Elan 400 standalone touchpad device. The combo device has been
> > found in the Lenovo Miix 630 and HP Envy x2 laptops.
> >
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > ---
>
> With my comments in 2/3, I wonder if you need this patch at all then.
I don't really follow the discussion in 2/3, but you should still have
specific compatibles even if right now you don't need them.
>
> Cheers,
> Benjamin
>
> > .../devicetree/bindings/input/elan,combo400-i2c.txt | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > new file mode 100644
> > index 000000000000..fb700a29148d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > @@ -0,0 +1,11 @@
> > +Elantech 0400 I2C combination Keyboard/Touchpad
> > +
> > +This binding describes an Elan device with pid 0x0400, that is a combination
> > +keyboard + touchpad device. This binding does not cover an Elan device with
> > +pid 0x0400 that is solely a standalone touchpad device.
> > +
> > +Required properties:
> > +- compatible: should be "elan,combo400-i2c"
> > +
> > +This binding is compatible with the HID over I2C binding, which is specified
> > +in hid-over-i2c.txt in this directory.
Separate is fine, but we've been adding compatibles to hid-over-i2c.txt.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] HID: input: add mapping for KEY_KBD_LAYOUT_NEXT
From: Dmitry Torokhov @ 2019-04-26 23:33 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, gwink
In-Reply-To: <CAO-hwJ+=n0Nh7XbcWRLeO5ay43YVwWK6vmMB=A5H23JKCWCUtg@mail.gmail.com>
On Fri, Apr 26, 2019 at 08:38:29AM +0200, Benjamin Tissoires wrote:
> On Thu, Apr 25, 2019 at 6:38 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > HUTRR56 defined a new usage code on consumer page to cycle through
> > set of keyboard layouts, let's add this mapping.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
>
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> I don't think this will collide with the HID tree, so IMO, you can
> take this through yours if you want.
OK, I will do that, thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: pm8xxx-vibrator: fix a potential NULL pointer dereference
From: Dmitry Torokhov @ 2019-04-27 0:27 UTC (permalink / raw)
To: Kangjie Lu; +Cc: pakki001, linux-input, linux-kernel
In-Reply-To: <20190309053922.22212-1-kjlu@umn.edu>
Hi Kangjie,
On Fri, Mar 08, 2019 at 11:39:21PM -0600, Kangjie Lu wrote:
> In case of_device_get_match_data fails to find the matched data,
> returns -ENODEV
How can this happen? We will not match again the device if compatible is
not present in the table.
If this happens I'd rather we crash and burn instead of silently
ignoring the failure.
Thanks.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> ---
> drivers/input/misc/pm8xxx-vibrator.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> index 7dd1c1fbe42a..740e59c11808 100644
> --- a/drivers/input/misc/pm8xxx-vibrator.c
> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> @@ -196,6 +196,8 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
> vib->vib_input_dev = input_dev;
>
> regs = of_device_get_match_data(&pdev->dev);
> + if (unlikely(!regs))
> + return -ENODEV;
>
> /* operate in manual mode */
> error = regmap_read(vib->regmap, regs->drv_addr, &val);
> --
> 2.17.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: Add Lenovo Miix 630
From: Bjorn Andersson @ 2019-04-27 4:42 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: robh+dt, mark.rutland, agross, david.brown, lee.jones,
dmitry.torokhov, jikos, benjamin.tissoires, linux-input,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20190415161115.16466-1-jeffrey.l.hugo@gmail.com>
On Mon 15 Apr 09:11 PDT 2019, Jeffrey Hugo wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
[..]
> + thermal-zones {
> + battery-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = <&tsens0 0>;
I guess you inherited the battery and skin thermal nodes from my MTP
dts. Unfortunately after talking to Amit I think I got these wrong, and
they should be &pmi8998_adc 0 and 5 instead.
Can you confirm this?
> +
> + trips {
> + battery_crit: trip0 {
> + temperature = <60000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
Regards,
Bjorn
^ permalink raw reply
* [git pull] Input updates for v5.1-rc6
From: Dmitry Torokhov @ 2019-04-27 22:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. Just a couple of fixups for
Synaptics RMI4 driver and allowing snvs_pwrkey to be selected on more
boards.
Changelog:
---------
Jacky Bai (1):
Input: snvs_pwrkey - make it depend on ARCH_MXC
Lucas Stach (1):
Input: synaptics-rmi4 - write config register values to the right offset
Pan Bian (1):
Input: synaptics-rmi4 - fix possible double free
Diffstat:
--------
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/rmi4/rmi_driver.c | 6 +-----
drivers/input/rmi4/rmi_f11.c | 2 +-
3 files changed, 3 insertions(+), 7 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH] input: imx6ul_tsc: use devm_platform_ioremap_resource() to simplify code
From: Anson Huang @ 2019-04-28 6:30 UTC (permalink / raw)
To: Mukesh Ojha, dmitry.torokhov@gmail.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-input@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <d3b8cf17-36bb-d79d-7d60-76ae2416075d@codeaurora.org>
Ping...
> -----Original Message-----
> From: Mukesh Ojha [mailto:mojha@codeaurora.org]
> Sent: Monday, April 1, 2019 4:02 PM
> To: Anson Huang <anson.huang@nxp.com>; dmitry.torokhov@gmail.com;
> shawnguo@kernel.org; s.hauer@pengutronix.de; kernel@pengutronix.de;
> festevam@gmail.com; linux-input@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH] input: imx6ul_tsc: use
> devm_platform_ioremap_resource() to simplify code
>
>
> On 4/1/2019 10:49 AM, Anson Huang wrote:
> > Use the new helper devm_platform_ioremap_resource() which wraps the
> > platform_get_resource() and devm_ioremap_resource() together, to
> > simplify the code.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
>
> Cheers,
> -Mukesh
>
> > ---
> > drivers/input/touchscreen/imx6ul_tsc.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/imx6ul_tsc.c
> > b/drivers/input/touchscreen/imx6ul_tsc.c
> > index c10fc59..e04eecd 100644
> > --- a/drivers/input/touchscreen/imx6ul_tsc.c
> > +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> > @@ -364,8 +364,6 @@ static int imx6ul_tsc_probe(struct platform_device
> *pdev)
> > struct device_node *np = pdev->dev.of_node;
> > struct imx6ul_tsc *tsc;
> > struct input_dev *input_dev;
> > - struct resource *tsc_mem;
> > - struct resource *adc_mem;
> > int err;
> > int tsc_irq;
> > int adc_irq;
> > @@ -403,16 +401,14 @@ static int imx6ul_tsc_probe(struct
> platform_device *pdev)
> > return err;
> > }
> >
> > - tsc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - tsc->tsc_regs = devm_ioremap_resource(&pdev->dev, tsc_mem);
> > + tsc->tsc_regs = devm_platform_ioremap_resource(pdev, 0);
> > if (IS_ERR(tsc->tsc_regs)) {
> > err = PTR_ERR(tsc->tsc_regs);
> > dev_err(&pdev->dev, "failed to remap tsc memory: %d\n",
> err);
> > return err;
> > }
> >
> > - adc_mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > - tsc->adc_regs = devm_ioremap_resource(&pdev->dev, adc_mem);
> > + tsc->adc_regs = devm_platform_ioremap_resource(pdev, 1);
> > if (IS_ERR(tsc->adc_regs)) {
> > err = PTR_ERR(tsc->adc_regs);
> > dev_err(&pdev->dev, "failed to remap adc memory: %d\n",
> err);
^ permalink raw reply
* Re: [git pull] Input updates for v5.1-rc6
From: pr-tracker-bot @ 2019-04-28 18:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <20190427223854.GA97206@dtor-ws>
The pull request you sent on Sat, 27 Apr 2019 15:38:54 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25cce03b1d06e4b742f6dafdda2f4d80c13bdc18
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Rafael J. Wysocki @ 2019-04-29 7:04 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Benjamin Tissoires, Dmitry Torokhov, Linux PM, Linux PCI,
Linux Kernel Mailing List, linux-input
In-Reply-To: <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com>
On Fri, Apr 26, 2019 at 2:14 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/22/19 4:08 PM, Bjorn Helgaas wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203297
> >
> > Regression, suspected but as yet unconfirmed cause:
> >
> > c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> >
> > backported to 4.20 stable as 39e1be324c2f.
> >
> With help of Keijo it was confirmed above patch broke the Synaptics
> touchpad. Not bisected but touchpad works again by forcing the i2c-i801
> SMBus controller always on:
> "echo on >/sys/bus/pci/devices/0000\:00\:1f.3/power/control"
>
> Above patch is a generalized fix that fixed the runtime PM regression on
> i2c-i801 and re-allow the controller go to runtime suspend when idle. So
> most probably Synaptics touchpad was broken by i2c-i801 runtime PM also
> before but got unnoticed. Which is easy since on many platforms SMBus
> controller doesn't necessarily have the PCI PM capabilities.
>
> I would like to ask help from input subsystem experts what kind of SMBus
> power state dependency Synaptics RMI4 SMBus devices have since it cease
> to work if SMBus controllers idles between transfers and how this is
> best to fix?
>
> Instead of revert I think we'd need to have some method to force SMBus
> controller on whenever the touchpad is active, like when there is a
> userspace listening.
>
> I'm not expert in this area so as quick proof of concept I had a
> following hack which forces the I2C/SMBus adapter, and eventually the
> parent PCI device of it on when the RMI4 SMBus device is probed and let
> the SMBus controller to idle when removed.
>
> According to Keijo it fixes the issue but I like to hear input experts
> for better place to put these.
>
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index b6ccf39c6a7b..2b11d69be313 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -16,6 +16,7 @@
> #include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> #include <linux/rmi.h>
> #include <linux/slab.h>
> #include "rmi_driver.h"
> @@ -332,6 +333,9 @@ static int rmi_smb_probe(struct i2c_client *client,
>
> dev_info(&client->dev, "registering SMbus-connected sensor\n");
>
> + /* Force SMBus adapter on while RMI4 device is connected */
> + pm_runtime_get(&client->adapter->dev);
That should be pm_runtime_get_sync() IMO.
Otherwise, the rmi_register_transport_device() may be called before
completing the PM transition.
> +
> error = rmi_register_transport_device(&rmi_smb->xport);
> if (error) {
> dev_err(&client->dev, "failed to register sensor: %d\n", error);
> @@ -346,6 +350,7 @@ static int rmi_smb_remove(struct i2c_client *client)
> struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
>
> rmi_unregister_transport_device(&rmi_smb->xport);
> + pm_runtime_put(&client->adapter->dev);
>
> return 0;
> }
>
> --
> Jarkko
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Benjamin Tissoires @ 2019-04-29 7:45 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER
In-Reply-To: <3a1139ef-10ed-6923-73c5-30fbf0c065c3@linux.intel.com>
On Fri, Apr 26, 2019 at 2:14 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/22/19 4:08 PM, Bjorn Helgaas wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203297
> >
> > Regression, suspected but as yet unconfirmed cause:
> >
> > c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> >
> > backported to 4.20 stable as 39e1be324c2f.
> >
> With help of Keijo it was confirmed above patch broke the Synaptics
> touchpad. Not bisected but touchpad works again by forcing the i2c-i801
> SMBus controller always on:
> "echo on >/sys/bus/pci/devices/0000\:00\:1f.3/power/control"
>
> Above patch is a generalized fix that fixed the runtime PM regression on
> i2c-i801 and re-allow the controller go to runtime suspend when idle. So
> most probably Synaptics touchpad was broken by i2c-i801 runtime PM also
> before but got unnoticed. Which is easy since on many platforms SMBus
> controller doesn't necessarily have the PCI PM capabilities.
>
> I would like to ask help from input subsystem experts what kind of SMBus
> power state dependency Synaptics RMI4 SMBus devices have since it cease
> to work if SMBus controllers idles between transfers and how this is
> best to fix?
Hmm, I am not sure there is such an existing architecture you could
use in a simple patch.
rmi-driver.c does indeed create an input device we could use to toggle
on/off the PM state, but those callbacks are not wired to the
transport driver (rmi_smbus.c), so it would required a little bit of
extra work. And then, there are other RMI4 functions (firmware
upgrade) that would not be happy if PM is in suspend while there is no
open input node.
So I think this "hack" (with Mika's comments addressed) should go in
until someone starts propagating the PM states correctly.
Cheers,
Benjamin
>
> Instead of revert I think we'd need to have some method to force SMBus
> controller on whenever the touchpad is active, like when there is a
> userspace listening.
>
> I'm not expert in this area so as quick proof of concept I had a
> following hack which forces the I2C/SMBus adapter, and eventually the
> parent PCI device of it on when the RMI4 SMBus device is probed and let
> the SMBus controller to idle when removed.
>
> According to Keijo it fixes the issue but I like to hear input experts
> for better place to put these.
>
> diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
> index b6ccf39c6a7b..2b11d69be313 100644
> --- a/drivers/input/rmi4/rmi_smbus.c
> +++ b/drivers/input/rmi4/rmi_smbus.c
> @@ -16,6 +16,7 @@
> #include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> #include <linux/rmi.h>
> #include <linux/slab.h>
> #include "rmi_driver.h"
> @@ -332,6 +333,9 @@ static int rmi_smb_probe(struct i2c_client *client,
>
> dev_info(&client->dev, "registering SMbus-connected sensor\n");
>
> + /* Force SMBus adapter on while RMI4 device is connected */
> + pm_runtime_get(&client->adapter->dev);
> +
> error = rmi_register_transport_device(&rmi_smb->xport);
> if (error) {
> dev_err(&client->dev, "failed to register sensor: %d\n", error);
> @@ -346,6 +350,7 @@ static int rmi_smb_remove(struct i2c_client *client)
> struct rmi_smb_xport *rmi_smb = i2c_get_clientdata(client);
>
> rmi_unregister_transport_device(&rmi_smb->xport);
> + pm_runtime_put(&client->adapter->dev);
>
> return 0;
> }
>
> --
> Jarkko
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Jarkko Nikula @ 2019-04-29 8:36 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER
In-Reply-To: <CAO-hwJKvXO6L7m0g1D6wycFP=Wu_qLDyLXTtmm0TkpxT5Z8ygw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]
On 4/29/19 10:45 AM, Benjamin Tissoires wrote:
>> I would like to ask help from input subsystem experts what kind of SMBus
>> power state dependency Synaptics RMI4 SMBus devices have since it cease
>> to work if SMBus controllers idles between transfers and how this is
>> best to fix?
>
> Hmm, I am not sure there is such an existing architecture you could
> use in a simple patch.
>
> rmi-driver.c does indeed create an input device we could use to toggle
> on/off the PM state, but those callbacks are not wired to the
> transport driver (rmi_smbus.c), so it would required a little bit of
> extra work. And then, there are other RMI4 functions (firmware
> upgrade) that would not be happy if PM is in suspend while there is no
> open input node.
>
I see.
I got another thought about this. I noticed these input drivers need
SMBus Host Notify, maybe that explain the PM dependency? If that's the
only dependency then we could prevent the controller suspend if there is
a client needing host notify mechanism. IMHO that's less hack than the
patch to rmi_smbus.c.
Keijo: care to test does this idea would fix the issue (without the
previous patch)? I also attached the diff.
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..d54eafad7727 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Adapter should not suspend for Host Notify */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
> So I think this "hack" (with Mika's comments addressed) should go in
> until someone starts propagating the PM states correctly.
>
I guess you mean the Rafael's pm_runtime_get_sync() comment?
--
Jarkko
[-- Attachment #2: i2c-core-host-notify-pm.diff --]
[-- Type: text/x-patch, Size: 830 bytes --]
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..d54eafad7727 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Adapter should not suspend for Host Notify */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
^ permalink raw reply related
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Benjamin Tissoires @ 2019-04-29 8:53 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Jean Delvare, Rafael J. Wysocki,
Dmitry Torokhov, linux-pm, linux-pci, lkml,
open list:HID CORE LAYER, Wolfram Sang
In-Reply-To: <e96a7220-974f-1df6-70ee-695ee815057f@linux.intel.com>
On Mon, Apr 29, 2019 at 10:38 AM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> On 4/29/19 10:45 AM, Benjamin Tissoires wrote:
> >> I would like to ask help from input subsystem experts what kind of SMBus
> >> power state dependency Synaptics RMI4 SMBus devices have since it cease
> >> to work if SMBus controllers idles between transfers and how this is
> >> best to fix?
> >
> > Hmm, I am not sure there is such an existing architecture you could
> > use in a simple patch.
> >
> > rmi-driver.c does indeed create an input device we could use to toggle
> > on/off the PM state, but those callbacks are not wired to the
> > transport driver (rmi_smbus.c), so it would required a little bit of
> > extra work. And then, there are other RMI4 functions (firmware
> > upgrade) that would not be happy if PM is in suspend while there is no
> > open input node.
> >
> I see.
>
> I got another thought about this. I noticed these input drivers need
> SMBus Host Notify, maybe that explain the PM dependency? If that's the
> only dependency then we could prevent the controller suspend if there is
> a client needing host notify mechanism. IMHO that's less hack than the
> patch to rmi_smbus.c.
So currently, AFAIK, only Synaptics (rmi4) and Elantech are using
SMBus Host Notify.
So this patch would prevent the same bugs for those 2 vendors, which is good.
It took me some time to understand why this would be less than a hack.
And indeed, given that Host Notify relies on the I2C connection to be
ready for the IRQ, we can not put the controller in suspend like we do
for others where the IRQ controller is still ready.
So yes, that could work from me. Not sure what Wolfram and Jean would
say though.
>
> Keijo: care to test does this idea would fix the issue (without the
> previous patch)? I also attached the diff.
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..d54eafad7727 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
> if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> dev_dbg(dev, "Using Host Notify IRQ\n");
> + /* Adapter should not suspend for Host Notify */
> + pm_runtime_get_sync(&client->adapter->dev);
> irq = i2c_smbus_host_notify_to_irq(client);
> } else if (dev->of_node) {
> irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
> device_init_wakeup(&client->dev, false);
>
> client->irq = client->init_irq;
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> + pm_runtime_put(&client->adapter->dev);
>
> return status;
> }
>
> > So I think this "hack" (with Mika's comments addressed) should go in
> > until someone starts propagating the PM states correctly.
> >
> I guess you mean the Rafael's pm_runtime_get_sync() comment?
Oops, yes, that one, sorry :)
Cheers,
Benjamin
^ permalink raw reply
* Re: [Bug 203297] Synaptics touchpad TM-3127 functionality broken by PCI runtime power management patch on 4.20.2
From: Jean Delvare @ 2019-04-29 9:45 UTC (permalink / raw)
To: Benjamin Tissoires, Jarkko Nikula
Cc: Bjorn Helgaas, Keijo Vaara, Rafael J. Wysocki, Dmitry Torokhov,
linux-pm, linux-pci, lkml, linux-input, Wolfram Sang
In-Reply-To: <CAO-hwJLCPd-KfoK7OnSpEWG4B5cYfsH3J0tYAxJeVMqHyJEN1A@mail.gmail.com>
On Mon, 2019-04-29 at 10:53 +0200, Benjamin Tissoires wrote:
> On Mon, Apr 29, 2019 at 10:38 AM Jarkko Nikula
> <jarkko.nikula@linux.intel.com> wrote:
> > I got another thought about this. I noticed these input drivers need
> > SMBus Host Notify, maybe that explain the PM dependency? If that's the
> > only dependency then we could prevent the controller suspend if there is
> > a client needing host notify mechanism. IMHO that's less hack than the
> > patch to rmi_smbus.c.
>
> So currently, AFAIK, only Synaptics (rmi4) and Elantech are using
> SMBus Host Notify.
> So this patch would prevent the same bugs for those 2 vendors, which is good.
>
> It took me some time to understand why this would be less than a hack.
> And indeed, given that Host Notify relies on the I2C connection to be
> ready for the IRQ, we can not put the controller in suspend like we do
> for others where the IRQ controller is still ready.
>
> So yes, that could work from me. Not sure what Wolfram and Jean would
> say though.
I would say OK with me, this looks like the cleanest solution to me, so
if testing is positive, let's go with it.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: input: add Elan 400 combo keyboard/touchpad over i2c
From: Jeffrey Hugo @ 2019-04-29 15:15 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Tissoires, Mark Rutland, Lee Jones, Bjorn Andersson,
Dmitry Torokhov, Andy Gross, David Brown, Jiri Kosina,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <20190426224908.GA30389@bogus>
On Fri, Apr 26, 2019 at 4:49 PM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Apr 18, 2019 at 11:35:42AM +0200, Benjamin Tissoires wrote:
> > On Mon, Apr 15, 2019 at 6:11 PM Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
> > >
> > > The Elan 400 combo keyboard/touchpad over i2c device is a distinct device
> > > from the Elan 400 standalone touchpad device. The combo device has been
> > > found in the Lenovo Miix 630 and HP Envy x2 laptops.
> > >
> > > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > > ---
> >
> > With my comments in 2/3, I wonder if you need this patch at all then.
>
> I don't really follow the discussion in 2/3, but you should still have
> specific compatibles even if right now you don't need them.
>
> >
> > Cheers,
> > Benjamin
> >
> > > .../devicetree/bindings/input/elan,combo400-i2c.txt | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > > new file mode 100644
> > > index 000000000000..fb700a29148d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/elan,combo400-i2c.txt
> > > @@ -0,0 +1,11 @@
> > > +Elantech 0400 I2C combination Keyboard/Touchpad
> > > +
> > > +This binding describes an Elan device with pid 0x0400, that is a combination
> > > +keyboard + touchpad device. This binding does not cover an Elan device with
> > > +pid 0x0400 that is solely a standalone touchpad device.
> > > +
> > > +Required properties:
> > > +- compatible: should be "elan,combo400-i2c"
> > > +
> > > +This binding is compatible with the HID over I2C binding, which is specified
> > > +in hid-over-i2c.txt in this directory.
>
> Separate is fine, but we've been adding compatibles to hid-over-i2c.txt.
Are you just referring to "wacom,w9013" ?
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: Add Lenovo Miix 630
From: Jeffrey Hugo @ 2019-04-29 15:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Mark Rutland, Andy Gross, David Brown, Lee Jones,
Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires,
open list:HID CORE LAYER, devicetree, linux-arm-msm, lkml
In-Reply-To: <20190427044245.GD3137@builder>
On Fri, Apr 26, 2019 at 10:42 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Mon 15 Apr 09:11 PDT 2019, Jeffrey Hugo wrote:
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> [..]
> > + thermal-zones {
> > + battery-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = <&tsens0 0>;
>
> I guess you inherited the battery and skin thermal nodes from my MTP
> dts. Unfortunately after talking to Amit I think I got these wrong, and
> they should be &pmi8998_adc 0 and 5 instead.
>
> Can you confirm this?
Yeah, I pulled thermal from the MTP. Someone pointed this out on the
v4 series. I haven't circled back to it yet.
>
> > +
> > + trips {
> > + battery_crit: trip0 {
> > + temperature = <60000>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH 4/4] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Frank Rowand @ 2019-04-29 19:44 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: dmitry.torokhov, linux-input
In-Reply-To: <1555444645-15156-5-git-send-email-info@metux.net>
On 4/16/19 12:57 PM, Enrico Weigelt, metux IT consult wrote:
> we don't need to build in oftree probing stuff when oftree isn't
> enabled at all.
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ---
> drivers/input/keyboard/gpio_keys_polled.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
> index 3f773b2..fbccb89 100644
> --- a/drivers/input/keyboard/gpio_keys_polled.c
> +++ b/drivers/input/keyboard/gpio_keys_polled.c
> @@ -147,6 +147,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
> static struct gpio_keys_platform_data *
> gpio_keys_polled_get_devtree_pdata(struct device *dev)
> {
> +#ifdef CONFIG_OF
> struct gpio_keys_platform_data *pdata;
> struct gpio_keys_button *button;
> struct fwnode_handle *child;
> @@ -200,6 +201,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
> }
>
> return pdata;
> +#else /* CONFIG_OF */
> + return ERR_PTR(-ENOENT);
> +#endif /* CONFIG_OF */
> }
>
> static void gpio_keys_polled_set_abs_params(struct input_dev *input,
> @@ -226,7 +230,7 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
> { .compatible = "gpio-keys-polled", },
> { },
> };
> -MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
> +MODULE_DEVICE_TABLE_OF(gpio_keys_polled_of_match);
Not needed, when you use of_match_ptr() -- see below.
>
> static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
> struct device *dev,
> @@ -452,7 +456,9 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
> .probe = gpio_keys_polled_probe,
> .driver = {
> .name = DRV_NAME,
> +#ifdef CONFIG_OF
> .of_match_table = gpio_keys_polled_of_match,
> +#endif /* CONFIG_OF */
No need for the #ifdef, use of_match_ptr():
.of_match_table = of_match_ptr(gpio_keys_polled_of_match),
> },
> };
> module_platform_driver(gpio_keys_polled_driver);
>
^ permalink raw reply
* Re: [PATCH 1/4] mod_devicetable: helper macro for declaring oftree module device table
From: Frank Rowand @ 2019-04-29 19:48 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, Dmitry Torokhov,
Enrico Weigelt, metux IT consult
Cc: linux-kernel, linux-input
In-Reply-To: <fc747fb3-e670-79a2-f4bc-b989dee469fa@metux.net>
On 4/24/19 3:48 AM, Enrico Weigelt, metux IT consult wrote:
> On 19.04.19 09:40, Dmitry Torokhov wrote:
>> Hi Enrico,
>>
>> On Tue, Apr 16, 2019 at 09:57:22PM +0200, Enrico Weigelt, metux IT consult wrote:
>>> Little helper macro that declares an oftree module device table,
>>> if CONFIG_OF is enabled. Otherwise it's just noop.
>>>
>>> This is also helpful if some drivers can be built w/ or w/o
>>> oftree support.
>>
>> This should go to OF folks, please.
>
> hmm, they should be CCed, if my script works right.
> This one is only needed for the 4th patch (skip oftree...).
Your script did not work (BTDT). I just happened to notice this on lkml.
-Frank
>
>
> --mtx
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox