* [RESEND PATCH v2 4/8] Input: sx8654 - add sx8655 and sx8656 to compatibles
From: Richard Leitner @ 2018-12-18 8:36 UTC (permalink / raw)
To: dmitry.torokhov, mark.rutland
Cc: robh+dt, linux-input, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20181218083606.25795-1-richard.leitner@skidata.com>
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
---
drivers/input/touchscreen/sx8654.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/touchscreen/sx8654.c b/drivers/input/touchscreen/sx8654.c
index 238f56b1581b..afa4da138fe9 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -293,6 +293,8 @@ static int sx8654_probe(struct i2c_client *client,
#ifdef CONFIG_OF
static const struct of_device_id sx8654_of_match[] = {
{ .compatible = "semtech,sx8654", },
+ { .compatible = "semtech,sx8655", },
+ { .compatible = "semtech,sx8656", },
{ },
};
MODULE_DEVICE_TABLE(of, sx8654_of_match);
@@ -300,6 +302,8 @@ MODULE_DEVICE_TABLE(of, sx8654_of_match);
static const struct i2c_device_id sx8654_id_table[] = {
{ "semtech_sx8654", 0 },
+ { "semtech_sx8655", 0 },
+ { "semtech_sx8656", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, sx8654_id_table);
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v2 3/8] dt-bindings: input: touchscreen: sx8654: add compatible models
From: Richard Leitner @ 2018-12-18 8:36 UTC (permalink / raw)
To: dmitry.torokhov, mark.rutland
Cc: robh+dt, linux-input, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20181218083606.25795-1-richard.leitner@skidata.com>
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
index ca521d8f7d65..a538678424dd 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
@@ -1,7 +1,10 @@
* Semtech SX8654 I2C Touchscreen Controller
Required properties:
-- compatible: must be "semtech,sx8654"
+- compatible: must be one of the following, depending on the model:
+ "semtech,sx8654"
+ "semtech,sx8655"
+ "semtech,sx8656"
- reg: i2c slave address
- interrupts: touch controller interrupt
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v2 2/8] Input: sx8654 - add reset-gpio support
From: Richard Leitner @ 2018-12-18 8:36 UTC (permalink / raw)
To: dmitry.torokhov, mark.rutland
Cc: robh+dt, linux-input, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20181218083606.25795-1-richard.leitner@skidata.com>
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
---
drivers/input/touchscreen/sx8654.c | 40 +++++++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/sx8654.c b/drivers/input/touchscreen/sx8654.c
index ed29db3ec731..238f56b1581b 100644
--- a/drivers/input/touchscreen/sx8654.c
+++ b/drivers/input/touchscreen/sx8654.c
@@ -33,6 +33,8 @@
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
/* register addresses */
#define I2C_REG_TOUCH0 0x00
@@ -74,6 +76,7 @@
struct sx8654 {
struct input_dev *input;
struct i2c_client *client;
+ struct gpio_desc *gpio_reset;
};
static irqreturn_t sx8654_irq(int irq, void *handle)
@@ -124,6 +127,27 @@ static irqreturn_t sx8654_irq(int irq, void *handle)
return IRQ_HANDLED;
}
+static int sx8654_reset(struct sx8654 *ts)
+{
+ int err;
+
+ if (ts->gpio_reset) {
+ gpiod_set_value_cansleep(ts->gpio_reset, 1);
+ udelay(2); /* Tpulse > 1µs */
+ gpiod_set_value_cansleep(ts->gpio_reset, 0);
+
+ return 0;
+ }
+
+ dev_dbg(&ts->client->dev, "NRST unavailable, try softreset\n");
+ err = i2c_smbus_write_byte_data(ts->client, I2C_REG_SOFTRESET,
+ SOFTRESET_VALUE);
+ if (err)
+ return err;
+ else
+ return 0;
+}
+
static int sx8654_open(struct input_dev *dev)
{
struct sx8654 *sx8654 = input_get_drvdata(dev);
@@ -186,6 +210,17 @@ static int sx8654_probe(struct i2c_client *client,
if (!sx8654)
return -ENOMEM;
+ sx8654->gpio_reset = devm_gpiod_get_optional(&client->dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(sx8654->gpio_reset)) {
+ error = PTR_ERR(sx8654->gpio_reset);
+ if (error != -EPROBE_DEFER)
+ dev_err(&client->dev, "unable to get reset-gpio: %d\n",
+ error);
+ return error;
+ }
+ dev_dbg(&client->dev, "got GPIO reset pin\n");
+
input = devm_input_allocate_device(&client->dev);
if (!input)
return -ENOMEM;
@@ -206,10 +241,9 @@ static int sx8654_probe(struct i2c_client *client,
input_set_drvdata(sx8654->input, sx8654);
- error = i2c_smbus_write_byte_data(client, I2C_REG_SOFTRESET,
- SOFTRESET_VALUE);
+ error = sx8654_reset(sx8654);
if (error) {
- dev_err(&client->dev, "writing softreset value failed");
+ dev_err(&client->dev, "reset failed");
return error;
}
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v2 1/8] dt-bindings: input: touchscreen: sx8654: add reset-gpio property
From: Richard Leitner @ 2018-12-18 8:35 UTC (permalink / raw)
To: dmitry.torokhov, mark.rutland
Cc: robh+dt, linux-input, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20181218083606.25795-1-richard.leitner@skidata.com>
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
index 4886c4aa2906..ca521d8f7d65 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
@@ -5,6 +5,9 @@ Required properties:
- reg: i2c slave address
- interrupts: touch controller interrupt
+Optional properties:
+ - reset-gpios: GPIO specification for the NRST input
+
Example:
sx8654@48 {
@@ -12,4 +15,5 @@ Example:
reg = <0x48>;
interrupt-parent = <&gpio6>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
};
--
2.11.0
^ permalink raw reply related
* [RESEND PATCH v2 0/8] Input: sx8654 - reset-gpio, sx865[056] support, etc.
From: Richard Leitner @ 2018-12-18 8:35 UTC (permalink / raw)
To: dmitry.torokhov, mark.rutland
Cc: robh+dt, linux-input, devicetree, linux-kernel, richard.leitner
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Changes RESEND v2:
- added "Reviewed-by: Rob Herring <robh@kernel.org>" tags
Changes v2:
- use devm_gpiod_get_optional in probe instead of in #ifdef CONFIG_OF
- convert flags to BIT() in a separate patch
- replace hrtimer with "regular" timer
- use of_device_get_match_data instead of of_match_device
- add driver data to i2c_device_id table for non-DT fallback
- fix sequence of common touchscreen initialization
- div. minor stlye changes
Richard Leitner (8):
dt-bindings: input: touchscreen: sx8654: add reset-gpio property
Input: sx8654 - add reset-gpio support
dt-bindings: input: touchscreen: sx8654: add compatible models
Input: sx8654 - add sx8655 and sx8656 to compatibles
dt-bindings: input: touchscreen: sx8654: add sx8650 to comatibles
Input: sx8654 - add sx8650 support
Input: sx8654 - use common of_touchscreen functions
Input: sx8654 - convert #defined flags to BIT(x)
.../bindings/input/touchscreen/sx8654.txt | 10 +-
drivers/input/touchscreen/sx8654.c | 245 ++++++++++++++++++---
2 files changed, 229 insertions(+), 26 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH] Input: elantech - Disable elan-i2c for P52 and P72
From: Peter Hutterer @ 2018-12-18 8:13 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, kt.liao, Aaron Ma, Kai Heng Feng, linux-input,
linux-kernel, stable
In-Reply-To: <20181212154205.24025-1-benjamin.tissoires@redhat.com>
On Wed, Dec 12, 2018 at 04:42:05PM +0100, Benjamin Tissoires wrote:
> The current implementation of elan_i2c is known to not support those
> 2 laptops.
>
> A proper fix is to tweak both elantech and elan_i2c to transmit the
> correct information from PS/2, which would make a bad candidate for
> stable.
>
> So to give us some time for fixing the root of the problem, disable
> elan_i2c for the devices we know are not behaving properly.
>
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> Link: https://bugs.archlinux.org/task/59714
> Fixes: df077237cf55 Input: elantech - detect new ICs and setup Host Notify for them
>
> Cc: stable@vger.kernel.org # v4.18+
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Cheers,
Peter
> ---
> drivers/input/mouse/elantech.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 2d95e8d93cc7..830ae9f07045 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1767,6 +1767,18 @@ static int elantech_smbus = IS_ENABLED(CONFIG_MOUSE_ELAN_I2C_SMBUS) ?
> module_param_named(elantech_smbus, elantech_smbus, int, 0644);
> MODULE_PARM_DESC(elantech_smbus, "Use a secondary bus for the Elantech device.");
>
> +static const char * const i2c_blacklist_pnp_ids[] = {
> + /*
> + * these are known to not be working properly as bits are missing
> + * in elan_i2c
> + */
> + "LEN2131", /* ThinkPad P52 w/ NFC */
> + "LEN2132", /* ThinkPad P52 */
> + "LEN2133", /* ThinkPad P72 w/ NFC */
> + "LEN2134", /* ThinkPad P72 */
> + NULL
> +};
> +
> static int elantech_create_smbus(struct psmouse *psmouse,
> struct elantech_device_info *info,
> bool leave_breadcrumbs)
> @@ -1802,10 +1814,12 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
>
> if (elantech_smbus == ELANTECH_SMBUS_NOT_SET) {
> /*
> - * New ICs are enabled by default.
> + * New ICs are enabled by default, unless mentioned in
> + * i2c_blacklist_pnp_ids.
> * Old ICs are up to the user to decide.
> */
> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> + if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
> + psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
> return -ENXIO;
> }
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate
From: Numan Demirdöğen @ 2018-12-18 7:23 UTC (permalink / raw)
To: Pavel Machek
Cc: jason.low2, Waiman.Long, paulmck, tglx, dmitry.torokhov, peterz,
mingo, linux-kernel, linux-input
In-Reply-To: <20181202222809.GA29467@amd>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
Sun, 2 Dec 2018 23:28:09 +0100 tarihinde
Pavel Machek <pavel@ucw.cz> yazdı:
>On Fri 2018-11-30 15:44:55, Numan Demirdöğen wrote:
>> Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
>> Numan Demirdöğen <if.gnu.linux@gmail.com> yazdı:
>>
>> >Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
>> >Pavel Machek <pavel@ucw.cz> yazdı:
>> >
>> >> Hi!
>> >>
>> >> Here's problem bisected down to:
>> >>
>> >> commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
>> >> Author: Peter Zijlstra <peterz@infradead.org>
>> >> Date: Tue Aug 23 14:40:16 2016 +0200
>> >>
>> >> locking/mutex: Add lock handoff to avoid starvation
>> >>
>> >> Implement lock handoff to avoid lock starvation.
>> >>
>> >> Numan, I assume revert of that patch on the 4.18 kernel still
>> >> makes it work?
>> >>
>> >
>> >Unfortunately, I could not revert
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c on kernels from 4.18.16 to
>> >4.10-rc1 because there were too much conflicts, which I could not
>> >solve as an "average Joe". I tried
>> >a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 which is parent of
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c and succeeded to compile
>> >kernel.
>> >
>> >git checkout a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3
>> >
>> >Then, I compiled kernel and rebooted with it. I tried a couples of
>> >times suspending and resuming, all of the time keyboard worked as
>> >expected.
>> >
>>
>> With this one line patch from Takashi Iwai, keyboard is working as
>> expected after resuming from suspend/hibernate.
>>
>> --- a/kernel/locking/mutex.c
>> +++ b/kernel/locking/mutex.c
>> @@ -59,7 +59,7 @@ EXPORT_SYMBOL(__mutex_init);
>> * Bit2 indicates handoff has been done and we're waiting for
>> pickup. */
>> #define MUTEX_FLAG_WAITERS 0x01
>> -#define MUTEX_FLAG_HANDOFF 0x02
>> +#define MUTEX_FLAG_HANDOFF 0x00
>> #define MUTEX_FLAG_PICKUP 0x04
>>
>> #define MUTEX_FLAGS 0x07
>>
>>
>> Thanks in advance and regards,
>
>Ok. So it is a regression, and you can ask Linus to apply this
>.. but... that's kind of heavy solution. Peter, do you have any other
>ideas?
>
> Pavel
Hi,
I did not mention the one line patch from Takashi Iwai as a means of fix
but as a hint. Sorry for misunderstanding.
Here is a another hint from another user:
I found that passing the options i8042.reset=1 i8042.dumbkbd=1 i8042.direct=1
results in the keyboard functioning after resume. However, there is a
long delay before the keyboard or mouse will respond to input on the
lock screen.[1]
[1] https://bugzilla.kernel.org/show_bug.cgi?id=195471#c39
--
Numan Demirdöğen
[-- Attachment #2: Dijital OpenPGP imzası --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/8] iio: adc: add STMPE ADC devicetree bindings
From: Rob Herring @ 2018-12-17 22:15 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, thierry.reding, Max Krummenacher,
Philippe Schenker, devicetree, linux-iio, Hartmut Knaack,
Alexandre Torgue, linux-input, linux-kernel, Dmitry Torokhov,
Lee Jones, Maxime Coquelin, Mark Rutland, Peter Meerwald-Stadler,
linux-stm32, linux-arm-kernel, Lars-Peter Clausen
In-Reply-To: <20181212130649.15146-6-dev@pschenker.ch>
On Wed, Dec 12, 2018 at 02:06:47PM +0100, Philippe Schenker wrote:
> From: Stefan Agner <stefan@agner.ch>
>
> This adds the devicetree bindings for the STMPE ADC. And corrects a
> typo in st,sample-time it is rather "6 -> 124 clocks" according
> to the datasheet and not 144.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> ---
>
> Changes in v4:
> - Put reformatting in a separate precursor patch.
>
> Changes in v3:
> - Reformatted documentation for touchscreen to use tabs and have a better
> overview of the settings.
> - Added note which adc-settings will take precedence.
> - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
> in the datasheet.
>
> Changes in v2:
> - Moved the bindings for ADC to the overlying mfd.
> - Reformatted for better readability
>
> .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++++++++++++
> .../bindings/input/touchscreen/stmpe.txt | 32 +++++++++----------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++++++++
> 3 files changed, 51 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> new file mode 100644
> index 000000000000..480e66422625
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> @@ -0,0 +1,21 @@
> +STMPE ADC driver
> +----------------
> +
> +Required properties:
> + - compatible: "st,stmpe-adc"
> +
> +Optional properties:
> +Note that the ADC is shared with the STMPE touchscreen. ADC related settings
> +have to be done in the mfd.
> +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> + requestable due to different usage (e.g. touch)
> +
> +Node name must be stmpe_adc and should be child node of stmpe node to
> +which it belongs.
> +
> +Example:
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> + };
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 1d3f84308142..8e2b240882fa 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,18 +5,6 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time : ADC conversion time in number of clock.
> - 0 -> 36 clocks 4 -> 80 clocks (recommended)
> - 1 -> 44 clocks 5 -> 96 clocks
> - 2 -> 56 clocks 6 -> 144 clocks
> - 3 -> 64 clocks
> -- st,mod-12b : ADC Bit mode
> - 0 -> 10bit ADC 1 -> 12bit ADC
> -- st,ref-sel : ADC reference source
> - 0 -> internal 1 -> external
> -- st,adc-freq : ADC Clock speed
> - 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> - 1 -> 3.25 MHz
> - st,ave-ctrl : Sample average control
> 0 -> 1 sample
> 1 -> 2 samples
> @@ -40,17 +28,29 @@ Optional properties:
> 0 -> 20 mA (typical 35mA max)
> 1 -> 50 mA (typical 80 mA max)
>
> +Optional properties common with MFD (deprecated):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
>
> +Note that common ADC settings of stmpe_touchscreen will take precedence.
This isn't clear. The parent or child properties take precedence?
> +
> Example:
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - st,sample-time = <4>;
> - st,mod-12b = <1>;
> - st,ref-sel = <0>;
> - st,adc-freq = <1>;
It would be nice to see an example with both ADC and touchscreen.
> st,ave-ctrl = <1>;
> st,touch-det-delay = <2>;
> st,settling = <2>;
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index a46e7177195d..d4408a417193 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -14,6 +14,20 @@ Optional properties:
> - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - irq-gpio : If present, which GPIO to use for event IRQ
>
> +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Example:
>
> stmpe1601: stmpe1601@40 {
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: stmpe: reformatting parameter list and use tabs only
From: Rob Herring @ 2018-12-17 22:06 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, thierry.reding, Philippe Schenker,
devicetree, Max Krummenacher, Alexandre Torgue, linux-input,
linux-kernel, Dmitry Torokhov, Lee Jones, Maxime Coquelin,
Mark Rutland, linux-stm32, linux-arm-kernel
In-Reply-To: <20181212130649.15146-1-dev@pschenker.ch>
On Wed, Dec 12, 2018 at 02:06:42PM +0100, Philippe Schenker wrote:
> This patch reformats the parameter list for stmpe device in a
> table-style so it is more clear to read.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Need to fix the author and S-o-b emails to match.
> ---
>
> Changes in v4:
> - New separate precursor patch for holding reformatting
>
> Changes in v3: None
> Changes in v2: None
>
> .../bindings/input/touchscreen/stmpe.txt | 52 ++++++++++++-------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++---
> 2 files changed, 41 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 127baa31a77a..1d3f84308142 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,24 +5,40 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time: ADC converstion time in number of clock. (0 -> 36 clocks, 1 ->
> - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
> - -> 144 clocks), recommended is 4.
> -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> - reference)
> -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
> -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
> - samples, 3 -> 8 samples)
> -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 ->
> - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
> - is 3
> -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 us, 3
> - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
> -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = Count of
> - the fractional part) recommended is 7
> -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA typical 35
> - mA max, 1 -> 50 mA typical 80 mA max)
> +- st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 144 clocks
> + 3 -> 64 clocks
Just make this a 1 column list
> +- st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> +- st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> +- st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +- st,ave-ctrl : Sample average control
> + 0 -> 1 sample
> + 1 -> 2 samples
> + 2 -> 4 samples
> + 3 -> 8 samples
> +- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
> + 0 -> 10 us 5 -> 5 ms
> + 1 -> 50 us 6 -> 10 ms
> + 2 -> 100 us 7 -> 50 ms
> + 3 -> 500 us
> + 4 -> 1 ms
> +- st,settling : Panel driver settling time (recommended is 2)
> + 0 -> 10 us 5 -> 10 ms
> + 1 -> 100 us 6 for 50 ms
> + 2 -> 500 us 7 -> 100 ms
> + 3 -> 1 ms
> + 4 -> 5 ms
> +- st,fraction-z : Length of the fractional part in z (recommended is 7)
> + (fraction-z ([0..7]) = Count of the fractional part)
> +- st,i-drive : current limit value of the touchscreen drivers
> + 0 -> 20 mA (typical 35mA max)
> + 1 -> 50 mA (typical 80 mA max)
>
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index c797c05cd3c2..a46e7177195d 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -4,15 +4,15 @@ STMPE is an MFD device which may expose the following inbuilt devices: gpio,
> keypad, touchscreen, adc, pwm, rotator.
>
> Required properties:
> - - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
> - - reg : I2C/SPI address of the device
> + - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
> + - reg : I2C/SPI address of the device
>
> Optional properties:
> - - interrupts : The interrupt outputs from the controller
> - - interrupt-controller : Marks the device node as an interrupt controller
> - - wakeup-source : Marks the input device as wakable
> - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - - irq-gpio : If present, which GPIO to use for event IRQ
> + - interrupts : The interrupt outputs from the controller
> + - interrupt-controller : Marks the device node as an interrupt controller
> + - wakeup-source : Marks the input device as wakable
> + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> + - irq-gpio : If present, which GPIO to use for event IRQ
>
> Example:
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: fixes incorrect error handling
From: Jiri Kosina @ 2018-12-17 14:05 UTC (permalink / raw)
To: Pan Bian; +Cc: Srinivas Pandruvada, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <1542847953-127599-1-git-send-email-bianpan2016@163.com>
On Thu, 22 Nov 2018, Pan Bian wrote:
> The memory chunk allocated by hid_allocate_device() should be released
> by hid_destroy_device(), not kfree().
>
> Fixes: 0b28cb4bcb1("HID: intel-ish-hid: ISH HID client driver")
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.c b/drivers/hid/intel-ish-hid/ishtp-hid.c
> index cd23903..e918d78 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid.c
> @@ -222,7 +222,7 @@ int ishtp_hid_probe(unsigned int cur_hid_dev,
> err_hid_device:
> kfree(hid_data);
> err_hid_data:
> - kfree(hid);
> + hid_destroy_device(hid);
> return rv;
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Benjamin Tissoires @ 2018-12-17 13:23 UTC (permalink / raw)
To: kernelrocks; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <20181216155319.GA17189@arks.localdomain>
On Sun, Dec 16, 2018 at 4:52 PM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
>
> The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> specific UsagePage 0xff31. In consequence, some multimedia keys such as
> brightness up and down are not working with hid-generic.
>
> This commit adds the T101HA dock into the supported device list of the
> hid-asus driver. It also prevents the dock's integrated touchpad to be
> bound with hid-asus given that it is already working fine with
> hid-multitouch.
>
> Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> ---
>
> Changes in v2:
> - use the report descriptor's application usage to identify the dock's
> touchpad instead of the usb interface id
Thanks for the quick respin.
Pushed into 4.21/hid-asus.
Cheers,
Benjamin
>
> drivers/hid/hid-asus.c | 8 ++++++++
> drivers/hid/hid-ids.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index ab8bd40a77ed..951bb17ae8b2 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define QUIRK_T100_KEYBOARD BIT(6)
> #define QUIRK_T100CHI BIT(7)
> #define QUIRK_G752_KEYBOARD BIT(8)
> +#define QUIRK_T101HA_DOCK BIT(9)
>
> #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> QUIRK_NO_INIT_REPORTS | \
> @@ -699,6 +700,11 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> + /* use hid-multitouch for T101HA touchpad */
> + if (id->driver_data & QUIRK_T101HA_DOCK &&
> + hdev->collection->usage == HID_GD_MOUSE)
> + return -ENODEV;
> +
> ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> if (ret) {
> hid_err(hdev, "Asus hw start failed: %d\n", ret);
> @@ -830,6 +836,8 @@ static const struct hid_device_id asus_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 4206428c0ba2..f1eee2778b70 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -184,6 +184,7 @@
> #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> --
> 2.20.0
>
^ permalink raw reply
* [PATCH v4] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Enric Balletbo i Serra @ 2018-12-17 9:54 UTC (permalink / raw)
To: linux-kernel
Cc: Alessandro Zummo, linux-pwm, linux-iio, Alexandre Belloni,
linux-i2c, groeck, kernel, linux-rtc, Chanwoo Choi, Benson Leung,
Sebastian Reichel, linux-input, Dmitry Torokhov, Jonathan Cameron,
Peter Meerwald-Stadler, devicetree, Thierry Reding, linux-pm,
MyungJoo Ham, Lee Jones, Hartmut Knaack, Rob Herring, Lars
There are multiple ChromeOS EC sub-drivers spread in different
subsystems, as all of them are related to the Chrome stuff add
Benson and myself as a maintainers for all these sub-drivers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Guenter Roeck <groeck@chromium.org>
---
Changes in v4:
- Remove the `for iio parts` from Jonathan's acked-by tag.
- Add more collected acks.
- Use two N patterns.
Changes in v3:
- Add collected acks
- Use a cros[-_]ec pattern instead of list all the files.
- Add Guenter as a reviewer.
Changes in v2:
- Fix typo in Benson email address.
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fa6e2ad90568..1e27b24e912e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3629,6 +3629,15 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
F: drivers/platform/chrome/
+CHROMEOS EC SUBDRIVERS
+M: Benson Leung <bleung@chromium.org>
+M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+R: Guenter Roeck <groeck@chromium.org>
+S: Maintained
+N: cros_ec
+N: cros-ec
+F: drivers/power/supply/cros_usbpd-charger.c
+
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: Brian Austin <brian.austin@cirrus.com>
M: Paul Handrigan <Paul.Handrigan@cirrus.com>
--
2.19.2
^ permalink raw reply related
* Re: Elantech SMBus support regression
From: Kai Heng Feng @ 2018-12-17 7:25 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJ+fshPj7xbJoBvK8uGrhfKCdFSmzicmmOyMJS0cdzAapQ@mail.gmail.com>
Hi,
> On Dec 12, 2018, at 22:25, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> Hi,
>
> sorry for the late reply. I was always meaning to fix this the proper
> way but couldn't dedicate a full day of work to go to the bottom of
> elan_i2c.
>
> Meanwhile, I am thinking at simply having a blacklist of devices that
> we know are not working well (P52, L480, L580 and P72).
>
> Could you get the value of /sys/bus/serio/devices/serio1/firmware_id
> from all of these laptops?
> I know the P52 is LEN2131, but I don't seem to find the other PNPIds.
These are feedbacks from the users:
L480:
cat /sys/bus/serio/devices/serio1/firmware_id
PNP: LEN2036 PNP0f13
P52:
"cat /sys/bus/serio/devices/serio1/firmware_id":
PNP: LEN2132 PNP0f13
So looks like it’s different to LEN2131.
Kai-Heng
>
> Cheers,
> Benjamin
>
> On Thu, Nov 22, 2018 at 5:22 AM Kai Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> Hi Benjamin,
>>
>> It appears the Elantech SMBus support breaks some users’ touchpad.
>>
>> Please have a look at [1] [2], thanks!
>>
>> [1] https://bugs.launchpad.net/bugs/1803600
>> [2] https://bugs.archlinux.org/task/59714
>>
>> Kai-Heng
^ permalink raw reply
* Re: [PATCH v5 3/3] Input: atmel_mxt_ts: Document optional voltage regulators
From: Sebastian Reichel @ 2018-12-16 22:41 UTC (permalink / raw)
To: Paweł Chmiel
Cc: nick, mark.rutland, devicetree, alexandre.belloni,
dmitry.torokhov, linux-kernel, robh+dt, linux-input,
linux-arm-kernel
In-Reply-To: <20181214151214.5391-4-pawel.mikolaj.chmiel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
Hi,
On Fri, Dec 14, 2018 at 04:12:14PM +0100, Paweł Chmiel wrote:
> Document new optional voltage regulators, which can be used
> to power down/up touchscreen.
>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> ---
> Changes from v1:
> - Added reviewed-by
> ---
> .../devicetree/bindings/input/atmel,maxtouch.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> index c88919480d37..17930ecadad3 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> @@ -31,6 +31,12 @@ Optional properties for main touchpad device:
>
> - reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
>
> +- avdd-supply: Analog power supply. It powers up the analog channel block
> + of the controller to detect the touches.
> +
> +- vdd-supply: Digital power supply. It powers up the digital block
> + of the controller to enable i2c communication.
> +
> Example:
>
> touch@4b {
> @@ -38,4 +44,6 @@ Example:
> reg = <0x4b>;
> interrupt-parent = <&gpio>;
> interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
> + avdd-supply = <&atsp_reg>;
> + vdd-supply = <&tsp_reg>;
> };
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Aleix Roca Nonell @ 2018-12-16 15:53 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, mbrugger, kernelrocks
The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
specific UsagePage 0xff31. In consequence, some multimedia keys such as
brightness up and down are not working with hid-generic.
This commit adds the T101HA dock into the supported device list of the
hid-asus driver. It also prevents the dock's integrated touchpad to be
bound with hid-asus given that it is already working fine with
hid-multitouch.
Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
---
Changes in v2:
- use the report descriptor's application usage to identify the dock's
touchpad instead of the usb interface id
drivers/hid/hid-asus.c | 8 ++++++++
drivers/hid/hid-ids.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index ab8bd40a77ed..951bb17ae8b2 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define QUIRK_T100_KEYBOARD BIT(6)
#define QUIRK_T100CHI BIT(7)
#define QUIRK_G752_KEYBOARD BIT(8)
+#define QUIRK_T101HA_DOCK BIT(9)
#define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
QUIRK_NO_INIT_REPORTS | \
@@ -699,6 +700,11 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
+ /* use hid-multitouch for T101HA touchpad */
+ if (id->driver_data & QUIRK_T101HA_DOCK &&
+ hdev->collection->usage == HID_GD_MOUSE)
+ return -ENODEV;
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "Asus hw start failed: %d\n", ret);
@@ -830,6 +836,8 @@ static const struct hid_device_id asus_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+ USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4206428c0ba2..f1eee2778b70 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -184,6 +184,7 @@
#define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
#define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
#define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
+#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
#define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
#define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
#define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
--
2.20.0
^ permalink raw reply related
* Re: [PATCH v4 6/8] iio: adc: add STMPE ADC devicetree bindings
From: Jonathan Cameron @ 2018-12-16 12:28 UTC (permalink / raw)
To: Philippe Schenker
Cc: marcel.ziswiler, stefan, thierry.reding, Max Krummenacher,
Philippe Schenker, devicetree, linux-iio, Hartmut Knaack,
Alexandre Torgue, linux-input, linux-kernel, Rob Herring,
Dmitry Torokhov, Lee Jones, Maxime Coquelin, Mark Rutland,
Peter Meerwald-Stadler, linux-stm32, linux-arm-kernel,
Lars-Peter Clausen
In-Reply-To: <20181212130649.15146-6-dev@pschenker.ch>
On Wed, 12 Dec 2018 14:06:47 +0100
Philippe Schenker <dev@pschenker.ch> wrote:
> From: Stefan Agner <stefan@agner.ch>
>
> This adds the devicetree bindings for the STMPE ADC. And corrects a
> typo in st,sample-time it is rather "6 -> 124 clocks" according
> to the datasheet and not 144.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
This still conflates a couple of different things but we can argue
about patch separation for ever so never mind.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>
> Changes in v4:
> - Put reformatting in a separate precursor patch.
>
> Changes in v3:
> - Reformatted documentation for touchscreen to use tabs and have a better
> overview of the settings.
> - Added note which adc-settings will take precedence.
> - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
> in the datasheet.
>
> Changes in v2:
> - Moved the bindings for ADC to the overlying mfd.
> - Reformatted for better readability
>
> .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++++++++++++
> .../bindings/input/touchscreen/stmpe.txt | 32 +++++++++----------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++++++++
> 3 files changed, 51 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> new file mode 100644
> index 000000000000..480e66422625
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> @@ -0,0 +1,21 @@
> +STMPE ADC driver
> +----------------
> +
> +Required properties:
> + - compatible: "st,stmpe-adc"
> +
> +Optional properties:
> +Note that the ADC is shared with the STMPE touchscreen. ADC related settings
> +have to be done in the mfd.
> +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> + requestable due to different usage (e.g. touch)
> +
> +Node name must be stmpe_adc and should be child node of stmpe node to
> +which it belongs.
> +
> +Example:
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> + };
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 1d3f84308142..8e2b240882fa 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,18 +5,6 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time : ADC conversion time in number of clock.
> - 0 -> 36 clocks 4 -> 80 clocks (recommended)
> - 1 -> 44 clocks 5 -> 96 clocks
> - 2 -> 56 clocks 6 -> 144 clocks
> - 3 -> 64 clocks
> -- st,mod-12b : ADC Bit mode
> - 0 -> 10bit ADC 1 -> 12bit ADC
> -- st,ref-sel : ADC reference source
> - 0 -> internal 1 -> external
> -- st,adc-freq : ADC Clock speed
> - 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> - 1 -> 3.25 MHz
> - st,ave-ctrl : Sample average control
> 0 -> 1 sample
> 1 -> 2 samples
> @@ -40,17 +28,29 @@ Optional properties:
> 0 -> 20 mA (typical 35mA max)
> 1 -> 50 mA (typical 80 mA max)
>
> +Optional properties common with MFD (deprecated):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
>
> +Note that common ADC settings of stmpe_touchscreen will take precedence.
> +
> Example:
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - st,sample-time = <4>;
> - st,mod-12b = <1>;
> - st,ref-sel = <0>;
> - st,adc-freq = <1>;
> st,ave-ctrl = <1>;
> st,touch-det-delay = <2>;
> st,settling = <2>;
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index a46e7177195d..d4408a417193 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -14,6 +14,20 @@ Optional properties:
> - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - irq-gpio : If present, which GPIO to use for event IRQ
>
> +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Example:
>
> stmpe1601: stmpe1601@40 {
^ permalink raw reply
* [PATCH v3 4/4] Input: goodix - Add GT5663 CTP support
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum has 16-bit
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 7371f6946098..735ab8e246b6 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -218,6 +218,7 @@ static const struct goodix_chip_data *goodix_get_chip_data(u16 id)
{
switch (id) {
case 1151:
+ case 5663:
return >1x_chip_data;
case 911:
@@ -965,6 +966,7 @@ MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
#ifdef CONFIG_OF
static const struct of_device_id goodix_of_match[] = {
{ .compatible = "goodix,gt1151" },
+ { .compatible = "goodix,gt5663" },
{ .compatible = "goodix,gt911" },
{ .compatible = "goodix,gt9110" },
{ .compatible = "goodix,gt912" },
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index c4622c983e08..59c89276e6bb 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller
Required properties:
- compatible : Should be "goodix,gt1151"
+ or "goodix,gt5663"
or "goodix,gt911"
or "goodix,gt9110"
or "goodix,gt912"
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 2/4] Input: goodix - Add AVDD28-supply regulator support
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/input/touchscreen/goodix.c | 33 +++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index f2d9c2c41885..7371f6946098 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -27,6 +27,7 @@
#include <linux/delay.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/of.h>
@@ -47,6 +48,7 @@ struct goodix_ts_data {
struct touchscreen_properties prop;
unsigned int max_touch_num;
unsigned int int_trigger_type;
+ struct regulator *avdd28;
struct gpio_desc *gpiod_int;
struct gpio_desc *gpiod_rst;
u16 id;
@@ -786,25 +788,41 @@ static int goodix_ts_probe(struct i2c_client *client,
if (error)
return error;
+ ts->avdd28 = devm_regulator_get(&client->dev, "AVDD28");
+ if (IS_ERR(ts->avdd28)) {
+ error = PTR_ERR(ts->avdd28);
+ if (error != -EPROBE_DEFER)
+ dev_err(&client->dev,
+ "Failed to get AVDD28 regulator: %d\n", error);
+ return error;
+ }
+
+ /* power the controller */
+ error = regulator_enable(ts->avdd28);
+ if (error) {
+ dev_err(&client->dev, "Controller fail to enable AVDD28\n");
+ return error;
+ }
+
if (ts->gpiod_int && ts->gpiod_rst) {
/* reset the controller */
error = goodix_reset(ts);
if (error) {
dev_err(&client->dev, "Controller reset failed.\n");
- return error;
+ goto error;
}
}
error = goodix_i2c_test(client);
if (error) {
dev_err(&client->dev, "I2C communication failure: %d\n", error);
- return error;
+ goto error;
}
error = goodix_read_version(ts);
if (error) {
dev_err(&client->dev, "Read version failed.\n");
- return error;
+ goto error;
}
ts->chip = goodix_get_chip_data(ts->id);
@@ -823,23 +841,28 @@ static int goodix_ts_probe(struct i2c_client *client,
dev_err(&client->dev,
"Failed to invoke firmware loader: %d\n",
error);
- return error;
+ goto error;
}
return 0;
} else {
error = goodix_configure_dev(ts);
if (error)
- return error;
+ goto error;
}
return 0;
+
+error:
+ regulator_disable(ts->avdd28);
+ return error;
}
static int goodix_ts_remove(struct i2c_client *client)
{
struct goodix_ts_data *ts = i2c_get_clientdata(client);
+ regulator_disable(ts->avdd28);
if (ts->gpiod_int && ts->gpiod_rst)
wait_for_completion(&ts->firmware_loading_complete);
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: input: touchscreen: goodix: Document AVDD28-supply property
From: Jagan Teki @ 2018-12-15 15:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the require boards
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index f7e95c52f3c7..c4622c983e08 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -23,6 +23,7 @@ Optional properties:
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
(swapping is done after inverting the axis)
+ - AVDD28-supply : Analog power supply regulator on AVDD28 pin
Example:
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 0/4] input: touchscreen: Add goodix GT5553 CTP support
From: Jagan Teki @ 2018-12-15 15:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
This patchset support goodix GT5553 CTP.
Changes for v3:
- add cover-letter
- s/ADVV28/AVDD28 on commit head
- fix few typo
Changes for v2:
- Rename vcc-supply with AVDD28-supply
- disable regulator in remove
- fix to setup regulator in probe code
- add chipdata
- drop example node in dt-bindings
Jagan Teki (4):
dt-bindings: input: touchscreen: goodix: Document AVDD28-supply
property
Input: goodix - Add AVDD28-supply regulator support
dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
Input: goodix - Add GT5663 CTP support
.../bindings/input/touchscreen/goodix.txt | 2 ++
drivers/input/touchscreen/goodix.c | 35 ++++++++++++++++---
2 files changed, 32 insertions(+), 5 deletions(-)
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Clément VUCHENER @ 2018-12-15 14:45 UTC (permalink / raw)
To: Harry Cutts
Cc: Peter Hutterer, linux-input, Dmitry Torokhov, Jiri Kosina,
torvalds, Nestor Lopez Casado, lkml, Benjamin Tissoires
In-Reply-To: <CA+jURcuhBRYiqFYHDgK8dDycrPgvzkujTRZfnmYraiHvwE+e6w@mail.gmail.com>
Le ven. 14 déc. 2018 à 19:37, Harry Cutts <hcutts@chromium.org> a écrit :
>
> Hi Clement,
>
> On Fri, 14 Dec 2018 at 05:47, Clément VUCHENER
> <clement.vuchener@gmail.com> wrote:
> > Hi, The G500s (and the G500 too, I think) does support the "scrolling
> > acceleration" bit. If I set it, I get around 8 events for each wheel
> > "click", this is what this driver expects, right? If I understood
> > correctly, I should try this patch with the
> > HIDPP_QUIRK_HI_RES_SCROLL_1P0 quirk set for my mouse.
>
> Thanks for the info! Yes, that should work.
Well, it is not that simple. I get "Device not connected" errors for
both interfaces of the mouse.
logitech-hidpp-device 0003:046D:C24E.000E: Device not connected
logitech-hidpp-device 0003:046D:C24E.000F: Device not connected
Here is the usbmon trace when connecting a G500s:
0cd42cc0 3.313741 C Ii:3:001:1 0:2048 1 =
04
0cd42cc0 3.313750 S Ii:3:001:1 -:2048 4 <
17b49a80 3.313764 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.313775 C Ci:3:001:0 0 4 =
01010100
17b49a80 3.313781 S Co:3:001:0 s 23 01 0010 0002 0000 0
17b49a80 3.313789 C Co:3:001:0 0 0
17b49a80 3.313792 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.313797 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.340415 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.340438 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.367434 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.367448 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.394434 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.394449 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.421416 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.421431 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.421690 S Co:3:001:0 s 23 03 0004 0002 0000 0
17b49a80 3.421707 C Co:3:001:0 0 0
17b49a80 3.483421 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.483436 C Ci:3:001:0 0 4 =
11010000
17b499c0 3.545429 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.545442 C Ci:3:001:0 0 4 =
03011000
17b499c0 3.545448 S Co:3:001:0 s 23 01 0014 0002 0000 0
17b499c0 3.545456 C Co:3:001:0 0 0
17b499c0 3.597659 S Ci:3:000:0 s 80 06 0100 0000 0040 64 <
17b499c0 3.597851 C Ci:3:000:0 0 8 =
12010002 00000008
17b499c0 3.597870 S Co:3:001:0 s 23 03 0004 0002 0000 0
17b499c0 3.597884 C Co:3:001:0 0 0
17b499c0 3.659419 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.659434 C Ci:3:001:0 0 4 =
11010000
17b499c0 3.721421 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.721435 C Ci:3:001:0 0 4 =
03011000
17b499c0 3.721442 S Co:3:001:0 s 23 01 0014 0002 0000 0
17b499c0 3.721451 C Co:3:001:0 0 0
17b49600 3.788420 S Ci:3:007:0 s 80 06 0100 0000 0012 18 <
17b49600 3.788897 C Ci:3:007:0 0 18 =
12010002 00000008 6d044ec2 01840102 0301
. . . . . . . . m . N . . . . . . .
17b49600 3.788920 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789057 C Ci:3:007:0 -32 0
17b49600 3.789092 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789438 C Ci:3:007:0 -32 0
17b49600 3.789459 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789827 C Ci:3:007:0 -32 0
17b49600 3.789850 S Ci:3:007:0 s 80 06 0200 0000 0009 9 <
17b49600 3.790272 C Ci:3:007:0 0 9 =
09023b00 020104a0 31
. . ; . . . . . 1
17b49600 3.790285 S Ci:3:007:0 s 80 06 0200 0000 003b 59 <
17b49600 3.791004 C Ci:3:007:0 0 59 =
09023b00 020104a0 31090400 00010301 02000921 11010001 22430007 05810308
. . ; . . . . . 1 . . . . . . . . . . ! . . . . " C . . . . . .
17b49600 3.791021 S Ci:3:007:0 s 80 06 0300 0000 00ff 255 <
17b49600 3.791203 C Ci:3:007:0 0 4 =
04030904
17b49600 3.791212 S Ci:3:007:0 s 80 06 0302 0409 00ff 255 <
17b49600 3.791829 C Ci:3:007:0 0 50 =
32034700 35003000 30007300 20004c00 61007300 65007200 20004700 61006d00
2 . G . 5 . 0 . 0 . s . . L . a . s . e . r . . G . a . m .
17b49600 3.791844 S Ci:3:007:0 s 80 06 0301 0409 00ff 255 <
17b49600 3.792141 C Ci:3:007:0 0 18 =
12034c00 6f006700 69007400 65006300 6800
. . L . o . g . i . t . e . c . h .
17b49600 3.792154 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49600 3.792563 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49300 3.795944 S Co:3:007:0 s 00 09 0001 0000 0000 0
17b49300 3.795998 C Co:3:007:0 0 0
17b49300 3.796025 S Ci:3:007:0 s 80 06 0304 0409 00ff 255 <
17b49300 3.796392 C Ci:3:007:0 0 26 =
1a035500 38003400 2e003000 31005f00 42003000 30003000 3900
. . U . 8 . 4 . . . 0 . 1 . _ . B . 0 . 0 . 0 . 9 .
17b49900 3.796473 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49900 3.796883 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49900 3.796914 S Co:3:007:0 s 21 0a 0000 0000 0000 0
17b49900 3.797027 C Co:3:007:0 -32 0
17b49900 3.797056 S Ci:3:007:0 s 81 06 2200 0000 0043 67 <
17b49900 3.798055 C Ci:3:007:0 0 67 =
05010902 a1010901 a1000509 19012910 15002501 95107501 81020501 16018026
. . . . . . . . . . . . . . ) . . . % . . . u . . . . . . . . &
17b49840 3.798350 S Co:3:007:0 s 21 09 0211 0000 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
17b49840 3.798500 C Co:3:007:0 0 20 >
17b49240 9.289560 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49240 9.289999 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49240 9.290040 S Co:3:007:0 s 21 0a 0000 0001 0000 0
17b49240 9.290145 C Co:3:007:0 -32 0
17b49240 9.290155 S Ci:3:007:0 s 81 06 2200 0001 007a 122 <
17b49240 9.291756 C Ci:3:007:0 0 122 =
05010906 a1018501 050719e0 29e71500 25017501 95088102 95057508 150026a4
. . . . . . . . . . . . ) . . . % . u . . . . . . . u . . . & .
17b49c00 9.292167 S Co:3:007:0 s 21 09 0211 0001 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
17b49c00 9.292628 C Co:3:007:0 0 20 >
It looks like the mouse is not responding to the
root_get_protocol_version packet. I don't know why, but even if it
did, it would not work correctly. The HID++ reports will only work
with one of the interfaces, the other should be ignored by the driver
instead of being disabled because it failed to respond to the HID++
report. The G500s and G500 HID++ interface also use the device index 0
instead of 0xff.
For comparison, if I use my distribution kernel
(4.19.7-200.fc28.x86_64) and send reports from user-space (using
hidraw) instead of for-4.21/highres-wheel kernel. I get this kind of
trace:
592193c0 0.253975 S Co:3:003:0 s 21 09 0211 0001 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
592193c0 0.254426 C Co:3:003:0 0 20 >
9ee5ff00 0.255859 C Ii:3:003:2 0:1 7 =
10ff8f00 110800
9ee5ff00 0.255867 S Ii:3:003:2 -:1 20 <
592193c0 11.116794 S Co:3:003:0 s 21 09 0211 0001 0014 20 =
11000011 00000000 00000000 00000000 00000000
592193c0 11.117258 C Co:3:003:0 0 20 >
9ee5ff00 11.118023 C Ii:3:003:2 0:1 7 =
10008f00 110100
9ee5ff00 11.118033 S Ii:3:003:2 -:1 20 <
When using device index 0xff the mouse responds with a
ERR_UNKNOWN_DEVICE (0x08) error, when using device index 0 it responds
ERR_INVALID_SUBID (0x01), the expected error for a HID++1.0 device.
Here is the diff from the for-4.21/highres-wheel branch, I only added
the devices to the device list with the required quirk.
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ed35c9a9a110..a1c431e7841c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -724,6 +724,7 @@
#define USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS 0xc24d
#define USB_DEVICE_ID_LOGITECH_MOUSE_C01A 0xc01a
#define USB_DEVICE_ID_LOGITECH_MOUSE_C05A 0xc05a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_G500 0xc068
#define USB_DEVICE_ID_LOGITECH_MOUSE_C06A 0xc06a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD 0xc20a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
@@ -731,6 +732,7 @@
#define USB_DEVICE_ID_LOGITECH_DUAL_ACTION 0xc216
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2 0xc218
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2_2 0xc219
+#define USB_DEVICE_ID_LOGITECH_MOUSE_G500S 0xc24e
#define USB_DEVICE_ID_LOGITECH_G29_WHEEL 0xc24f
#define USB_DEVICE_ID_LOGITECH_G920_WHEEL 0xc262
#define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 15ed6177a7a3..b9b34ce455a4 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3416,6 +3416,10 @@ static const struct hid_device_id hidpp_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 |
HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_G500),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_G500S),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
{}
};
^ permalink raw reply related
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-15 10:29 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215101221.GA23879@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
On Sat 2018-12-15 11:12:21, Vojtech Pavlik wrote:
> On Sat, Dec 15, 2018 at 10:47:22AM +0100, Pavel Machek wrote:
>
> > > > b) would it be acceptable if done properly? (cmd line option to
> > > > enable, avoiding duplicate/wrong events?)
> > >
> > > Well, for one, you shouldn't be using a timer, all the debouncing can be
> > > done by math on the event timestamps.
> >
> > Not... really, right? You need to send an release some time after
> > button indicates release if bounce did not happen. It is similar to
> > autorepeat needing a timer.
>
> You can send the first release and ignore all presses and releases in a
> time window after that.
I could, and it would work for glitches on release, but that would do
very bad things if switch glitched on press, right?
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX " ->
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX " ... ok
"XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..." ->
"XX ..." ... bad idea. [Maybe could be
detected with "XX " being unusually short?]
But I believe I see
"XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX" on X220 device, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Vojtech Pavlik @ 2018-12-15 10:12 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215094722.GA5804@amd>
On Sat, Dec 15, 2018 at 10:47:22AM +0100, Pavel Machek wrote:
> > > b) would it be acceptable if done properly? (cmd line option to
> > > enable, avoiding duplicate/wrong events?)
> >
> > Well, for one, you shouldn't be using a timer, all the debouncing can be
> > done by math on the event timestamps.
>
> Not... really, right? You need to send an release some time after
> button indicates release if bounce did not happen. It is similar to
> autorepeat needing a timer.
You can send the first release and ignore all presses and releases in a
time window after that.
> Let me gain some experience with the patch. I don't think hardware
> does as heavy debouncing as you describe.
Microswitches vibrate significantly when clicked. Without hardware
debouncing, you'd have many clicks instead of one even on a new mouse.
--
Vojtech Pavlik
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-15 9:47 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215085510.GB12930@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Hi!
> > Patch is obviously not ready; but:
> >
> > a) would it be useful to people
>
> Probably not.
>
> Mice already do internal software/hardware debouncing on switches. If you
> see duplicate clicks making it all the way to the kernel driver, something
> is very wrong with the switch, to the point where it'll soon fail
> completely.
It seems mice normally survive 2 years under my use. This one has left
button repaired and middle button failing... If debouncing gives it
one more year, it will be success...
> > b) would it be acceptable if done properly? (cmd line option to
> > enable, avoiding duplicate/wrong events?)
>
> Well, for one, you shouldn't be using a timer, all the debouncing can be
> done by math on the event timestamps.
Not... really, right? You need to send an release some time after
button indicates release if bounce did not happen. It is similar to
autorepeat needing a timer.
Let me gain some experience with the patch. I don't think hardware
does as heavy debouncing as you describe.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ 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