* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: simon @ 2014-05-21 22:42 UTC (permalink / raw)
To: Roland Bosa
Cc: Elias Vanderstuyft, "Michal Malý",
Dmitry Torokhov, HID CORE LAYER, linux-kernel@vger.kernel.org,
Jiri Kosina, Anssi Hannula, Simon Wood
In-Reply-To: <537D28E3.3000401@logitech.com>
>> But 2 Spring effects with different offsets and non-zero effective
>> force can't be combined into a single slot (without streaming them
>> with Constant force), right?
>
> Yes - you cannot *download* two springs to a single slot. You need to
> choose (allocate) one of them. The winner gets the slot. The losers go
> somewhere else (they might get discarded, they might get simulated).
In reverse engineering, I thought that a single slot could hold two
rotational angles/points (at which a springs would start) and that that
the direction could be set so that both acting in the same direction with
different forces.
--
Byte 2 - 0x_1
Byte 3 - Clockwise angle, nominally on left (0x00..0xFF - 0x00 is
fully left)
Byte 4 - Anti-Clockwise angle, nominally on right(0x00..0xFF)
Byte 5 - L/R Proportion force, upper nibble clockwise + lower nibble
anti-clockwise (each 0x0..0xF)
Byte 6 - Reverse Direction; upper nibble clockwise + lower nibble
anti-clockwise (each 0x0..0x1)
Byte 7 - Force (0x00..0xFF)
--
Ie. turning from fully left (00) with no force, you could hit a 'weak'
spring (at 40) and then a 'stronger' spring (at 80).
So to some degree you /can/ merge springs... but I'm not saying that you
should :-).
Simon
^ permalink raw reply
* Re: [PATCHv4 4/4] DTS: ARM: OMAP3-N900: Add tsc2005 support
From: Tony Lindgren @ 2014-05-21 22:19 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1400693774-21306-5-git-send-email-sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
* Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [140521 10:38]:
> This adds support for the tsc2005 touchscreen
> to the Nokia N900 DTS file.
>
> Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Dmitry, if no other comments, feel free to pick this one too.
This does not seem to conflict with anything I have queued:
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm/boot/dts/omap3-n900.dts | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 1a57b61..cb8ed2d5 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -580,9 +580,24 @@
> * Also... order in the device tree actually matters here.
> */
> tsc2005@0 {
> - compatible = "tsc2005";
> + compatible = "ti,tsc2005";
> spi-max-frequency = <6000000>;
> reg = <0>;
> +
> + vio-supply = <&vio>;
> +
> + reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
> + interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
> +
> + touchscreen-fuzz-x = <4>;
> + touchscreen-fuzz-y = <7>;
> + touchscreen-fuzz-pressure = <2>;
> + touchscreen-max-x = <4096>;
> + touchscreen-max-y = <4096>;
> + touchscreen-max-pressure = <2048>;
> +
> + ti,x-plate-ohms = <280>;
> + ti,esd-recovery-timeout-ms = <8000>;
> };
>
> acx565akm@2 {
> --
> 2.0.0.rc2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv4 4/4] DTS: ARM: OMAP3-N900: Add tsc2005 support
From: Sebastian Reichel @ 2014-05-21 17:36 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Tony Lindgren, Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-omap, linux-kernel, Sebastian Reichel
In-Reply-To: <1400693774-21306-1-git-send-email-sre@kernel.org>
This adds support for the tsc2005 touchscreen
to the Nokia N900 DTS file.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
arch/arm/boot/dts/omap3-n900.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1a57b61..cb8ed2d5 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -580,9 +580,24 @@
* Also... order in the device tree actually matters here.
*/
tsc2005@0 {
- compatible = "tsc2005";
+ compatible = "ti,tsc2005";
spi-max-frequency = <6000000>;
reg = <0>;
+
+ vio-supply = <&vio>;
+
+ reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
+ interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
+
+ touchscreen-fuzz-x = <4>;
+ touchscreen-fuzz-y = <7>;
+ touchscreen-fuzz-pressure = <2>;
+ touchscreen-max-x = <4096>;
+ touchscreen-max-y = <4096>;
+ touchscreen-max-pressure = <2048>;
+
+ ti,x-plate-ohms = <280>;
+ ti,esd-recovery-timeout-ms = <8000>;
};
acx565akm@2 {
--
2.0.0.rc2
^ permalink raw reply related
* [PATCHv4 3/4] Documentation: dt: Document TSC2005 DT binding
From: Sebastian Reichel @ 2014-05-21 17:36 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Tony Lindgren, Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-omap, linux-kernel, Sebastian Reichel
In-Reply-To: <1400693774-21306-1-git-send-email-sre@kernel.org>
Add devicetree binding documentation for TSC2005 touchscreen.
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
.../bindings/input/touchscreen/tsc2005.txt | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 0000000..4b641c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,42 @@
+* Texas Instruments tsc2005 touchscreen controller
+
+Required properties:
+ - compatible : "ti,tsc2005"
+ - reg : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts : IRQ specifier
+ - reset-gpios : GPIO specifier
+ - vio-supply : Regulator specifier
+
+Optional properties:
+ - ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
+ in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
+ the configured time (in milli seconds), the driver
+ will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+&mcspi1 {
+ tsc2005@0 {
+ compatible = "ti,tsc2005";
+ spi-max-frequency = <6000000>;
+ reg = <0>;
+
+ vio-supply = <&vio>;
+
+ reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
+ interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
+
+ touchscreen-fuzz-x = <4>;
+ touchscreen-fuzz-y = <7>;
+ touchscreen-fuzz-pressure = <2>;
+ touchscreen-max-x = <4096>;
+ touchscreen-max-y = <4096>;
+ touchscreen-max-pressure = <2048>;
+
+ ti,x-plate-ohms = <280>;
+ ti,esd-recovery-timeout-ms = <8000>;
+ };
+}
--
2.0.0.rc2
^ permalink raw reply related
* [PATCHv4 2/4] Input: tsc2005: add DT support
From: Sebastian Reichel @ 2014-05-21 17:36 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Tony Lindgren, Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-omap, linux-kernel, Sebastian Reichel
In-Reply-To: <1400693774-21306-1-git-send-email-sre@kernel.org>
This adds DT support to the tsc2005 touchscreen
driver. It also adds regulator support to the
driver if booted via DT.
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
drivers/input/touchscreen/tsc2005.c | 122 ++++++++++++++++++++++++++++++------
1 file changed, 102 insertions(+), 20 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c
index 9daaddd..731f0fd 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -25,11 +25,15 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/input.h>
+#include <linux/input/touchscreen.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/pm.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/spi/spi.h>
#include <linux/spi/tsc2005.h>
+#include <linux/regulator/consumer.h>
/*
* The touchscreen interface operates as follows:
@@ -100,6 +104,11 @@
TSC2005_CFR2_AVG_7)
#define MAX_12BIT 0xfff
+#define TSC2005_DEF_X_FUZZ 4
+#define TSC2005_DEF_Y_FUZZ 8
+#define TSC2005_DEF_P_FUZZ 2
+#define TSC2005_DEF_RESISTOR 280
+
#define TSC2005_SPI_MAX_SPEED_HZ 10000000
#define TSC2005_PENUP_TIME_MS 40
@@ -143,6 +152,9 @@ struct tsc2005 {
bool pen_down;
+ struct regulator *vio;
+
+ int reset_gpio;
void (*set_reset)(bool enable);
};
@@ -337,6 +349,14 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
tsc2005_cmd(ts, TSC2005_CMD_STOP);
}
+static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
+{
+ if (ts->reset_gpio >= 0)
+ gpio_set_value(ts->reset_gpio, enable);
+ else if (ts->set_reset)
+ ts->set_reset(enable);
+}
+
/* must be called with ts->mutex held */
static void __tsc2005_disable(struct tsc2005 *ts)
{
@@ -355,7 +375,7 @@ static void __tsc2005_enable(struct tsc2005 *ts)
{
tsc2005_start_scan(ts);
- if (ts->esd_timeout && ts->set_reset) {
+ if (ts->esd_timeout && (ts->set_reset || ts->reset_gpio)) {
ts->last_valid_interrupt = jiffies;
schedule_delayed_work(&ts->esd_work,
round_jiffies_relative(
@@ -414,9 +434,9 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
}
/* hardware reset */
- ts->set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts->set_reset(true);
+ tsc2005_set_reset(ts, true);
if (!success)
goto out;
@@ -459,7 +479,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
umode_t mode = attr->mode;
if (attr == &dev_attr_selftest.attr) {
- if (!ts->set_reset)
+ if (!ts->set_reset && !ts->reset_gpio)
mode = 0;
}
@@ -509,9 +529,9 @@ static void tsc2005_esd_work(struct work_struct *work)
tsc2005_update_pen_state(ts, 0, 0, 0);
- ts->set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts->set_reset(true);
+ tsc2005_set_reset(ts, true);
enable_irq(ts->spi->irq);
tsc2005_start_scan(ts);
@@ -572,29 +592,47 @@ static void tsc2005_setup_spi_xfer(struct tsc2005 *ts)
static int tsc2005_probe(struct spi_device *spi)
{
const struct tsc2005_platform_data *pdata = dev_get_platdata(&spi->dev);
+ struct device_node *np = spi->dev.of_node;
+
struct tsc2005 *ts;
struct input_dev *input_dev;
- unsigned int max_x, max_y, max_p;
- unsigned int fudge_x, fudge_y, fudge_p;
+ unsigned int max_x = MAX_12BIT;
+ unsigned int max_y = MAX_12BIT;
+ unsigned int max_p = MAX_12BIT;
+ unsigned int fudge_x = TSC2005_DEF_X_FUZZ;
+ unsigned int fudge_y = TSC2005_DEF_Y_FUZZ;
+ unsigned int fudge_p = TSC2005_DEF_P_FUZZ;
+ unsigned int x_plate_ohm = TSC2005_DEF_RESISTOR;
+ unsigned int esd_timeout;
int error;
- if (!pdata) {
+ if (!np && !pdata) {
dev_err(&spi->dev, "no platform data\n");
return -ENODEV;
}
- fudge_x = pdata->ts_x_fudge ? : 4;
- fudge_y = pdata->ts_y_fudge ? : 8;
- fudge_p = pdata->ts_pressure_fudge ? : 2;
- max_x = pdata->ts_x_max ? : MAX_12BIT;
- max_y = pdata->ts_y_max ? : MAX_12BIT;
- max_p = pdata->ts_pressure_max ? : MAX_12BIT;
-
if (spi->irq <= 0) {
dev_err(&spi->dev, "no irq\n");
return -ENODEV;
}
+ if (pdata) {
+ fudge_x = pdata->ts_x_fudge;
+ fudge_y = pdata->ts_y_fudge;
+ fudge_p = pdata->ts_pressure_fudge;
+ max_x = pdata->ts_x_max;
+ max_y = pdata->ts_y_max;
+ max_p = pdata->ts_pressure_max;
+ x_plate_ohm = pdata->ts_x_plate_ohm;
+ esd_timeout = pdata->esd_timeout_ms;
+ } else {
+ x_plate_ohm = TSC2005_DEF_RESISTOR;
+ of_property_read_u32(np, "ti,x-plate-ohms", &x_plate_ohm);
+ esd_timeout = 0;
+ of_property_read_u32(np, "ti,esd-recovery-timeout-ms",
+ &esd_timeout);
+ }
+
spi->mode = SPI_MODE_0;
spi->bits_per_word = 8;
if (!spi->max_speed_hz)
@@ -612,9 +650,37 @@ static int tsc2005_probe(struct spi_device *spi)
ts->spi = spi;
ts->idev = input_dev;
- ts->x_plate_ohm = pdata->ts_x_plate_ohm ? : 280;
- ts->esd_timeout = pdata->esd_timeout_ms;
- ts->set_reset = pdata->set_reset;
+ ts->x_plate_ohm = x_plate_ohm;
+ ts->esd_timeout = esd_timeout;
+
+ if (np) {
+ ts->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
+ if (ts->reset_gpio == -EPROBE_DEFER)
+ return ts->reset_gpio;
+ if (ts->reset_gpio < 0) {
+ dev_err(&spi->dev, "error acquiring reset gpio: %d\n",
+ ts->reset_gpio);
+ return ts->reset_gpio;
+ }
+
+ error = devm_gpio_request_one(&spi->dev, ts->reset_gpio, 0,
+ "reset-gpios");
+ if (error) {
+ dev_err(&spi->dev, "error requesting reset gpio: %d\n",
+ error);
+ return error;
+ }
+
+ ts->vio = devm_regulator_get(&spi->dev, "vio");
+ if (IS_ERR(ts->vio)) {
+ error = PTR_ERR(ts->vio);
+ dev_err(&spi->dev, "vio regulator missing (%d)", error);
+ return error;
+ }
+ } else {
+ ts->reset_gpio = -1;
+ ts->set_reset = pdata->set_reset;
+ }
mutex_init(&ts->mutex);
@@ -639,6 +705,9 @@ static int tsc2005_probe(struct spi_device *spi)
input_set_abs_params(input_dev, ABS_Y, 0, max_y, fudge_y, 0);
input_set_abs_params(input_dev, ABS_PRESSURE, 0, max_p, fudge_p, 0);
+ if (np)
+ touchscreen_parse_of_params(input_dev);
+
input_dev->open = tsc2005_open;
input_dev->close = tsc2005_close;
@@ -656,12 +725,19 @@ static int tsc2005_probe(struct spi_device *spi)
return error;
}
+ /* enable regulator for DT */
+ if (ts->vio) {
+ error = regulator_enable(ts->vio);
+ if (error)
+ return error;
+ }
+
spi_set_drvdata(spi, ts);
error = sysfs_create_group(&spi->dev.kobj, &tsc2005_attr_group);
if (error) {
dev_err(&spi->dev,
"Failed to create sysfs attributes, err: %d\n", error);
- return error;
+ goto disable_regulator;
}
error = input_register_device(ts->idev);
@@ -676,6 +752,9 @@ static int tsc2005_probe(struct spi_device *spi)
err_remove_sysfs:
sysfs_remove_group(&spi->dev.kobj, &tsc2005_attr_group);
+disable_regulator:
+ if (ts->vio)
+ regulator_disable(ts->vio);
return error;
}
@@ -685,6 +764,9 @@ static int tsc2005_remove(struct spi_device *spi)
sysfs_remove_group(&ts->spi->dev.kobj, &tsc2005_attr_group);
+ if (ts->vio)
+ regulator_disable(ts->vio);
+
return 0;
}
--
2.0.0.rc2
^ permalink raw reply related
* [PATCHv4 1/4] Input: add common DT binding for touchscreens
From: Sebastian Reichel @ 2014-05-21 17:36 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Tony Lindgren, Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-omap, linux-kernel, Sebastian Reichel
In-Reply-To: <1400693774-21306-1-git-send-email-sre@kernel.org>
Add common DT binding documentation for touchscreen devices and
implement input_parse_touchscreen_of_params, which parses the common
properties and configures the input device accordingly.
The method currently does not interpret the axis inversion properties,
since there is no matching flag in the generic linux input device.
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
.../bindings/input/touchscreen/touchscreen.txt | 27 +++++++++++++
drivers/input/touchscreen/Kconfig | 4 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/of_touchscreen.c | 44 ++++++++++++++++++++++
include/linux/input/touchscreen.h | 22 +++++++++++
5 files changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
create mode 100644 drivers/input/touchscreen/of_touchscreen.c
create mode 100644 include/linux/input/touchscreen.h
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
new file mode 100644
index 0000000..d8e0616
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -0,0 +1,27 @@
+General Touchscreen Properties:
+
+Optional properties for Touchscreens:
+ - touchscreen-size-x : horizontal resolution of touchscreen
+ (in pixels)
+ - touchscreen-size-y : vertical resolution of touchscreen
+ (in pixels)
+ - touchscreen-max-pressure : maximum reported pressure (arbitrary range
+ dependent on the controller)
+ - touchscreen-fuzz-x : horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y : vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-pressure : pressure noise value of the absolute input
+ device (arbitrary range dependent on the
+ controller)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+
+Deprecated properties for Touchscreens:
+ - x-size : deprecated name for touchscreen-size-x
+ - y-size : deprecated name for touchscreen-size-y
+ - moving-threshold : deprecated name for a combination of
+ touchscreen-fuzz-x and touchscreen-fuzz-y
+ - contact-threshold : deprecated name for touchscreen-fuzz-pressure
+ - x-invert : deprecated name for touchscreen-inverted-x
+ - y-invert : deprecated name for touchscreen-inverted-y
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 68edc9d..b2a31ca 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -11,6 +11,10 @@ menuconfig INPUT_TOUCHSCREEN
if INPUT_TOUCHSCREEN
+config OF_TOUCHSCREEN
+ def_tristate INPUT
+ depends on INPUT && OF
+
config TOUCHSCREEN_88PM860X
tristate "Marvell 88PM860x touchscreen"
depends on MFD_88PM860X
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 4bc954b..efa08ae 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -6,6 +6,7 @@
wm97xx-ts-y := wm97xx-core.o
+obj-$(CONFIG_OF_TOUCHSCREEN) += of_touchscreen.o
obj-$(CONFIG_TOUCHSCREEN_88PM860X) += 88pm860x-ts.o
obj-$(CONFIG_TOUCHSCREEN_AD7877) += ad7877.o
obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
diff --git a/drivers/input/touchscreen/of_touchscreen.c b/drivers/input/touchscreen/of_touchscreen.c
new file mode 100644
index 0000000..0431b28
--- /dev/null
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -0,0 +1,44 @@
+/*
+ * Generic DT helper functions for touchscreen devices
+ *
+ * Copyright (c) 2014 Sebastian Reichel <sre@kernel.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/input.h>
+
+/**
+ * touchscreen_parse_of_params - parse common touchscreen DT properties
+ * @dev: device that should be parsed
+ *
+ * This function parses common DT properties for touchscreens and setups the
+ * input device accordingly. The function keeps previously setuped default
+ * values if no value is specified via DT.
+ */
+void touchscreen_parse_of_params(struct input_dev *dev)
+{
+ struct device_node *np = dev->dev.parent->of_node;
+ struct input_absinfo *absinfo;
+
+ input_alloc_absinfo(dev);
+ if (!dev->absinfo)
+ return;
+
+ absinfo = &dev->absinfo[ABS_X];
+ of_property_read_u32(np, "touchscreen-size-x", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-x", &absinfo->fuzz);
+
+ absinfo = &dev->absinfo[ABS_Y];
+ of_property_read_u32(np, "touchscreen-size-y", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-y", &absinfo->fuzz);
+
+ absinfo = &dev->absinfo[ABS_PRESSURE];
+ of_property_read_u32(np, "touchscreen-max-pressure", &absinfo->maximum);
+ of_property_read_u32(np, "touchscreen-fuzz-pressure", &absinfo->fuzz);
+}
+EXPORT_SYMBOL(touchscreen_parse_of_params);
diff --git a/include/linux/input/touchscreen.h b/include/linux/input/touchscreen.h
new file mode 100644
index 0000000..67df6f2
--- /dev/null
+++ b/include/linux/input/touchscreen.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (c) 2014 Sebastian Reichel <sre@kernel.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#ifndef _TOUCHSCREEN_H
+#define _TOUCHSCREEN_H
+
+#include <linux/input.h>
+
+#if defined(CONFIG_OF)
+void touchscreen_parse_of_params(struct input_dev *dev);
+#else
+static inline void touchscreen_parse_of_params(struct input_dev *dev) {
+ return;
+}
+#endif
+
+#endif
--
2.0.0.rc2
^ permalink raw reply related
* [PATCHv4 0/4] tsc2005 DT binding
From: Sebastian Reichel @ 2014-05-21 17:36 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Rob Herring
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel
Hi,
This adds device tree support for the tsc2005 touchscreen
controller, which is currently only used by the Nokia N900
board.
The patch does not update the reset pin handling for platform
data based probe to avoid merge conflicts. The n900 platform
code will be removed in the near future (3.17?) and the driver
can be simplified once that has happened.
Changes since v3 [0]:
* Move common touchscreen DT handling code into its own file
* Add regulator support to tsc2005 driver
* Added N900 DTS patch for completeness. It should go via
Tony's Tree of course.
[0] https://lkml.org/lkml/2014/4/25/694
-- Sebastian
Sebastian Reichel (4):
Input: add common DT binding for touchscreens
Input: tsc2005: add DT support
Documentation: dt: Document TSC2005 DT binding
DTS: ARM: OMAP3-N900: Add tsc2005 support
.../bindings/input/touchscreen/touchscreen.txt | 27 +++++
.../bindings/input/touchscreen/tsc2005.txt | 42 +++++++
arch/arm/boot/dts/omap3-n900.dts | 17 ++-
drivers/input/touchscreen/Kconfig | 4 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/of_touchscreen.c | 44 ++++++++
drivers/input/touchscreen/tsc2005.c | 122 +++++++++++++++++----
include/linux/input/touchscreen.h | 22 ++++
8 files changed, 258 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
create mode 100644 drivers/input/touchscreen/of_touchscreen.c
create mode 100644 include/linux/input/touchscreen.h
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] touchscreen: Introduce the use of the managed version of kzalloc
From: Dmitry Torokhov @ 2014-05-21 15:32 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140521151405.GA8526@himangi-Dell>
Hi Himangi,
On Wed, May 21, 2014 at 08:44:05PM +0530, Himangi Saraogi wrote:
> - input_dev = input_allocate_device();
> + input_dev = devm_input_allocate_device(&pdev->dev);
...
> @@ -365,7 +359,6 @@ static int da9034_touch_remove(struct platform_device *pdev)
> struct da9034_touch *touch = platform_get_drvdata(pdev);
>
> input_unregister_device(touch->input_dev);
When using managed input devices calling input_unregister_device() is
unnecessary. Whole da9034_touch_remove() can be removed. I fixed it up
locally and applied your patch.
Thanks!
> - kfree(touch);
>
> return 0;
> }
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: mcs_touchkey: fix incorrect input device name
From: Dmitry Torokhov @ 2014-05-21 15:26 UTC (permalink / raw)
To: Beomho Seo
Cc: linux-input, Joonyoung Shim, Myungjoo Ham, Jaehoon Chung,
Chanwoo Choi
In-Reply-To: <537C509E.10705@samsung.com>
Hi Beomho,
On Wed, May 21, 2014 at 04:07:10PM +0900, Beomho Seo wrote:
> This patch fix a typo error at input device name.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> ---
> drivers/input/keyboard/mcs_touchkey.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/mcs_touchkey.c b/drivers/input/keyboard/mcs_touchkey.c
> index 1da8e0b..375b05c 100644
> --- a/drivers/input/keyboard/mcs_touchkey.c
> +++ b/drivers/input/keyboard/mcs_touchkey.c
> @@ -147,7 +147,7 @@ static int mcs_touchkey_probe(struct i2c_client *client,
> }
> dev_info(&client->dev, "Firmware version: %d\n", fw_ver);
>
> - input_dev->name = "MELPAS MCS Touchkey";
> + input_dev->name = "MELFAS MCS Touchkey";
Hmm, we have the same spelling in mcs5000_ts.c...
Thanks.
> input_dev->id.bustype = BUS_I2C;
> input_dev->dev.parent = &client->dev;
> input_dev->evbit[0] = BIT_MASK(EV_KEY);
> --
> 1.7.9.5
--
Dmitry
^ permalink raw reply
* [PATCH v2] HID: rmi: do not handle touchscreens through hid-rmi
From: Benjamin Tissoires @ 2014-05-21 15:15 UTC (permalink / raw)
To: Jiri Kosina, Andrew Duggan, linux-input, linux-kernel
Currently, hid-rmi drives every Synaptics product, but the touchscreens
on the Windows tablets should be handled through hid-multitouch.
Instead of providing a long list of PIDs, rely on the scan_report
capability to detect which should go to hid-multitouch, and which
should not go to hid-rmi.
related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=74241
https://bugzilla.redhat.com/show_bug.cgi?id=1089583
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Changes in v2:
- use HID_GROUP_RMI instead of HID_GROUP_HAVE_SPECIAL_DRIVER
- match all the HID devices with the proper group in hid-rmi instead of only the
Synaptics ones (we already spoted one Razer laptop with this touchpad which has
a different VID/PID)
drivers/hid/hid-core.c | 10 ++++++++--
drivers/hid/hid-rmi.c | 3 +--
include/linux/hid.h | 8 ++++++++
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5b74dab..bb43525 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -779,6 +779,14 @@ static int hid_scan_report(struct hid_device *hid)
(hid->group == HID_GROUP_MULTITOUCH))
hid->group = HID_GROUP_MULTITOUCH_WIN_8;
+ /*
+ * Vendor specific handlings
+ */
+ if ((hid->vendor == USB_VENDOR_ID_SYNAPTICS) &&
+ (hid->group == HID_GROUP_GENERIC))
+ /* hid-rmi should take care of them, not hid-generic */
+ hid->group = HID_GROUP_RMI;
+
vfree(parser);
return 0;
}
@@ -1888,8 +1896,6 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_SRWS1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, HID_ANY_ID) },
- { HID_I2C_DEVICE(USB_VENDOR_ID_SYNAPTICS, HID_ANY_ID) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THINGM, USB_DEVICE_ID_BLINK1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index c529b03..2451c7e 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -894,8 +894,7 @@ static void rmi_remove(struct hid_device *hdev)
}
static const struct hid_device_id rmi_id[] = {
- { HID_I2C_DEVICE(USB_VENDOR_ID_SYNAPTICS, HID_ANY_ID) },
- { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, HID_ANY_ID) },
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID) },
{ }
};
MODULE_DEVICE_TABLE(hid, rmi_id);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 54f855b..8ce9ff4 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -299,6 +299,9 @@ struct hid_item {
/*
* HID device groups
+ *
+ * Note: HID_GROUP_ANY is declared in linux/mod_devicetable.h
+ * and has a value of 0x0000
*/
#define HID_GROUP_GENERIC 0x0001
#define HID_GROUP_MULTITOUCH 0x0002
@@ -306,6 +309,11 @@ struct hid_item {
#define HID_GROUP_MULTITOUCH_WIN_8 0x0004
/*
+ * Vendor specific HID device groups
+ */
+#define HID_GROUP_RMI 0x0100
+
+/*
* This is the global environment of the parser. This information is
* persistent for main-items. The global environment can be saved and
* restored with PUSH/POP statements.
--
1.9.0
^ permalink raw reply related
* [PATCH] touchscreen: Introduce the use of the managed version of kzalloc
From: Himangi Saraogi @ 2014-05-21 15:14 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: julia.lawall
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also data allocated using input_allocate_device is moved to
devm_input_allocate_device and unnecessary labels are removed.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
drivers/input/touchscreen/da9034-ts.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/da9034-ts.c b/drivers/input/touchscreen/da9034-ts.c
index 8ccf7bb..ed85744 100644
--- a/drivers/input/touchscreen/da9034-ts.c
+++ b/drivers/input/touchscreen/da9034-ts.c
@@ -303,7 +303,8 @@ static int da9034_touch_probe(struct platform_device *pdev)
struct input_dev *input_dev;
int ret;
- touch = kzalloc(sizeof(struct da9034_touch), GFP_KERNEL);
+ touch = devm_kzalloc(&pdev->dev, sizeof(struct da9034_touch),
+ GFP_KERNEL);
if (touch == NULL) {
dev_err(&pdev->dev, "failed to allocate driver data\n");
return -ENOMEM;
@@ -322,11 +323,10 @@ static int da9034_touch_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(&touch->tsi_work, da9034_tsi_work);
touch->notifier.notifier_call = da9034_touch_notifier;
- input_dev = input_allocate_device();
+ input_dev = devm_input_allocate_device(&pdev->dev);
if (!input_dev) {
dev_err(&pdev->dev, "failed to allocate input device\n");
- ret = -ENOMEM;
- goto err_free_touch;
+ return -ENOMEM;
}
input_dev->name = pdev->name;
@@ -348,16 +348,10 @@ static int da9034_touch_probe(struct platform_device *pdev)
ret = input_register_device(input_dev);
if (ret)
- goto err_free_input;
+ return ret;
platform_set_drvdata(pdev, touch);
return 0;
-
-err_free_input:
- input_free_device(input_dev);
-err_free_touch:
- kfree(touch);
- return ret;
}
static int da9034_touch_remove(struct platform_device *pdev)
@@ -365,7 +359,6 @@ static int da9034_touch_remove(struct platform_device *pdev)
struct da9034_touch *touch = platform_get_drvdata(pdev);
input_unregister_device(touch->input_dev);
- kfree(touch);
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-21 14:53 UTC (permalink / raw)
To: Roland Bosa
Cc: Michal Malý, Dmitry Torokhov, open list:HID CORE LAYER,
linux-kernel@vger.kernel.org, Jiri Kosina, Anssi Hannula,
Simon Wood
In-Reply-To: <537BCB63.1020200@logitech.com>
On Tue, May 20, 2014 at 11:38 PM, Roland Bosa <rbosa@logitech.com> wrote:
> On 05/20/2014 12:00 PM, Michal Malı wrote:
> There's a healthy amount of
> code in the Windows driver that you would call 'quirks' which deals with
> deciding how to allocate multiple springs and dampers to a single slot.
But 2 Spring effects with different offsets and non-zero effective
force can't be combined into a single slot (without streaming them
with Constant force), right?
> Sometimes, even the springs and dampers are being streamed in via the
> constants force, but that requires (as you pointed out earlier) a fast
> update rate and some "smartness"
OK, is this method used when all force-slots are already full?
Or is it only used for some specific (restricted) devices, such as
devices with only 2 force slots?
And in this case, is the position of the device monitored at a speed
higher than 8ms, in order to keep the feedback-loop stable?
Thanks,
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-21 14:22 UTC (permalink / raw)
To: Michal Malý, Roland Bosa
Cc: Simon Wood, Dmitry Torokhov, open list:HID CORE LAYER,
linux-kernel@vger.kernel.org, Jiri Kosina, Anssi Hannula
In-Reply-To: <CADbOyBQfHAnZYJj=z-SF77yg+yNpAzETX_W2UGh56NsZo3o8ew@mail.gmail.com>
On Wed, May 21, 2014 at 3:35 PM, Elias Vanderstuyft <elias.vds@gmail.com> wrote:
> On Wed, May 21, 2014 at 4:13 AM, Michal Malý
> <madcatxster@devoid-pointer.net> wrote:
>> Proper decoupling of the userspace and driver is the only important thing that
>> is missing from the current code.
>
> Also dynamic updating of periodic effects is not yet supported in
> "ff-memless-next".
> This can also be important in simulation games (=second type), e.g.
> the "rFactor" game.
Oh, and I forgot some other things that need to be mentioned:
- Trigger-button is not yet implemented, as far as I know
- Custom force effects, in Linux it is called FF_CUSTOM. (however I
think we can neglect this effect for now)
- Infinite iterations in the Linux FF API is not supported.
@Roland:
Now I understand why Logitech Windows drivers have bugs in the
periodic implementation of the DInput specs:
Logitech seems to have based their drivers on the Immersion Studio
visualisation of the to-be-generated periodic effects, and these
visualisations are not conform with the DInput specs of MSDN.
Take a quick look at the MSDN specs for e.g. SawtoothUp:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee418719%28v=vs.85%29.aspx
Now open the Immersion Studio (demo) and create a standard SawtoothUp
effect, and look at the visualisation... It's wrong, right?
Same applies for SawtoothDown and Triangle.
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-21 14:08 UTC (permalink / raw)
To: Nestor Lopez Casado
Cc: Michal Malý, Roland Bosa, Simon Wood, Dmitry Torokhov,
open list:HID CORE LAYER, linux-kernel@vger.kernel.org,
Jiri Kosina, Anssi Hannula
In-Reply-To: <CAE7qMrrH5Yeya9gKx+gbi1w39mJoEj9xw4mh3D86dLaKsWWLSQ@mail.gmail.com>
On Wed, May 21, 2014 at 12:17 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
> Elias, Simon, Michal,
>
> It is unfortunate that we didn't get back to you in 2013 when you
> asked for help in reverse engineering, oftentimes we have conflicting
> priorities and a particular request may be left laying around for some
> time before being addressed. But please, don't hesitate to re-kick us
> if you feel we are not being reactive.
>
> Let me clearly say that our intentions are to disclose as much
> information as possible and to help the community in having great
> support to all our hardware across all platforms. We have zero problem
> with being asked for information.
OK, thanks for your reply.
Don't worry, I understand ;)
Elias
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-21 14:05 UTC (permalink / raw)
To: Simon Wood
Cc: Roland Bosa, Michal Malý, Dmitry Torokhov, linux-input,
linux-kernel, Jiri Kosina, Anssi Hannula
In-Reply-To: <2643156.2tkLFqgYFg@sigyn>
On Wed, May 21, 2014 at 4:13 AM, Michal Malý
<madcatxster@devoid-pointer.net> wrote:
> On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:
>>
>> The file format of an IFR is probably easily deducible. There's a lot of
>> textual clues to parameters and the values are also written out in
>> string form.
>>
>> I don't have a FEdit file at hand, but I suppose it will be similar.
>
> I believe that Elias successfully reverse engineered the effect file format
> produced by FEdit. There is no support for this kind of prefabricated effects
> in the Linux FF API.
Of course I did, Simon, what did you expect? :P
Here you are:
http://www.winehq.org/pipermail/wine-devel/2014-February/103108.html
It contains a description of the DInput effect file format (.ffe), a
working Python script to load these files and dump their contents, as
well as a bunch of example files and tests/results.
The FFE file format is binary RIFF, if you're interested.
But I prefer not to include such things in the Linux kernel, I believe
this is the task of the userspace application.
I'm planning to implement this function into Wine, but maybe SDL would
benefit from similar functionality too (using an open file-format
instead, of course)?
Anyway, this is off-topic.
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] Input: mcs_touchkey: add device tree binding document
From: Mark Rutland @ 2014-05-21 13:53 UTC (permalink / raw)
To: Beomho Seo
Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
dmitry.torokhov@gmail.com, Joonyoung Shim, Myungjoo Ham,
Jaehoon Chung, Chanwoo Choi
In-Reply-To: <537C3EFD.8040601@samsung.com>
On Wed, May 21, 2014 at 06:51:57AM +0100, Beomho Seo wrote:
> This patch add simple device tree bindings to
> MELFAS MCS5000/5080 controller.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> ---
> .../devicetree/bindings/input/mcs-touchkey.txt | 25 ++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/mcs-touchkey.txt
>
> diff --git a/Documentation/devicetree/bindings/input/mcs-touchkey.txt b/Documentation/devicetree/bindings/input/mcs-touchkey.txt
> new file mode 100644
> index 0000000..8364799
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/mcs-touchkey.txt
> @@ -0,0 +1,25 @@
> +* mcs_touchkey MELFAS MCS5000/5080 controller
> +
> +Required properties:
> +- compatible: must be "mcs5000_touchkey" or "mcs5080_touchkey"
NAK. These should be in "$VENDOR,$DEVICE" format (e.g. "melfas,mcs5000").
It looks like "melfas" is already used, but is undocumented. Please add
it to vendor-prefixes.txt.
> +- reg : I2C address of the chip
> +- interrupts: interrupt to which the chip is connected
> +- key_maxval: size of keycode table
Surely this is already implicit in the size of the linux,code property
data?
This is superfluous and broken. Please get rid of it.
> +- code: key code for this device
This doesn't match the example or driver. If this is a standard
property, please refer to a definition of the format.
> +
> +Example:
> +
> + i2c_touch_key: i2c-gpio-0 {
> + /* ... */
> +
> + touch_key@20 {
> + compatible = "mcs5080_touchkey";
> + reg = <0x20>;
> + interrupt-patrent = <gpj0>;
> + key_maxval = <2>;
> + linux, code = <0x0000009e
> + 0x000000a9>;
Random spacing?
Please bracket individual list elements.
Cheers,
Mark.
^ permalink raw reply
* Re: [PATCH 1/2] Input: mcs_touchkey: add device tree support
From: Mark Rutland @ 2014-05-21 13:48 UTC (permalink / raw)
To: Beomho Seo
Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
dmitry.torokhov@gmail.com, Joonyoung Shim, Myungjoo Ham,
Jaehoon Chung, Chanwoo Choi
In-Reply-To: <537C3EF5.90000@samsung.com>
On Wed, May 21, 2014 at 06:51:49AM +0100, Beomho Seo wrote:
> Add device tree support for mcs touchkey driver.
> Tested on exynos 4412 board.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> ---
> drivers/input/keyboard/mcs_touchkey.c | 73 +++++++++++++++++++++++++++++++--
> 1 file changed, 69 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/keyboard/mcs_touchkey.c b/drivers/input/keyboard/mcs_touchkey.c
> index 1da8e0b..9bff47b 100644
> --- a/drivers/input/keyboard/mcs_touchkey.c
> +++ b/drivers/input/keyboard/mcs_touchkey.c
> @@ -19,6 +19,7 @@
> #include <linux/irq.h>
> #include <linux/slab.h>
> #include <linux/pm.h>
> +#include <linux/of_gpio.h>
>
> /* MCS5000 Touchkey */
> #define MCS5000_TOUCHKEY_STATUS 0x04
> @@ -96,6 +97,60 @@ static irqreturn_t mcs_touchkey_interrupt(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +#ifdef CONFIG_OF
> +static struct mcs_platform_data *mcs_touchkey_parse_dt(struct device *dev)
> +{
> + struct mcs_platform_data *pdata;
> + struct device_node *np = dev->of_node;
> + unsigned int keymap[2];
> + unsigned int len;
> + int i = 0;
> + const __be32 *prop;
Hmm. Almost every use of __be32 *prop values is indicative of something
that can be done with existing accessors. I suspect that may be true
here...
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(dev, "Failed to allocate platform data\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + prop = of_get_property(np, "linux,code", &len);
> + if (!prop) {
> + dev_err(dev, "Failed to get code\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (len % sizeof(u32)) {
> + dev_err(dev, "Malformed keycode property\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + pdata->keymap_size = len / sizeof(u32);
Use of_property_count_u32_elems. It does all of this and returns a
negative error code if anything is wrong.
> +
> + if (of_property_read_u32(np, "key_maxval", &pdata->key_maxval)) {
> + dev_err(dev, "Failed to get key max value data\n");
> + return ERR_PTR(-EINVAL);
> + }
What is this? This sounds like an implementation detail. Why is it in
the DT?
Why doesn't it follow dt conventions ('-' rather than '_')?
> +
> + if (pdata->keymap_size > pdata->key_maxval) {
> + dev_err(dev, "Key map size overflow\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + for (i = 0; i < pdata->keymap_size; i++) {
> + u32 code = be32_to_cpup(prop + i);
Use the DT accessors (e.g. of_property_read_u32_index). There is
absolutely no reason to touch the raw DTB data here.
> + keymap[i] = MCS_KEY_MAP(i, code);
> + }
> + pdata->keymap = keymap;
> + return pdata;
> +}
> +#else
> +static inline struct mcs_platform_data *mcs_touchkey_parse_dt
> + (struct device *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
> static int mcs_touchkey_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -107,10 +162,14 @@ static int mcs_touchkey_probe(struct i2c_client *client,
> int error;
> int i;
>
> - pdata = dev_get_platdata(&client->dev);
> - if (!pdata) {
> - dev_err(&client->dev, "no platform data defined\n");
> - return -EINVAL;
> + if (&client->dev.of_node)
> + pdata = mcs_touchkey_parse_dt(&client->dev);
> + else
> + pdata = dev_get_platdata(&client->dev);
> +
> + if (IS_ERR(pdata)) {
> + dev_err(&client->dev, "Failed to get platform data\n");
> + return PTR_ERR(pdata);
> }
>
> data = kzalloc(sizeof(struct mcs_touchkey_data) +
> @@ -262,11 +321,17 @@ static const struct i2c_device_id mcs_touchkey_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, mcs_touchkey_id);
>
> +static struct of_device_id mcs_touchkey_dt_match[] = {
> + { .compatible = "mcs5000_touchkey", },
> + { .compatible = "mcs5080_touchkey", },
NAK. These do not follow the "$VENDOR,$DEVICE" pattern.
Mark.
> +};
> +
> static struct i2c_driver mcs_touchkey_driver = {
> .driver = {
> .name = "mcs_touchkey",
> .owner = THIS_MODULE,
> .pm = &mcs_touchkey_pm_ops,
> + .of_match_table = of_match_ptr(mcs_touchkey_dt_match),
> },
> .probe = mcs_touchkey_probe,
> .remove = mcs_touchkey_remove,
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-21 13:35 UTC (permalink / raw)
To: Michal Malý
Cc: Roland Bosa, Simon Wood, Dmitry Torokhov, linux-input,
linux-kernel, Jiri Kosina, Anssi Hannula
In-Reply-To: <2643156.2tkLFqgYFg@sigyn>
On Wed, May 21, 2014 at 4:13 AM, Michal Malý
<madcatxster@devoid-pointer.net> wrote:
> On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:
>> In any case, the USB traffic should be decoupled from the app. Any force
>> updates should only change state in the ff-memless[-next] driver. Any
>> change there should trickle down to a 'slot' representation of the
>> device. If there's any change in the slots, the device is marked as
>> 'dirty' and USB transfers are scheduled to send the latest state to the
>> physical device.
>>
>> The scheduling should keep track of how many requests are in-flight and
>> delay writing the next output, until the previous one has completed.
>
> The approach I had in mind would keep track of the last effect that made it to
> the device and the last effect that arrived from userspace. This would be
> stored for each effect slot. An update would be scheduled at the desired update
> rate. The updating routine would figure out the state change between last
> update and "now", send the required data to the device and reschedule itself.
> The routine could check if there are any USB transfers still running and
> reschedule itself immediately.
I've got another/(a more detailed?) idea about this:
We can use round-robin scheduling for the slots, and use a priority
queue for e.g. LED data or data that doesn't fit in the
slot-methodology and doesn't permit in-between packets to be lost.
And I believe that ff-memless-next should generate a periodic force
with a constant/defined sample-period/update-rate, while the layer
between ff-memless-next and USB transfers, i.e. the round-robin and
priority queue scheduler, should send the dirty slots as soon as
possible, i.e. when the USB pipe is clear or when some custom
#maxAllowedPacketsInUsbBuffer (optimized for somewhere between latency
and throughput) is not exceeded by the kernel USB queue.
Now the question is, can we query the state of the kernel USB queue?
Optionally, this method of packet scheduling could be used by other
kernel drivers (even non-FF drivers) as well, and can further increase
flexibility of ff-memless-next and the HW-specific drivers, and it
will reduce code duplication.
>> Question back to the community: are there APIs in the USB layer to check
>> for presence of in-progress requests? Can one add a 'completion'
>> callback to a request, that gets invoked on completion/cancellation?
>
> For instance "usb_submit_urb()" can have a completion handler that is called
> once the transfer is done. The current code uses "hid_hw_request()" which is
> asynchronous and doesn't report anything back.
>
> Proper decoupling of the userspace and driver is the only important thing that
> is missing from the current code.
Also dynamic updating of periodic effects is not yet supported in
"ff-memless-next".
This can also be important in simulation games (=second type), e.g.
the "rFactor" game.
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: usbhid: PicoLCD 256x64 USB error -71
From: Kieran Kunhya @ 2014-05-21 13:08 UTC (permalink / raw)
To: Bruno Prémont; +Cc: linux-input
In-Reply-To: <20140518203718.5422588f@neptune.home>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
The pin connections match yours and I have tried with different cables.
> Did some previous kernel release work?
I should have been clearer - I have tried many kernels in the 3.0
series and none work with this motherboard.
Other motherboards work fine.
> Could you provide verbose lsusb output and firmware version for your PicoLCD?
lsusb attached, when when the device is detected.
I think this corresponds to the firmware version:
[ 1.733167] usb 3-7: SerialNumber: Ver.00.03
Regards,
Kieran Kunhya
[-- Attachment #2: lsusb.txt --]
[-- Type: text/plain, Size: 22858 bytes --]
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x8008
bcdDevice 0.05
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 0 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x8000
bcdDevice 0.05
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 8
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 0 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Bus 003 Device 002: ID 04d8:c002 Microchip Technology, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04d8 Microchip Technology, Inc.
idProduct 0xc002
bcdDevice 0.02
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 2
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 150mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.01
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 290
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
Bus 003 Device 003: ID 413c:1003 Dell Computer Corp. Keyboard Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x413c Dell Computer Corp.
idProduct 0x1003 Keyboard Hub
bcdDevice 2.00
iManufacturer 1 Dell
iProduct 2 Dell USB Keyboard Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 2 Dell USB Keyboard Hub
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 2 Dell USB Keyboard Hub
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 24
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
bPwrOn2PwrGood 22 * 2 milli seconds
bHubContrCurrent 100 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.15
iManufacturer 3 Linux 3.15.0-rc5+ ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1a.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0507 highspeed power suspend enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.15
iManufacturer 3 Linux 3.15.0-rc5+ ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0507 highspeed power suspend enable connect
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.15
iManufacturer 3 Linux 3.15.0-rc5+ xhci_hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:14.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 15
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x80
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0103 power enable connect
Port 8: 0000.0100 power
Port 9: 0000.0100 power
Port 10: 0000.0103 power enable connect
Port 11: 0000.0100 power
Port 12: 0000.0100 power
Port 13: 0000.0100 power
Port 14: 0000.0100 power
Port 15: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 3.15
iManufacturer 3 Linux 3.15.0-rc5+ xhci_hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:14.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 31
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
Hub Descriptor:
bLength 12
bDescriptorType 42
nNbrPorts 6
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
bHubDecLat 0.0 micro seconds
wHubDelay 0 nano seconds
DeviceRemovable 0x00
Hub Port Status:
Port 1: 0000.02a0 5Gbps power Rx.Detect
Port 2: 0000.02a0 5Gbps power Rx.Detect
Port 3: 0000.02a0 5Gbps power Rx.Detect
Port 4: 0000.02a0 5Gbps power Rx.Detect
Port 5: 0000.02a0 5Gbps power Rx.Detect
Port 6: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 15
bNumDeviceCaps 1
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x02
wSpeedsSupported 0x0008
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 3
Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 512 micro seconds
Device Status: 0x0001
Self Powered
Bus 003 Device 004: ID 413c:2010 Dell Computer Corp. Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x413c Dell Computer Corp.
idProduct 0x2010 Keyboard
bcdDevice 2.00
iManufacturer 1 Dell
iProduct 3 Dell USB Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 3 Dell USB Keyboard
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 3 Dell USB Keyboard
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 65
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 3 Dell USB Keyboard
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 142
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 255
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply
* [PATCH] Support Xbox One controllers in xpad driver.
From: Ted Mielczarek @ 2014-05-21 12:26 UTC (permalink / raw)
To: linux-input; +Cc: dmitry.torokhov, linux-kernel, Ted Mielczarek
Xbox One controllers require an initialization message to start sending data,
so xpad_init_output becomes a required function. The Xbox One controller does
not have LEDs like the Xbox 360 controller, so that functionality is not
implemented. The format of messages controlling rumble is currently
undocumented, so rumble support is not yet implemented.
The only thing I'm not certain about in this patch is the check against bInterfaceNumber in xpad_probe. The Xbox One controller advertises three interfaces with the same interface class, subclass and protocol, and I couldn't see any way to match just the first one using usb_device_id.
Signed-off-by: Ted Mielczarek <ted@mielczarek.org>
---
drivers/input/joystick/xpad.c | 163 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 149 insertions(+), 14 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 603fe0d..800e2f4 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -95,7 +95,8 @@
#define XTYPE_XBOX 0
#define XTYPE_XBOX360 1
#define XTYPE_XBOX360W 2
-#define XTYPE_UNKNOWN 3
+#define XTYPE_XBOXONE 3
+#define XTYPE_UNKNOWN 4
static bool dpad_to_buttons;
module_param(dpad_to_buttons, bool, S_IRUGO);
@@ -121,6 +122,7 @@ static const struct xpad_device {
{ 0x045e, 0x0287, "Microsoft Xbox Controller S", 0, XTYPE_XBOX },
{ 0x045e, 0x0289, "Microsoft X-Box pad v2 (US)", 0, XTYPE_XBOX },
{ 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
+ { 0x045e, 0x02d1, "Microsoft X-Box One pad", 0, XTYPE_XBOXONE },
{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
@@ -245,9 +247,20 @@ static const signed short xpad_abs_triggers[] = {
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,1) }, \
{ XPAD_XBOX360_VENDOR_PROTOCOL(vend,129) }
+/* The Xbox One controller uses subclass 71 and protocol 208. */
+#define XPAD_XBOXONE_VENDOR_PROTOCOL(vend,pr) \
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO, \
+ .idVendor = (vend), \
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC, \
+ .bInterfaceSubClass = 71, \
+ .bInterfaceProtocol = (pr)
+#define XPAD_XBOXONE_VENDOR(vend) \
+ { XPAD_XBOXONE_VENDOR_PROTOCOL(vend,208) }
+
static struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */
XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */
+ XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */
XPAD_XBOX360_VENDOR(0x046d), /* Logitech X-Box 360 style controllers */
XPAD_XBOX360_VENDOR(0x0738), /* Mad Catz X-Box 360 controllers */
{ USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */
@@ -470,6 +483,101 @@ static void xpad360w_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned cha
xpad360_process_packet(xpad, cmd, &data[4]);
}
+/*
+ * xpadone_process_buttons
+ *
+ * Process a button update packet from an Xbox one controller.
+ */
+static void xpadone_process_buttons(struct usb_xpad *xpad,
+ struct input_dev *dev,
+ unsigned char *data)
+{
+ /* menu/view buttons */
+ input_report_key(dev, BTN_START, data[4] & 0x04);
+ input_report_key(dev, BTN_SELECT, data[4] & 0x08);
+
+ /* buttons A,B,X,Y */
+ input_report_key(dev, BTN_A, data[4] & 0x10);
+ input_report_key(dev, BTN_B, data[4] & 0x20);
+ input_report_key(dev, BTN_X, data[4] & 0x40);
+ input_report_key(dev, BTN_Y, data[4] & 0x80);
+
+ /* digital pad */
+ if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
+ /* dpad as buttons (left, right, up, down) */
+ input_report_key(dev, BTN_TRIGGER_HAPPY1, data[5] & 0x04);
+ input_report_key(dev, BTN_TRIGGER_HAPPY2, data[5] & 0x08);
+ input_report_key(dev, BTN_TRIGGER_HAPPY3, data[5] & 0x01);
+ input_report_key(dev, BTN_TRIGGER_HAPPY4, data[5] & 0x02);
+ } else {
+ input_report_abs(dev, ABS_HAT0X,
+ !!(data[5] & 0x08) - !!(data[5] & 0x04));
+ input_report_abs(dev, ABS_HAT0Y,
+ !!(data[5] & 0x02) - !!(data[5] & 0x01));
+ }
+
+ /* TL/TR */
+ input_report_key(dev, BTN_TL, data[5] & 0x10);
+ input_report_key(dev, BTN_TR, data[5] & 0x20);
+
+ /* stick press left/right */
+ input_report_key(dev, BTN_THUMBL, data[5] & 0x40);
+ input_report_key(dev, BTN_THUMBR, data[5] & 0x80);
+
+ if (!(xpad->mapping & MAP_STICKS_TO_NULL)) {
+ /* left stick */
+ input_report_abs(dev, ABS_X,
+ (__s16) le16_to_cpup((__le16 *)(data + 10)));
+ input_report_abs(dev, ABS_Y,
+ ~(__s16) le16_to_cpup((__le16 *)(data + 12)));
+
+ /* right stick */
+ input_report_abs(dev, ABS_RX,
+ (__s16) le16_to_cpup((__le16 *)(data + 14)));
+ input_report_abs(dev, ABS_RY,
+ ~(__s16) le16_to_cpup((__le16 *)(data + 16)));
+ }
+
+ /* triggers left/right */
+ if (xpad->mapping & MAP_TRIGGERS_TO_BUTTONS) {
+ input_report_key(dev, BTN_TL2,
+ (__u16) le16_to_cpup((__le16 *)(data + 6)));
+ input_report_key(dev, BTN_TR2,
+ (__u16) le16_to_cpup((__le16 *)(data + 8)));
+ } else {
+ input_report_abs(dev, ABS_Z,
+ (__u16) le16_to_cpup((__le16 *)(data + 6)));
+ input_report_abs(dev, ABS_RZ,
+ (__u16) le16_to_cpup((__le16 *)(data + 8)));
+ }
+}
+
+/*
+ * xpadone_process_packet
+ *
+ * Completes a request by converting the data into events for the
+ * input subsystem. This version is for the Xbox One controller.
+ *
+ * The report format was gleaned from
+ * https://github.com/kylelemons/xbox/blob/master/xbox.go
+ */
+
+static void xpadone_process_packet(struct usb_xpad *xpad,
+ u16 cmd, unsigned char *data)
+{
+ struct input_dev *dev = xpad->dev;
+
+ if (data[0] == 0x20) {
+ xpadone_process_buttons(xpad, dev, data);
+ } else if (data[0] == 0x07) {
+ /* the xbox button has its own special report */
+ input_report_key(dev, BTN_MODE, data[4] & 0x01);
+ }
+
+ if (data[0] == 0x20 || data[0] == 0x07)
+ input_sync(dev);
+}
+
static void xpad_irq_in(struct urb *urb)
{
struct usb_xpad *xpad = urb->context;
@@ -502,6 +610,9 @@ static void xpad_irq_in(struct urb *urb)
case XTYPE_XBOX360W:
xpad360w_process_packet(xpad, 0, xpad->idata);
break;
+ case XTYPE_XBOXONE:
+ xpadone_process_packet(xpad, 0, xpad->idata);
+ break;
default:
xpad_process_packet(xpad, 0, xpad->idata);
}
@@ -535,7 +646,6 @@ static void xpad_bulk_out(struct urb *urb)
}
}
-#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
static void xpad_irq_out(struct urb *urb)
{
struct usb_xpad *xpad = urb->context;
@@ -593,7 +703,11 @@ static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad)
goto fail2;
}
- ep_irq_out = &intf->cur_altsetting->endpoint[1].desc;
+ if (xpad->xtype == XTYPE_XBOXONE)
+ /* Xbox One controller has in/out endpoints swapped. */
+ ep_irq_out = &intf->cur_altsetting->endpoint[0].desc;
+ else
+ ep_irq_out = &intf->cur_altsetting->endpoint[1].desc;
usb_fill_int_urb(xpad->irq_out, xpad->udev,
usb_sndintpipe(xpad->udev, ep_irq_out->bEndpointAddress),
xpad->odata, XPAD_PKT_LEN,
@@ -621,11 +735,6 @@ static void xpad_deinit_output(struct usb_xpad *xpad)
xpad->odata, xpad->odata_dma);
}
}
-#else
-static int xpad_init_output(struct usb_interface *intf, struct usb_xpad *xpad) { return 0; }
-static void xpad_deinit_output(struct usb_xpad *xpad) {}
-static void xpad_stop_output(struct usb_xpad *xpad) {}
-#endif
#ifdef CONFIG_JOYSTICK_XPAD_FF
static int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect *effect)
@@ -692,7 +801,7 @@ static int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect
static int xpad_init_ff(struct usb_xpad *xpad)
{
- if (xpad->xtype == XTYPE_UNKNOWN)
+ if (xpad->xtype == XTYPE_UNKNOWN || xpad->xtype == XTYPE_XBOXONE)
return 0;
input_set_capability(xpad->dev, EV_FF, FF_RUMBLE);
@@ -801,6 +910,14 @@ static int xpad_open(struct input_dev *dev)
if (usb_submit_urb(xpad->irq_in, GFP_KERNEL))
return -EIO;
+ if (xpad->xtype == XTYPE_XBOXONE) {
+ /* Xbox one controller needs to be initialized. */
+ xpad->odata[0] = 0x05;
+ xpad->odata[1] = 0x20;
+ xpad->irq_out->transfer_buffer_length = 2;
+ return usb_submit_urb(xpad->irq_out, GFP_KERNEL);
+ }
+
return 0;
}
@@ -816,6 +933,7 @@ static void xpad_close(struct input_dev *dev)
static void xpad_set_up_abs(struct input_dev *input_dev, signed short abs)
{
+ struct usb_xpad *xpad = input_get_drvdata(input_dev);
set_bit(abs, input_dev->absbit);
switch (abs) {
@@ -827,7 +945,10 @@ static void xpad_set_up_abs(struct input_dev *input_dev, signed short abs)
break;
case ABS_Z:
case ABS_RZ: /* the triggers (if mapped to axes) */
- input_set_abs_params(input_dev, abs, 0, 255, 0, 0);
+ if (xpad->xtype == XTYPE_XBOXONE)
+ input_set_abs_params(input_dev, abs, 0, 1023, 0, 0);
+ else
+ input_set_abs_params(input_dev, abs, 0, 255, 0, 0);
break;
case ABS_HAT0X:
case ABS_HAT0Y: /* the d-pad (only if dpad is mapped to axes */
@@ -850,6 +971,15 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
break;
}
+ if (xpad_device[i].xtype == XTYPE_XBOXONE
+ && intf->cur_altsetting->desc.bInterfaceNumber != 0) {
+ /* The Xbox One controller lists three interfaces all with the
+ * same interface class, subclass and protocol. Differentiate by
+ * interface number.
+ */
+ return -ENODEV;
+ }
+
xpad = kzalloc(sizeof(struct usb_xpad), GFP_KERNEL);
input_dev = input_allocate_device();
if (!xpad || !input_dev) {
@@ -920,7 +1050,8 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
__set_bit(xpad_common_btn[i], input_dev->keybit);
/* set up model-specific ones */
- if (xpad->xtype == XTYPE_XBOX360 || xpad->xtype == XTYPE_XBOX360W) {
+ if (xpad->xtype == XTYPE_XBOX360 || xpad->xtype == XTYPE_XBOX360W
+ || xpad->xtype == XTYPE_XBOXONE) {
for (i = 0; xpad360_btn[i] >= 0; i++)
__set_bit(xpad360_btn[i], input_dev->keybit);
} else {
@@ -933,7 +1064,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
__set_bit(xpad_btn_pad[i], input_dev->keybit);
} else {
for (i = 0; xpad_abs_pad[i] >= 0; i++)
- xpad_set_up_abs(input_dev, xpad_abs_pad[i]);
+ xpad_set_up_abs(input_dev, xpad_abs_pad[i]);
}
if (xpad->mapping & MAP_TRIGGERS_TO_BUTTONS) {
@@ -956,7 +1087,11 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
if (error)
goto fail5;
- ep_irq_in = &intf->cur_altsetting->endpoint[0].desc;
+ if (xpad->xtype == XTYPE_XBOXONE)
+ /* Xbox One controller has in/out endpoints swapped. */
+ ep_irq_in = &intf->cur_altsetting->endpoint[1].desc;
+ else
+ ep_irq_in = &intf->cur_altsetting->endpoint[0].desc;
usb_fill_int_urb(xpad->irq_in, udev,
usb_rcvintpipe(udev, ep_irq_in->bEndpointAddress),
xpad->idata, XPAD_PKT_LEN, xpad_irq_in,
@@ -1010,7 +1145,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
/*
* Submit the int URB immediately rather than waiting for open
* because we get status messages from the device whether
- * or not any controllers are attached. In fact, it's
+ * or not any controllers are attached. In fact, it's
* exactly the message that a controller has arrived that
* we're waiting for.
*/
--
1.9.1
^ permalink raw reply related
* re: Input: atmel_mxt_ts - read and report bootloader version
From: Dan Carpenter @ 2014-05-21 12:26 UTC (permalink / raw)
To: nick.dyer; +Cc: linux-input
Hello Nick Dyer,
The patch e57a66aa8534: "Input: atmel_mxt_ts - read and report
bootloader version" from May 18, 2014, leads to the following static
checker warning:
drivers/input/touchscreen/atmel_mxt_ts.c:437 mxt_get_bootloader_version()
warn: signedness bug returning '(-5)'
drivers/input/touchscreen/atmel_mxt_ts.c
429 static u8 mxt_get_bootloader_version(struct mxt_data *data, u8 val)
430 {
431 struct device *dev = &data->client->dev;
432 u8 buf[3];
433
434 if (val & MXT_BOOT_EXTENDED_ID) {
435 if (mxt_bootloader_read(data, &buf[0], 3) != 0) {
436 dev_err(dev, "%s: i2c failure\n", __func__);
437 return -EIO;
^^^^
This gets truncated into a number from 0-255 and anyway the caller
doesn't check for errors.
438 }
439
440 dev_dbg(dev, "Bootloader ID:%d Version:%d\n", buf[1], buf[2]);
441
442 return buf[0];
443 } else {
444 dev_dbg(dev, "Bootloader ID:%d\n", val & MXT_BOOT_ID_MASK);
445
446 return val;
447 }
448 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Nestor Lopez Casado @ 2014-05-21 10:17 UTC (permalink / raw)
To: Michal Malý
Cc: Roland Bosa, Simon Wood, Dmitry Torokhov,
open list:HID CORE LAYER, linux-kernel@vger.kernel.org,
Jiri Kosina, Elias Vanderstuyft, anssi.hannula
In-Reply-To: <2643156.2tkLFqgYFg@sigyn>
Elias, Simon, Michal,
It is unfortunate that we didn't get back to you in 2013 when you
asked for help in reverse engineering, oftentimes we have conflicting
priorities and a particular request may be left laying around for some
time before being addressed. But please, don't hesitate to re-kick us
if you feel we are not being reactive.
Let me clearly say that our intentions are to disclose as much
information as possible and to help the community in having great
support to all our hardware across all platforms. We have zero problem
with being asked for information.
Many thanks,
-nestor
On Wed, May 21, 2014 at 4:13 AM, Michal Malý
<madcatxster@devoid-pointer.net> wrote:
>
> On Tuesday 20 of May 2014 18:17:51 Roland Bosa wrote:
> >
> > The file format of an IFR is probably easily deducible. There's a lot of
> > textual clues to parameters and the values are also written out in
> > string form.
> >
> > I don't have a FEdit file at hand, but I suppose it will be similar.
>
> I believe that Elias successfully reverse engineered the effect file format
> produced by FEdit. There is no support for this kind of prefabricated effects
> in the Linux FF API.
>
> > > I assume that most AAA games, would implement these through some middle
> > > layer. I think that is probably via Steam using SDL2 haptic API, we have
> > > been testing against SDL2's 'testhaptic'.
> >
> > I wasn't aware of this layer. I must read up on it. It sounds like a
> > simple way to access force feedback - I guess a game developer should
> > shed some light on this...
> >
> >
> > > Do you see another path (which we should be supporting/testing)?
> >
> > Nope, not at this time.
> >
> > > There was some discussion about rate limiting the USB packets to the
> > > wheel, and how to deal if app updates too quickly. Is there an upper limit
> > > for the wheel itself, or is it just the USB 'pipe' which is the limiting
> > > factor?
> >
> > On the Windows side we send 125 reports/sec. The entire simulation loop
> > runs with a 8ms resolution. I assume this value was chosen for some
> > hardware constraints back in the days, but it has proven to be a good
> > compromise for simulated periodics and physics constraints.
>
> Our current code uses 8 msecs delay as well.
>
> > In any case, the USB traffic should be decoupled from the app. Any force
> > updates should only change state in the ff-memless[-next] driver. Any
> > change there should trickle down to a 'slot' representation of the
> > device. If there's any change in the slots, the device is marked as
> > 'dirty' and USB transfers are scheduled to send the latest state to the
> > physical device.
> >
> > The scheduling should keep track of how many requests are in-flight and
> > delay writing the next output, until the previous one has completed.
>
> The approach I had in mind would keep track of the last effect that made it to
> the device and the last effect that arrived from userspace. This would be
> stored for each effect slot. An update would be scheduled at the desired update
> rate. The updating routine would figure out the state change between last
> update and "now", send the required data to the device and reschedule itself.
> The routine could check if there are any USB transfers still running and
> reschedule itself immediately.
>
> > Question back to the community: are there APIs in the USB layer to check
> > for presence of in-progress requests? Can one add a 'completion'
> > callback to a request, that gets invoked on completion/cancellation?
>
> For instance "usb_submit_urb()" can have a completion handler that is called
> once the transfer is done. The current code uses "hid_hw_request()" which is
> asynchronous and doesn't report anything back.
>
> Proper decoupling of the userspace and driver is the only important thing that
> is missing from the current code.
>
> Michal
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] input: pcap2: avoid calling mutex_lock() in irq handler
From: Antonio Ospite @ 2014-05-21 9:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Alexey Khoroshilov, linux-input, linux-kernel, ldv-project,
Daniel Ribeiro, Ilya Petrov, Antonio Ospite
In-Reply-To: <20140406202436.GA16739@core.coreip.homeip.net>
On Sun, 6 Apr 2014 13:24:36 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Sun, Apr 06, 2014 at 12:54:50AM +0400, Alexey Khoroshilov wrote:
> > pcap_keys_handler() calls ezx_pcap_read() that calls mutex_lock().
> > pcap_keys_handler() is registered as nonthreaded irq handler,
> > that means sleeping function is called in irq handler.
> >
> > The patch makes a switch to threaded irq handling.
> > Compile tested only.
> >
> > Found by Linux Driver Verification project (linuxtesting.org).
> >
> > Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> > ---
> > drivers/input/misc/pcap_keys.c | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/input/misc/pcap_keys.c b/drivers/input/misc/pcap_keys.c
> > index cd230365166e..2a10f3a30969 100644
> > --- a/drivers/input/misc/pcap_keys.c
> > +++ b/drivers/input/misc/pcap_keys.c
> > @@ -79,13 +79,15 @@ static int pcap_keys_probe(struct platform_device *pdev)
> > if (err)
> > goto fail_allocate;
> >
> > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > - pcap_keys_handler, 0, "Power key", pcap_keys);
> > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > + NULL, pcap_keys_handler, 0,
> > + "Power key", pcap_keys);
> > if (err)
> > goto fail_register;
> >
> > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > - pcap_keys_handler, 0, "Headphone button", pcap_keys);
> > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > + NULL, pcap_keys_handler, 0,
> > + "Headphone button", pcap_keys);
>
> So I guess we do need threaded IRQ here, but I do not see the pcap's
> irqchip specifying IRQCHIP_ONESHOT_SAFE so I do not think
> request_threaded_irq() without IRQF_ONESHOT would succeed.
>
> Can someone test the change to be sure?
>
Tested-by: Antonio Ospite <ao2@ao2.it>
I confirm the keys still work fine with the patch applied on a 3.2
kernel. I cannot test on a newer version for now.
Sorry for the delay.
Ciao ciao,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
From: Lee Jones @ 2014-05-21 9:14 UTC (permalink / raw)
To: Carlo Caione
Cc: Mark Brown, linux-arm-kernel, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
Maxime Ripard, Hans De Goede, Emilio Lopez, wens Tsai,
sameo-VuQAYsv1563Yd54FQh9/CA, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Boris BREZILLON
In-Reply-To: <CAOQ7t2aBc5tFYk2MkfL9QqvFf5fcebwKtO97F3S=WdJ2uFE_jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> >> This set of patches introduces the core driver and support for two different
> >> subsystems:
> >> - Regulators
> >
> >> .../ABI/testing/sysfs-driver-input-axp-pek | 11 +
> >> Documentation/devicetree/bindings/mfd/axp20x.txt | 93 +++++++
> >> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> >> arch/arm/configs/multi_v7_defconfig | 3 +
> >> arch/arm/configs/sunxi_defconfig | 4 +
> >> drivers/input/misc/Kconfig | 11 +
> >> drivers/input/misc/Makefile | 1 +
> >> drivers/input/misc/axp20x-pek.c | 281 +++++++++++++++++++++
> >> drivers/mfd/Kconfig | 12 +
> >> drivers/mfd/Makefile | 1 +
> >> drivers/mfd/axp20x.c | 258 +++++++++++++++++++
> >> include/linux/mfd/axp20x.h | 180 +++++++++++++
> >> 12 files changed, 856 insertions(+)
> >
> > The regulator changes don't appear to be showing up in the diffstat or
> > obviously in the series?
>
> Right. Cut-and-paste error.
> You have already applied the regulator patches so I didn't include
> them here (in theory I posted this series to be picked up by Lee).
That's fine. Just tell me which patches need to stay together and
which are able to be applied through their respective subsystem trees
separately. Then, once I have all the Acks I can apply no problem.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
From: Carlo Caione @ 2014-05-21 7:24 UTC (permalink / raw)
To: Mark Brown
Cc: Carlo Caione, linux-arm-kernel,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Maxime Ripard, Hans De Goede,
Emilio Lopez, wens Tsai, sameo-VuQAYsv1563Yd54FQh9/CA,
Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Lee Jones,
Boris BREZILLON
In-Reply-To: <20140520222307.GK12304-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Wed, May 21, 2014 at 12:23 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, May 19, 2014 at 09:47:41PM +0200, Carlo Caione wrote:
>
>> This set of patches introduces the core driver and support for two different
>> subsystems:
>> - Regulators
>
>> .../ABI/testing/sysfs-driver-input-axp-pek | 11 +
>> Documentation/devicetree/bindings/mfd/axp20x.txt | 93 +++++++
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> arch/arm/configs/multi_v7_defconfig | 3 +
>> arch/arm/configs/sunxi_defconfig | 4 +
>> drivers/input/misc/Kconfig | 11 +
>> drivers/input/misc/Makefile | 1 +
>> drivers/input/misc/axp20x-pek.c | 281 +++++++++++++++++++++
>> drivers/mfd/Kconfig | 12 +
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/axp20x.c | 258 +++++++++++++++++++
>> include/linux/mfd/axp20x.h | 180 +++++++++++++
>> 12 files changed, 856 insertions(+)
>
> The regulator changes don't appear to be showing up in the diffstat or
> obviously in the series?
Right. Cut-and-paste error.
You have already applied the regulator patches so I didn't include
them here (in theory I posted this series to be picked up by Lee).
Thanks,
--
Carlo Caione
^ 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