hid-lenovo-tpkbd unknown key/button events
My Lenovo ThinkPad Keyboard with TrackPoint reports two keys/buttons events which have no names in input.h. Event 282 (0x11A) is generated on the pointer devices via Fn-F9: Event: time 1402899841.080255, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90018 Event: time 1402899841.080255, type 1 (EV_KEY), code 282 (?), value 1 Event: time 1402899841.080255, -- SYN_REPORT Event: time 1402899841.176247, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90018 Event: time 1402899841.176247, type 1 (EV_KEY), code 282 (?), value 0 Event: time 1402899841.176247, -- SYN_REPORT I have not found how to generate event 286 (0x11E). Lenovo documents Fn-F9 on: http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-42883 as ThinkPad EasyEject Utility. Are there any other devices known to generate codes in the 0x118-0x11F range? Woulditbe beneficial to come up with names for them? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
On Sun, Jun 15, 2014 at 05:59:40PM +0300, Janne Kanniainen wrote: Ok, so you decided to continue setting mode on every LED brightness update. That should be fine, but you never answered my question about whether it is necessary? I decided to do it that way because official driver did it as well. I can check if it is necessary. Ok, I checked this one and every time you update LEDs brightness you will need to update mode also. Ok, great. Then we know. Johan -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
On Sun, Jun 15, 2014 at 02:23:25AM +0300, Janne Kanniainen wrote: Hi! Hi. --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r @@ -0,0 +1,10 @@ +What:/sys/class/hidraw/hidraw/device/state +Date:Jun 2014 +KernelVersion: 3.15 +Contact: Janne Kanniainen janne.kanniai...@gmail.com +Description: + Set the mode of LEDs + + 0 - normal + 1 - audio + 2 - breathing THat's some strange interface. Don't we normally use led triggers for this? I can implement it that way, if you all think that it is correct way. What do Jiri and Johan thinks of it? And the mode of the LED should really be in /sys/class/leds, not in hidraw somewhere... The problem is that all panels can only be in one mode at the time. For example front panel can't be in breathing mode while side panel is in normal mode. As Janne explained above, it's really an attribute of the parent device and not the individual LEDs. The latter could still use the software timer trigger to blink independently. Johan -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] elantech: Add support for trackpoint found on some v3 models
Hi
On Fri, Jun 13, 2014 at 11:21 PM, Ulrik De Bie ulrik.debie...@e2big.org wrote:
Some elantech v3 touchpad equipped laptops also have a trackpoint, before
this commit, these give sync errors. With this patch, the trackpoint is
provided as another input device: 'Elantech PS/2 TrackPoint'
The patch will also output messages that do not follow the expected pattern.
In the mean time I've seen 2 unknown packets occasionally:
0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00
0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00
I don't know what those are for, but they can be safely ignored.
Currently all packets that are not known to v3 touchpad and where
packet[3] (the fourth byte) lowest nibble is 6 are now recognized as
PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint.
This has been verified to work on a laptop Lenovo L530 where the
touchpad/trackpoint combined identify themselves as:
psmouse serio1: elantech: assuming hardware version 3 (with firmware version
0x350f02)
psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15,
0x0c.
Reviewed-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Ulrik De Bie ulrik.debie...@e2big.org
---
drivers/input/mouse/elantech.c | 119
+++--
drivers/input/mouse/elantech.h | 3 ++
2 files changed, 118 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index ee2a04d..0eb185b 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -403,6 +403,71 @@ static void elantech_report_absolute_v2(struct psmouse
*psmouse)
input_sync(dev);
}
+static void elantech_report_trackpoint(struct psmouse *psmouse,
+ int packet_type)
+{
+ /*
+* byte 0: 0 0 ~sx ~sy 0 M R L
+* byte 1: sx 0 0 0 0 0 0 0
+* byte 2: sy 0 0 0 0 0 0 0
+* byte 3: 0 0 sy sx 0 1 1 0
+* byte 4: x7 x6 x5 x4 x3 x2 x1 x0
+* byte 5: y7 y6 y5 y4 y3 y2 y1 y0
+*
+* x and y are written in two's complement spread
+* over 9 bits with sx/sy the relative top bit and
+* x7..x0 and y7..y0 the lower bits.
+* The sign of y is opposite to what the input driver
+* expects for a relative movement
+*/
+
+ struct elantech_data *etd = psmouse-private;
+ struct input_dev *tp_dev = etd-tp_dev;
+ unsigned char *packet = psmouse-packet;
+ int x, y;
+ u32 t;
+
+ if (!tp_dev) {
+ static bool __section(.data.unlikely) __warned;
+
+ if (!__warned) {
+ __warned = true;
+ psmouse_err(psmouse, Unexpected trackpoint
message\n);
+ if (etd-debug == 1)
+ elantech_packet_dump(psmouse);
+ }
+
+ return;
+ }
+
+ input_report_key(tp_dev, BTN_LEFT, packet[0] 0x01);
+ input_report_key(tp_dev, BTN_RIGHT, packet[0] 0x02);
+ input_report_key(tp_dev, BTN_MIDDLE, packet[0] 0x04);
+
+ x = ((packet[1] 0x80) ? 0U : 0xFF00U) | packet[4];
+ y = -(int)(((packet[2] 0x80) ? 0U : 0xFF00U) | packet[5]);
+
+ input_report_rel(tp_dev, REL_X, x);
+ input_report_rel(tp_dev, REL_Y, y);
+
+ t = (((u32)packet[0] 0xF8) 24) | ((u32)packet[1] 16)
+ | (u32)packet[2] 8 | (u32)packet[3];
+ switch (t) {
+ case 0x00808036U:
+ case 0x10008026U:
+ case 0x20800016U:
+ case 0x3006U:
+ break;
+ default:
+ /* Dump unexpected packet sequences if debug=1 (default) */
+ if (etd-debug == 1)
+ elantech_packet_dump(psmouse);
+ break;
+ }
+
+ input_sync(tp_dev);
+}
+
/*
* Interpret complete data packets and report absolute mode input events for
* hardware version 3. (12 byte packets for two fingers)
@@ -715,6 +780,8 @@ static int elantech_packet_check_v3(struct psmouse
*psmouse)
if ((packet[0] 0x0c) == 0x0c (packet[3] 0xce) == 0x0c)
return PACKET_V3_TAIL;
+ if ((packet[3] 0x0f) == 0x06)
+ return PACKET_TRACKPOINT;
}
return PACKET_UNKNOWN;
@@ -798,7 +865,10 @@ static psmouse_ret_t elantech_process_byte(struct
psmouse *psmouse)
if (packet_type == PACKET_UNKNOWN)
return PSMOUSE_BAD_DATA;
- elantech_report_absolute_v3(psmouse, packet_type);
+ if (packet_type == PACKET_TRACKPOINT)
+ elantech_report_trackpoint(psmouse, packet_type);
+ else
+ elantech_report_absolute_v3(psmouse, packet_type);
Re: [PATCH v3 2/2] elantech: Call psmouse_reset when elantech probe fails
Hi On Fri, Jun 13, 2014 at 11:21 PM, Ulrik De Bie ulrik.debie...@e2big.org wrote: Signed-off-by: Ulrik De Bie ulrik.debie...@e2big.org This patch lacks _any_ explanation why this is done. Please always write commit-messages! It is totally unclear from the patch description why the device is reset. Thanks David --- drivers/input/mouse/elantech.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c index 0eb185b..fa150d9 100644 --- a/drivers/input/mouse/elantech.c +++ b/drivers/input/mouse/elantech.c @@ -1617,6 +1617,7 @@ int elantech_init(struct psmouse *psmouse) sysfs_remove_group(psmouse-ps2dev.serio-dev.kobj, elantech_attr_group); init_fail: + psmouse_reset(psmouse); kfree(etd); return error; } -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/6] input: touchscreen: imx25 tcq driver
From: Markus Pargmann m...@pengutronix.de
This is a driver for the imx25 ADC/TSC module. It controls the
touchscreen conversion queue and creates a touchscreen input device.
The driver currently only supports 4 wire touchscreens. The driver uses
a simple conversion queue of precharge, touch detection, X measurement,
Y measurement, precharge and another touch detection.
This driver uses the regmap from the parent to setup some touch specific
settings in the core driver and setup a idle configuration with touch
detection.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
---
Changelog v2-v3:
- Fixed the 'Senitel' typo.
- Fixed input_report_key to report 1 for BTN_TOUCH events.
- Removed useless explicit casts.
- Also disable clock when devm_request_threaded_irq failed.
---
.../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29 +
drivers/input/touchscreen/Kconfig |6 +
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/fsl-imx25-tcq.c | 575
4 files changed, 611 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
new file mode 100644
index 000..4214a99
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
@@ -0,0 +1,29 @@
+Freescale mx25 TS conversion queue module
+
+mx25 touchscreen conversion queue module which controls the ADC unit of the
+mx25 for attached touchscreens.
+
+Required properties:
+ - compatible: Should be fsl,imx25-tcq.
+ - reg: Memory range of the device.
+ - interrupts: Should be the interrupt number associated with this module
within
+ the tscadc unit (0).
+ - interrupt-parent: Should be a phandle to the tscadc unit.
+ - fsl,wires: Should be '4' or '5'
+
+Optional properties:
+ - fsl,pen-debounce: Pen debounce time.
+ - fsl,pen-threshold: Pen-down threshold for the touchscreen.
+ - fsl,settling-time: Settling time in nanoseconds.
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 0;
+ fsl,wires = 4;
+ };
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index a23a94b..a2290b9 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -699,6 +699,12 @@ config TOUCHSCREEN_USB_COMPOSITE
To compile this driver as a module, choose M here: the
module will be called usbtouchscreen.
+config TOUCHSCREEN_MX25
+ tristate Freescale i.MX25 touchscreen input driver
+ depends on MFD_MX25_TSADC
+ help
+ Enable support for touchscreen connected to your i.MX25.
+
config TOUCHSCREEN_MC13783
tristate Freescale MC13783 touchscreen input driver
depends on MFD_MC13XXX
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 126479d..537d591 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= intel-mid-touch.o
obj-$(CONFIG_TOUCHSCREEN_LPC32XX) += lpc32xx_ts.o
obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
+obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
obj-$(CONFIG_TOUCHSCREEN_MC13783) += mc13783_ts.o
obj-$(CONFIG_TOUCHSCREEN_MCS5000) += mcs5000_ts.o
obj-$(CONFIG_TOUCHSCREEN_MIGOR)+= migor_ts.o
diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c
b/drivers/input/touchscreen/fsl-imx25-tcq.c
new file mode 100644
index 000..8c5e2e7
--- /dev/null
+++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
@@ -0,0 +1,575 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ * Based on driver from 2011:
+ * Juergen Beisert, Pengutronix ker...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
+ * connected to the imx25 ADC.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/mfd/imx25-tsadc.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
[PATCH v3 6/6] ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC support.
Signed-off-by: Denis Carikli de...@eukrea.com --- Changelog v2-v3: - Added ADC support, splitting it would be overkill. --- arch/arm/configs/imx_v4_v5_defconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig index 397f43c..580c367 100644 --- a/arch/arm/configs/imx_v4_v5_defconfig +++ b/arch/arm/configs/imx_v4_v5_defconfig @@ -98,6 +98,7 @@ CONFIG_KEYBOARD_IMX=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=m +CONFIG_TOUCHSCREEN_MX25=y CONFIG_TOUCHSCREEN_MC13783=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=m @@ -118,6 +119,7 @@ CONFIG_HWMON=m CONFIG_SENSORS_MC13783_ADC=m CONFIG_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_MFD_MX25_TSADC=y CONFIG_MFD_MC13XXX_SPI=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -184,6 +186,8 @@ CONFIG_DMADEVICES=y CONFIG_IMX_SDMA=y CONFIG_IMX_DMA=y # CONFIG_IOMMU_SUPPORT is not set +CONFIG_IIO=y +CONFIG_FSL_MX25_ADC=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/6] iio: adc: fsl,imx25-gcq driver
From: Markus Pargmann m...@pengutronix.de
This is a conversion queue driver for the mx25 SoC. It uses the central
ADC which is used by two seperate independent queues. This driver
prepares different conversion configurations for each possible input.
For a conversion it creates a conversionqueue of one item with the
correct configuration for the chosen channel. It then executes the queue
once and disables the conversion queue afterwards.
The reference voltages are configurable through devicetree subnodes,
depending on the connections of the ADC inputs.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
---
Changelog v2-v3:
- Fixed compilation: I forgott to tell that this IIO patch was untested
in the previous cover letter. Now it is tested at runtime:
I left the touchscreen connected but I configured the TSC as an ADC
instead, set the refp to internal reference, and the refn to ngnd_adc(3)
for the first 4 channels(xp,yp,xn,yn) and observed the values changing
while touching the resistive 4-wire touchscreen.
- MX25_IIO_CHAN now became MX25_GCQ_CHAN and its .address is now gone
and the code using it adapted.
- The instances of struct iio_dev were renamed from idev to indio_dev.
- regmap_read return value is now checked in mx25_gcq_read_raw.
- Comparisons with MX25_NUM_CFGS are now fixed
- Cosmetics fix in a multiline comment.
---
.../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 54
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/fsl-imx25-gcq.c| 342
4 files changed, 404 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
new file mode 100644
index 000..333fc55
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
@@ -0,0 +1,54 @@
+Freescale i.MX25 ADC GCQ device
+
+This is a generic conversion queue device that can convert any of the analog
+inputs using the ADC unit of the i.MX25.
+
+Required properties:
+ - compatible: Should be fsl,imx25-gcq.
+ - reg: Should be the register range of the module.
+ - interrupts: Should be the interrupt number of the module. Typically this is
1.
+ - interrupt-parent: phandle to the tsadc module of the i.MX25.
+ - #address-cells: Should be 1 (setting for the subnodes)
+ - #size-cells: Should be 0 (setting for the subnodes)
+
+Optionally you can define subnodes which define the positive and negative
+reference voltage for one of the analog inputs.
+
+Required properties for subnodes:
+ - reg: Should be the number of the analog input.
+ 0: xp
+ 1: yp
+ 2: xn
+ 3: yn
+ 4: wiper
+ 5: inaux0
+ 6: inaux1
+ 7: inaux2
+ - fsl,adc-refp: Positive reference input
+ 0: yp
+ 1: xp
+ 2: External reference
+ 3: Internal reference
+ - fsl,adc-refn: Negative reference input
+ 0: xn
+ 1: yn
+ 2: ngnd_adc
+ 3: ngnd_adc
+
+
+Example:
+
+ adc: adc@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ inaux@5 {
+ reg = 5;
+ fsl,adc-refp = 3;
+ fsl,adc-refn = 3;
+ };
+ };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a80d236..58efb8d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -125,6 +125,13 @@ config EXYNOS_ADC
of SoCs for drivers such as the touchscreen and hwmon to use to share
this resource.
+config FSL_MX25_ADC
+ tristate Freescale MX25 ADC driver
+ depends on MFD_MX25_TSADC
+ help
+ Generic Conversion Queue driver used for general purpose ADC in the
+ MX25. This driver supports single measurements using the MX25 ADC.
+
config LP8788_ADC
tristate LP8788 ADC driver
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9d60f2d..2767fd6 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
new file mode 100644
index 000..685cac5
--- /dev/null
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -0,0 +1,342 @@
+/*
+ *
[PATCH v3 1/6] mfd: fsl imx25 Touchscreen ADC driver
From: Markus Pargmann m...@pengutronix.de
This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.
This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
---
Changelog v2-v3:
- None
---
.../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |2 +
drivers/mfd/fsl-imx25-tsadc.c | 232
include/linux/mfd/imx25-tsadc.h| 138
5 files changed, 427 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
create mode 100644 include/linux/mfd/imx25-tsadc.h
diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
new file mode 100644
index 000..a857af0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
@@ -0,0 +1,46 @@
+Freescale mx25 ADC/TSC multifunction device
+
+This device combines two general purpose conversion queues one used for general
+ADC and the other used for touchscreens.
+
+Required properties:
+ - compatible: Should be fsl,imx25-tsadc.
+ - reg: Memory range of the device.
+ - interrupts: Interrupt for this device as described in
+ interrupts/interrupts.txt
+ - clocks: An 'ipg' clock defined as described in clocks/clock.txt
+ - interrupt-controller: This device is an interrupt controller. It controls
+ the interrupts of both conversion queues.
+ - #interrupt-cells: Should be '1'.
+ - #address-cells: Should be '1'.
+ - #size-cells: Should be '1'.
+ - ranges
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+ tscadc: tscadc@5003 {
+ compatible = fsl,imx25-tsadc;
+ reg = 0x5003 0xc;
+ interrupts = 46;
+ clocks = clks 119;
+ clock-names = ipg;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ ...
+ };
+
+ adc: gcq@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ ...
+ };
+ };
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ee8204c..73f4e66 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,15 @@ config MFD_DA9063
Additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MX25_TSADC
+ tristate Freescale i.MX25 integrated Touchscreen and ADC unit
+ depends on ARCH_MXC
+ select REGMAP_MMIO
+ help
+ Enable support for the integrated Touchscreen and ADC unit of the
+ i.MX25 processors. They consist of a conversion queue for general
+ purpose ADC and a queue for Touchscreens.
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..7ff1013 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
obj-$(CONFIG_TWL6040_CORE) += twl6040.o
+obj-$(CONFIG_MFD_MX25_TSADC) += fsl-imx25-tsadc.o
+
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index 000..10332c2
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/irqdesc.h
+#include linux/irqdomain.h
+#include linux/irqchip/chained_irq.h
[PATCH v3 4/6] ARM: dts: imx25: Add TSC and ADC support
Signed-off-by: Denis Carikli de...@eukrea.com
---
Changelog v2-v3:
- Added ADC controller support: making a separate patch
for it would have been overkill.
- Moved the common TSC and ADC sub-nodes inside this patch
instead of having a copy in each dts using it.
---
arch/arm/boot/dts/imx25.dtsi | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 98783f5..3187342 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -264,13 +264,37 @@
status = disabled;
};
- tsc: tsc@5003 {
- compatible = fsl,imx25-adc, fsl,imx21-tsc;
- reg = 0x5003 0x4000;
+ tscadc: tscadc@5003 {
+ compatible = fsl,imx25-tsadc;
+ reg = 0x5003 0xc;
interrupts = 46;
clocks = clks 119;
clock-names = ipg;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
status = disabled;
+
+ adc: adc@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 0;
+ fsl,wires = 4;
+ status = disabled;
+ };
};
ssi1: ssi@50034000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Input: evdev - add event-mask API
Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on the same kernel interface.
However, user-space is often only interested in specific sets of events.
For instance, daemons dealing with system-reboot (like systemd-logind)
listen for KEY_POWER, but are not interested in any main keyboard keys.
Usually, power keys are reported via separate interfaces, however,
some i8042 boards report it in the AT matrix. To avoid waking up those
system daemons on each key-press, we had two ideas:
- split off KEY_POWER into a separate interface unconditionally
- allow masking a specific set of events on evdev FDs
Splitting of KEY_POWER is a rather weird way to deal with this and may
break backwards-compatibility. It is also specific to KEY_POWER and might
be required for other stuff, too. Moreover, we might end up with a huge
set of input-devices just to have them properly split.
Hence, this patchset implements the second idea: An event-mask to specify
which events you're interested in. Two ioctls allow setting this mask for
each event-type. If not set, all events are reported. The type==0 entry is
used same as in EVIOCGBIT to set the actual EV_* mask of masked events.
This way, you have a two-level filter.
We are heavily forward-compatible to new event-types and event-codes. So
new user-space will be able to run on an old kernel which doesn't know the
given event-codes or event-types.
Signed-off-by: David Herrmann dh.herrm...@gmail.com
---
v2:
- Drop empty SYN_REPORT
- turn evdev_get_mask_cnt() into an array-lookup
- add documentation
- fix coding-style
drivers/input/evdev.c | 156 -
include/uapi/linux/input.h | 53 +++
2 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index fd325ec..f8367190 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -51,10 +51,130 @@ struct evdev_client {
struct list_head node;
int clkid;
bool revoked;
+ unsigned long *evmasks[EV_CNT];
unsigned int bufsize;
struct input_event buffer[];
};
+static size_t evdev_get_mask_cnt(unsigned int type)
+{
+ static size_t counts[EV_CNT] = {
+ /* EV_SYN==0 is EV_CNT, _not_ SYN_CNT, see EVIOCGBIT */
+ [EV_SYN] = EV_CNT,
+ [EV_KEY] = KEY_CNT,
+ [EV_REL] = REL_CNT,
+ [EV_ABS] = ABS_CNT,
+ [EV_MSC] = MSC_CNT,
+ [EV_SW] = SW_CNT,
+ [EV_LED] = LED_CNT,
+ [EV_SND] = SND_CNT,
+ [EV_FF] = FF_CNT,
+ };
+
+ return (type EV_CNT) ? counts[type] : 0;
+}
+
+/* must be called with evdev-mutex held */
+static int evdev_set_mask(struct evdev_client *client,
+ unsigned int type,
+ const void __user *codes,
+ u32 codes_size)
+{
+ unsigned long flags, *mask, *oldmask;
+ size_t cnt, size;
+
+ /* unknown masks are simply ignored for forward-compat */
+ cnt = evdev_get_mask_cnt(type);
+ if (!cnt)
+ return 0;
+
+ /* we allow 'codes_size size' for forward-compat */
+ size = sizeof(unsigned long) * BITS_TO_LONGS(cnt);
+
+ mask = kzalloc(size, GFP_KERNEL);
+ if (!mask)
+ return -ENOMEM;
+
+ if (copy_from_user(mask, codes, min_t(size_t, codes_size, size))) {
+ kfree(mask);
+ return -EFAULT;
+ }
+
+ spin_lock_irqsave(client-buffer_lock, flags);
+ oldmask = client-evmasks[type];
+ client-evmasks[type] = mask;
+ spin_unlock_irqrestore(client-buffer_lock, flags);
+
+ kfree(oldmask);
+
+ return 0;
+}
+
+/* must be called with evdev-mutex held */
+static int evdev_get_mask(struct evdev_client *client,
+ unsigned int type,
+ void __user *codes,
+ u32 codes_size)
+{
+ unsigned long *mask;
+ size_t cnt, size, min, i;
+ u8 __user *out;
+
+ /* we allow unknown types and 'codes_size size' for forward-compat */
+ cnt = evdev_get_mask_cnt(type);
+ size = sizeof(unsigned long) * BITS_TO_LONGS(cnt);
+ min = min_t(size_t, codes_size, size);
+
+ if (cnt 0) {
+ mask = client-evmasks[type];
+ if (mask) {
+ if (copy_to_user(codes, mask, min))
+ return -EFAULT;
+ } else {
+ /* fake mask with all bits set */
+ out = (u8 __user*)codes;
+ for (i = 0; i min; ++i) {
+ if (put_user((u8)0xff, out + i))
+ return -EFAULT;
+ }
+ }
+ }
+
+
Re: [PATCH v3 1/6] mfd: fsl imx25 Touchscreen ADC driver
From: Markus Pargmann m...@pengutronix.de
This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.
This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
---
Changelog v2-v3:
- None
---
.../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |2 +
drivers/mfd/fsl-imx25-tsadc.c | 232
include/linux/mfd/imx25-tsadc.h| 138
5 files changed, 427 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
create mode 100644 include/linux/mfd/imx25-tsadc.h
[...]
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index 000..10332c2
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
[...]
+static struct regmap_config mx25_tsadc = {
+ .fast_io = true,
+ .max_register = 0x8,
Why are you representing this and this alone, in hex?
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+struct regmap *mx25_tsadc_get_regmap(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mx25_tsadc_priv *priv;
+
+ if (!dev)
+ return NULL;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ priv = platform_get_drvdata(pdev);
+ if (IS_ERR_OR_NULL(priv-regs))
+ return NULL;
What? Why are you going to all the trouble of requesting driver data
through pdev?
In fact, why have this function at all? Just pull out the information
you need from the child device driver.
+ return priv-regs;
+}
+EXPORT_SYMBOL(mx25_tsadc_get_regmap);
+
+struct clk *mx25_tsadc_get_ipg(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mx25_tsadc_priv *priv;
+
+ if (!dev)
+ return NULL;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ priv = platform_get_drvdata(pdev);
+ if (IS_ERR_OR_NULL(priv-clk))
+ return NULL;
+
+ return priv-clk;
As above - both points.
+}
+EXPORT_SYMBOL(mx25_tsadc_get_ipg);
[...]
+static void mx25_tsadc_nop(struct irq_data *d)
+{
+}
Err, no, this is not required. Just don't populate the call-backs.
+static int mx25_tsadc_set_wake_nop(struct irq_data *d, unsigned int state)
+{
+ return 0;
+}
+
+static struct irq_chip mx25_tsadc_irq_chip = {
+ .name = mx25-tsadc,
+ .irq_ack = mx25_tsadc_nop,
+ .irq_mask = mx25_tsadc_nop,
+ .irq_unmask = mx25_tsadc_nop,
No need to do this.
+ .irq_set_wake = mx25_tsadc_set_wake_nop,
+};
+
+static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct mx25_tsadc_priv *priv = d-host_data;
+
+ irq_set_chip_data(irq, priv);
+ irq_set_chip_and_handler(irq, mx25_tsadc_irq_chip,
+ handle_level_irq);
+
+
Too many '\n's here.
+ set_irq_flags(irq, IRQF_VALID);
+
+ return 0;
+}
[...]
+static int mx25_tsadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ struct mx25_tsadc_priv *priv;
+ struct resource *iores;
It would be more consistent if you just called this 'res'.
+ int ret;
+ void __iomem *iomem;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ iomem = devm_ioremap_resource(dev, iores);
+ if (IS_ERR(iomem)) {
+ dev_err(dev, Failed to remap iomem\n);
No need for an error message here, devm_ioremap_resource() is noisy
enough.
+ return PTR_ERR(iomem);
+ }
+
+ priv-regs = regmap_init_mmio(dev, iomem, mx25_tsadc);
devm_*?
Best to identify the regmap config as such -
mx25_tsadc_regmap_config.
+ if (IS_ERR(priv-regs)) {
+ dev_err(dev, Failed to initialize regmap\n);
+ return PTR_ERR(priv-regs);
+ }
+
+ priv-clk = devm_clk_get(dev, ipg);
+ if (IS_ERR(priv-clk)) {
+ dev_err(dev, Failed to get ipg clock\n);
+ return PTR_ERR(priv-clk);
+ }
+
+ /* Enable clock and reset the component */
+ regmap_update_bits(priv-regs, MX25_TSC_TGCR, MX25_TGCR_CLK_EN,
+ MX25_TGCR_CLK_EN);
+
Re: [PATCH v3 1/6] mfd: fsl imx25 Touchscreen ADC driver
On 06/16/2014 01:26 PM, Lee Jones wrote:
+static void mx25_tsadc_nop(struct irq_data *d)
+{
+}
Err, no, this is not required. Just don't populate the call-backs.
+static int mx25_tsadc_set_wake_nop(struct irq_data *d, unsigned int state)
+{
+ return 0;
+}
+
+static struct irq_chip mx25_tsadc_irq_chip = {
+ .name = mx25-tsadc,
+ .irq_ack = mx25_tsadc_nop,
+ .irq_mask = mx25_tsadc_nop,
+ .irq_unmask = mx25_tsadc_nop,
No need to do this.
I can avoid all callbacks but the irq_mask/irq_unmask ones:
Even if I add some flags to prevent it to be called during probe, it
can't be avoided to be called when an IRQ arrives.
It's called by handle_level_irq, which is setup as handler in
mx25_tsadc_domain_map. I don't think it's a good idea to rewrite it not
to depend on irq_mask/irq_unmask.
Here's what happens when an IRQ arrives (Shortened version):
[c005391c] (handle_level_irq)
[c0050930] (generic_handle_irq)
[c02dc544] (mx25_tsadc_irq_handler)
[c0050930] (generic_handle_irq)
[c0009e64] (handle_IRQ)
[c0008710] (avic_handle_irq)
[...]
Then handle_level_irq it runs mask_ack_irq inconditionally.
mask_ack_irq in turn will try to executes irq_mask_ack or else irq_mask
(without checking if it's NULL) and then will provoke the NULL pointer.
Instead when I look in drivers/mfd/ I see the following drivers which
have some dummy handlers:
wm8994-irq.c, ucb1x00-core.c, tc6393xb.c, htc-egpio.c, arizona-irq.c
So I wonder if dummy callbacks are allowed or if it's an old practice
that has been deprecated.
Else I wonder how to avoid them:
- By setting some flags (which ones?).
- Or by re-architecting the IRQ handling between the MFD and its
sub-devices in a way that the mfd driver is responsible for enabling and
disabling the IRQs (instead of its subdevices). That would be done
inside .irq_enable() and a .irq_disable().
Most of the mfd drivers that handle an IRQ controller have theses callbacks.
In the later case, how the subdevice would enable the interrupts, would
it be done automatically? or would it have to enable the parent mfd's
interrupts trough explicit callbacks or wrapper functions that will call
the callbacks(irq_enable and so on, with the irq taken from the mfd's
private struct).
I've fixed the rest of the concerns but I'll wait for an answer before
resending so I can fix this issue too.
Denis.
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input - wacom: put a flag when the led are initialized
Hi Ping, On Jun 13 2014 or thereabouts, Ping Cheng wrote: Hi Benjamin, On Fri, Jun 13, 2014 at 1:29 PM, Benjamin Tissoires benjamin.tissoi...@redhat.com wrote: This solves a bug with the wireless receiver: Your patch does get rid of the crash. But, it does not fix it at the root cause. True, it fixes the crash, does not get rid of the root cause, but it is still required. See later. - at plug, the wireless receiver does not know which Wacom device it is connected to, so it does not actually creates all the LEDs This is the root cause - LEDs are not created for wireless devices. Neither here, nor later when a real device is connected. Yep - when the tablet connects, wacom-wacom_wac.features.type is set to the proper device so that wacom_wac can understand the packets LEDs are not created for any wireless devices since we don't call wacom_initialize_leds() when real tablets are connected. Yep - when the receiver is unplugged, it detects that a LED should have been created (based on wacom-wacom_wac.features.type) and tries to remove it: crash when removing the sysfs group. When receiver is unplugged, it remembers the last tablet that connected to it. If that tablet supports LEDs, wacom_destroy_leds() is called. But, no LEDs were initialized. That's why it crashes. Yep Side effect, we can now safely call several times wacom_destroy_leds(). led_initialized will never be true if we keep wacom_initialize_leds() inside probe(). If you are talking about wireless devices only, yes, this value will never be true. That's the purpose of this patch actually :) To make initialize_leds() and desctroy_leds() work for wireless devices, we need to move them to wacom_wireless_work() where we know what type of tablet is connected/disconnected. Unfortunately, this does not work: - we *can* create the LEDs sysfs in the wireless work - this will prevent the crash - the user will think it can control the LEDs - actually these LEDs control will do nothing because LEDs handling for wireless devices goes through the WL interface, and not the PEN interface of the WL receiver. - we need to implement a specific led_handling for the wireless receiver (which will need to know which type of tablet is connected to it) - we still need a way to say that the pen intf which is declared as the connected device does not has a LED sysfs. We could add a quirk to the wacom_wac-features saying that the connection is wireless, so there is no LED attached to the interface. Still, there will be some work to do to properly handle the LED configuration from the WL receiver. This work has to be done in the kernel, but also in the user space (g-s-d) because now, the led control will not be on the pen device, but on a plain usb device without input. If you prefer, I can add such a quirk. But my only concern is here to fix the kernel oops, not to add features which would require more testing across different hardware and development on the user space side. Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com Thank you for your support. But, sorry NAKed-by: Ping Cheng pi...@wacom.com Please reconsider it or validate the quirk approach I mentioned. Cheers, Benjamin -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] leds: USB: HID: Add support for MSI GT683R led panels
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- suppport for selecting status
Changes in v5:
- mode attribute documented under Documentation/ABI
- made array for led_classdev
- led devices uses now recommended naming scheme
Changes in v6:
- flush_work added
- using hid device name instead of hard coded gt683r
- allocating name buffers with devm_kzalloc
.../ABI/testing/sysfs-class-hid-driver-gt683r | 14 +
drivers/hid/Kconfig| 16 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c | 318 +
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c| 2 +-
7 files changed, 352 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
new file mode 100644
index 000..6d0bd80
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
@@ -0,0 +1,14 @@
+What: /sys/class/hidraw/hidraw/device/mode
+Date: Jun 2014
+KernelVersion: 3.17
+Contact: Janne Kanniainen janne.kanniai...@gmail.com
+Description:
+ Set the mode of LEDs
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
+
+ Normal: LEDs are on
+ Audio: LEDs brightness depends on sound level
+ Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..b88cabd 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,22 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following modes:
+ - Normal: LEDs are on
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
+
+ You can also select which leds you want to enable.
+
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..132cc54
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,318 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General
[PATCH 0/2] touchscreen: sun4i-ts: fix reported temperature on A10
Hi Dmitry and Maxime, I've learned today that the temperature reported on the A10 / sun4i SoC family is aprox twice too high, since the A10 rtp controller temperature register seems to have double the resolution (one bit more) then that of the A13 (sun5i) and later. Dmitry, can you please add the sun4i-ts.c patch to your tree? Ideally as a bug-fix for 3.16 (where this driver was first added). Maxime, can you please add the dts patch to your tree ? Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] touchscreen: sun4i-ts: A10 (sun4i) has double the temperature precision
Testing has revealed that the temperature in the rtp controller of the A10
(sun4i) SoC has a resolution of 50 milli degrees / step, where as the
A13 (sun5i) and later models have 100 milli degrees / step.
Add a new sun5i-a13-ts compatible to differentiate the newer models and
set the resolution based on the compatible string.
This fixes the temperature reported on the A10 being twice as high as expected.
Reported-by: Tong Zhang lovewill...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/input/touchscreen/sun4i.txt | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
index aef5779..5106709 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
@@ -2,7 +2,7 @@ sun4i resistive touchscreen controller
--
Required properties:
- - compatible: allwinner,sun4i-a10-ts
+ - compatible: allwinner,sun4i-a10-ts or allwinner,sun5i-a13-ts
- reg: mmio address range of the chip
- interrupts: interrupt to which the chip is connected
diff --git a/drivers/input/touchscreen/sun4i-ts.c
b/drivers/input/touchscreen/sun4i-ts.c
index 2ba8260..5661be0 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -111,6 +111,7 @@ struct sun4i_ts_data {
unsigned int irq;
bool ignore_fifo_data;
int temp_data;
+ int temp_step;
};
static void sun4i_ts_irq_handle_input(struct sun4i_ts_data *ts, u32 reg_val)
@@ -189,7 +190,7 @@ static ssize_t show_temp(struct device *dev, struct
device_attribute *devattr,
if (ts-temp_data == -1)
return -EAGAIN;
- return sprintf(buf, %d\n, (ts-temp_data - 1447) * 100);
+ return sprintf(buf, %d\n, (ts-temp_data - 1447) * ts-temp_step);
}
static ssize_t show_temp_label(struct device *dev,
@@ -224,6 +225,10 @@ static int sun4i_ts_probe(struct platform_device *pdev)
ts-dev = dev;
ts-ignore_fifo_data = true;
ts-temp_data = -1;
+ if (of_device_is_compatible(np, allwinner,sun4i-a10-ts))
+ ts-temp_step = 50;
+ else
+ ts-temp_step = 100;
ts_attached = of_property_read_bool(np, allwinner,ts-attached);
if (ts_attached) {
@@ -318,6 +323,7 @@ static int sun4i_ts_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_ts_of_match[] = {
{ .compatible = allwinner,sun4i-a10-ts, },
+ { .compatible = allwinner,sun5i-a13-ts, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun4i_ts_of_match);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: sunxi: Adjust touchscreen compatible for sun5i and later
The touchscreen controller in the A13 and later has a different temperature
resulution compated to the one in the original A10, change the compatible
for the A13 and later so that the kernel will use the correct resolution.
Reported-by: Tong Zhang lovewill...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun5i-a10s.dtsi | 2 +-
arch/arm/boot/dts/sun5i-a13.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 6835b88..25549c1 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -519,7 +519,7 @@
};
rtp: rtp@01c25000 {
- compatible = allwinner,sun4i-a10-ts;
+ compatible = allwinner,sun5i-a13-ts;
reg = 0x01c25000 0x100;
interrupts = 29;
};
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 206b6f8..be28b3b 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -467,7 +467,7 @@
};
rtp: rtp@01c25000 {
- compatible = allwinner,sun4i-a10-ts;
+ compatible = allwinner,sun5i-a13-ts;
reg = 0x01c25000 0x100;
interrupts = 29;
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 8029a75..87c7d33 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -823,7 +823,7 @@
};
rtp: rtp@01c25000 {
- compatible = allwinner,sun4i-a10-ts;
+ compatible = allwinner,sun5i-a13-ts;
reg = 0x01c25000 0x100;
interrupts = 0 29 4;
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] Rename hid-lenovo-tpkbd to hid-lenovo, so we can add other keyboards
On Sun, 15 Jun 2014 21:39:49 +0100
Jamie Lentin j...@lentin.co.uk wrote:
Almost there :)
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
drivers/hid/Kconfig | 14 +-
drivers/hid/Makefile | 2 +-
drivers/hid/hid-core.c | 2 +-
drivers/hid/{hid-lenovo-tpkbd.c = hid-lenovo.c} | 233
+--
4 files changed, 142 insertions(+), 109 deletions(-)
rename drivers/hid/{hid-lenovo-tpkbd.c = hid-lenovo.c} (59%)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index f722001..dd07d59 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -322,18 +322,18 @@ config HID_LCPOWER
---help---
Support for LC-Power RC1000MCE RF remote control.
-config HID_LENOVO_TPKBD
- tristate Lenovo ThinkPad USB Keyboard with TrackPoint
+config HID_LENOVO
+ tristate Lenovo / Thinkpad devices
depends on HID
select NEW_LEDS
select LEDS_CLASS
---help---
- Support for the Lenovo ThinkPad USB Keyboard with TrackPoint.
+ Support for Lenovo devices that are not fully compliant with HID
standard.
Try to wrap text in Kconfig at 80 chars.
- Say Y here if you have a Lenovo ThinkPad USB Keyboard with TrackPoint
- and would like to use device-specific features like changing the
- sensitivity of the trackpoint, using the microphone mute button or
- controlling the mute and microphone mute LEDs.
+ Say Y if you want support for the non-compliant features of the Lenovo
+ Thinkpad standalone keyboards, e.g:
Maybe don't mention keyboards just yet on the line above since the
driver is now supposed to support other devices too.
+ - ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and
trackpoint
+ configuration)
Wrap at 80 chars here too.
config HID_LOGITECH
tristate Logitech devices if EXPERT
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 30e4431..384f981 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -58,7 +58,7 @@ obj-$(CONFIG_HID_KENSINGTON)+= hid-kensington.o
obj-$(CONFIG_HID_KEYTOUCH) += hid-keytouch.o
obj-$(CONFIG_HID_KYE)+= hid-kye.o
obj-$(CONFIG_HID_LCPOWER) += hid-lcpower.o
-obj-$(CONFIG_HID_LENOVO_TPKBD) += hid-lenovo-tpkbd.o
+obj-$(CONFIG_HID_LENOVO) += hid-lenovo.o
obj-$(CONFIG_HID_LOGITECH) += hid-logitech.o
obj-$(CONFIG_HID_LOGITECH_DJ)+= hid-logitech-dj.o
obj-$(CONFIG_HID_MAGICMOUSE)+= hid-magicmouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8a5384c..e8ce932 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1736,7 +1736,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC,
USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LCPOWER, USB_DEVICE_ID_LCPOWER_LC1000 )
},
-#if IS_ENABLED(CONFIG_HID_LENOVO_TPKBD)
+#if IS_ENABLED(CONFIG_HID_LENOVO)
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_TPKBD) },
#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER)
},
diff --git a/drivers/hid/hid-lenovo-tpkbd.c b/drivers/hid/hid-lenovo.c
similarity index 59%
rename from drivers/hid/hid-lenovo-tpkbd.c
rename to drivers/hid/hid-lenovo.c
index 2d25b6c..aabf084 100644
--- a/drivers/hid/hid-lenovo-tpkbd.c
+++ b/drivers/hid/hid-lenovo.c
@@ -1,5 +1,6 @@
/*
- * HID driver for Lenovo ThinkPad USB Keyboard with TrackPoint
+ * HID driver for Lenovo:-
The dash before the colon is not needed (really not a big deal I
mentioned that again just because there are other fixes too).
+ * - ThinkPad USB Keyboard with TrackPoint (tpkbd)
*
This hunk could go into a preparatory patch separated from the rename
one, see below.
* Copyright (c) 2012 Bernhard Seibold
*/
@@ -20,8 +21,7 @@
#include hid-ids.h
-/* This is only used for the trackpoint part of the driver, hence _tp */
-struct tpkbd_data_pointer {
+struct lenovo_drvdata_tpkbd {
int led_state;
struct led_classdev led_mute;
struct led_classdev led_micmute;
@@ -35,7 +35,7 @@ struct tpkbd_data_pointer {
#define map_key_clear(c) hid_map_usage_clear(hi, usage, bit, max, EV_KEY,
(c))
-static int tpkbd_input_mapping(struct hid_device *hdev,
+static int lenovo_input_mapping_tpkbd(struct hid_device *hdev,
I'd name this just lenovo_input_mapping() for now.
struct hid_input *hi, struct hid_field *field,
struct hid_usage *usage, unsigned long **bit, int *max)
{
@@ -48,12 +48,26 @@ static int tpkbd_input_mapping(struct hid_device *hdev,
return 0;
}
+static int lenovo_input_mapping(struct hid_device *hdev,
And add this separation in a preparatory patch, more or
Re: [PATCH v3 2/2] Add support for Compact (Bluetooth|USB) keyboard with Trackpoint
On Sun, 15 Jun 2014 21:39:50 +0100
Jamie Lentin j...@lentin.co.uk wrote:
This one does not compile on 3.15, see below.
Maybe you can take the chance to split the series in 4 patches:
1. rename only
2. cleanup of already existing code
3. preparatory changes to support multiple devices (the original
1/2)
4. support for the Compact keyboard (the original 2/2).
but two patches are fine too as long as the important issues are sorted
out.
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
drivers/hid/Kconfig | 2 +
drivers/hid/hid-core.c | 2 +
drivers/hid/hid-ids.h| 2 +
drivers/hid/hid-lenovo.c | 202
+++
include/linux/hid.h | 1 +
5 files changed, 209 insertions(+)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index dd07d59..48b4777 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -334,6 +334,8 @@ config HID_LENOVO
Thinkpad standalone keyboards, e.g:
- ThinkPad USB Keyboard with TrackPoint (supports extra LEDs and
trackpoint
configuration)
+ - ThinkPad Compact Bluetooth Keyboard with TrackPoint (supports Fn keys)
+ - ThinkPad Compact USB Keyboard with TrackPoint (supports Fn keys)
config HID_LOGITECH
tristate Logitech devices if EXPERT
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e8ce932..bce37c3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1738,6 +1738,8 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LCPOWER, USB_DEVICE_ID_LCPOWER_LC1000 )
},
#if IS_ENABLED(CONFIG_HID_LENOVO)
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_TPKBD) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_CUSBKBD) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LENOVO,
USB_DEVICE_ID_LENOVO_CBTKBD) },
#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_S510_RECEIVER) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 6e12cd0..1763a07 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -551,6 +551,8 @@
#define USB_VENDOR_ID_LENOVO 0x17ef
#define USB_DEVICE_ID_LENOVO_TPKBD 0x6009
+#define USB_DEVICE_ID_LENOVO_CUSBKBD 0x6047
+#define USB_DEVICE_ID_LENOVO_CBTKBD 0x6048
One TAB is enough here to align the second entry.
#define USB_VENDOR_ID_LG 0x1fd2
#define USB_DEVICE_ID_LG_MULTITOUCH 0x0064
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index aabf084..0a19f84 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -1,8 +1,11 @@
/*
* HID driver for Lenovo:-
* - ThinkPad USB Keyboard with TrackPoint (tpkbd)
+ * - ThinkPad Compact Bluetooth Keyboard with TrackPoint (cptkbd)
+ * - ThinkPad Compact USB Keyboard with TrackPoint (cptkbd)
*
* Copyright (c) 2012 Bernhard Seibold
+ * Copyright (c) 2014 Jamie Lentin j...@lentin.co.uk
*/
/*
@@ -33,6 +36,10 @@ struct lenovo_drvdata_tpkbd {
int press_speed;
};
+struct lenovo_drvdata_cptkbd {
+ unsigned int fn_lock;
bool?
+};
+
#define map_key_clear(c) hid_map_usage_clear(hi, usage, bit, max, EV_KEY,
(c))
static int lenovo_input_mapping_tpkbd(struct hid_device *hdev,
@@ -48,6 +55,49 @@ static int lenovo_input_mapping_tpkbd(struct hid_device
*hdev,
return 0;
}
+static int lenovo_input_mapping_cptkbd(struct hid_device *hdev,
+ struct hid_input *hi, struct hid_field *field,
+ struct hid_usage *usage, unsigned long **bit, int *max)
+{
+ /* HID_UP_LNVENDOR = USB, HID_UP_MSVENDOR = BT */
+ if ((usage-hid HID_USAGE_PAGE) == HID_UP_MSVENDOR ||
+ (usage-hid HID_USAGE_PAGE) == HID_UP_LNVENDOR) {
+ set_bit(EV_REP, hi-input-evbit);
+ switch (usage-hid HID_USAGE) {
+ case 0x00f1: /* Fn-F4: Mic mute */
+ map_key_clear(KEY_MICMUTE);
+ return 1;
+ case 0x00f2: /* Fn-F5: Brightness down */
+ map_key_clear(KEY_BRIGHTNESSDOWN);
+ return 1;
+ case 0x00f3: /* Fn-F6: Brightness up */
+ map_key_clear(KEY_BRIGHTNESSUP);
+ return 1;
+ case 0x00f4: /* Fn-F7: External display (projector) */
+ map_key_clear(KEY_SWITCHVIDEOMODE);
+ return 1;
+ case 0x00f5: /* Fn-F8: Wireless */
+ map_key_clear(KEY_WLAN);
+ return 1;
+ case 0x00f6: /* Fn-F9: Control panel */
+ map_key_clear(KEY_CONFIG);
+ return 1;
+ case 0x00f8: /* Fn-F11: View open applications (3 boxes) */
+
Re: [PATCH 1/2] touchscreen: sun4i-ts: A10 (sun4i) has double the temperature precision
Hi Hans, On Mon, Jun 16, 2014 at 08:24:28PM +0200, Hans de Goede wrote: Testing has revealed that the temperature in the rtp controller of the A10 (sun4i) SoC has a resolution of 50 milli degrees / step, where as the A13 (sun5i) and later models have 100 milli degrees / step. Add a new sun5i-a13-ts compatible to differentiate the newer models and set the resolution based on the compatible string. This fixes the temperature reported on the A10 being twice as high as expected. Should we maybe add explicit temperature steps property so that we won;t need to patch again if they decided to change resolution again? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/10] Batch of cleanup patches for cros_ec
This is a batch of cleanup patches picked from the ChromeOS 3.8 kernel tree and applied to ToT. Most of these patches were authored by Bill Richardson (CCed). Where appropriate I've squashed patches together, though I have erred on the side of keeping patches logically distinct rather than squashing into one big cleanup patch. There is very little functionality added by this series, but this gets us closer to how things look in the ChromeOS tree so we can add more patches atop it. In general I took the oldest patches from our tree and stopped picking when I got to a reasonable patch size (10 patches). There are about 5 more cleanup patches still in the ChromeOS tree, then some more major functionality patches. Note that I didn't take the cros_ec_dev userspace inteface, the LPC implementation, the vboot context implementation, and patches relating to exynos5250-spring when picking patches. These bits are very separate (and big!) and can be added and debated separately after we've got cleanup in. Whenever patches touched those pieces of the code I ignored that part of the patch. In general I did take cleanup code that was intended to make it easier to later add these bits. I have tested basic functionality of these patches on exynos5250-snow and exynos5420-peach-pit. Bill Richardson (9): mfd: cros_ec: Fix the comment on cros_ec_remove() mfd: cros_ec: IRQs for cros_ec should be optional mfd: cros_ec: Allow static din/dout buffers with cros_ec_register() mfd: cros_ec: Tweak struct cros_ec_device for clarity mfd: cros_ec: Use struct cros_ec_command to communicate with the EC mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device mfd: cros_ec: cleanup: Remove EC wrapper functions mfd: cros_ec: Check result code from EC messages mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC Simon Glass (1): mdf: cros_ec: Detect in-progress commands drivers/i2c/busses/i2c-cros-ec-tunnel.c | 17 -- drivers/input/keyboard/cros_ec_keyb.c | 14 - drivers/mfd/cros_ec.c | 76 +++- drivers/mfd/cros_ec_i2c.c | 44 -- drivers/mfd/cros_ec_spi.c | 43 -- include/linux/mfd/cros_ec.h | 100 +++- 6 files changed, 144 insertions(+), 150 deletions(-) -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions
From: Bill Richardson wfric...@chromium.org
Remove the three wrapper functions that talk to the EC without passing all
the desired arguments and just use the underlying communication function
that passes everything in a struct intead.
This is internal code refactoring only. Nothing should change.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 15 +++
drivers/input/keyboard/cros_ec_keyb.c | 14 --
drivers/mfd/cros_ec.c | 32
include/linux/mfd/cros_ec.h | 19 ++-
4 files changed, 29 insertions(+), 51 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 8e7a714..dd07818 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -183,6 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
u8 *request = NULL;
u8 *response = NULL;
int result;
+ struct cros_ec_command msg;
request_len = ec_i2c_count_message(i2c_msgs, num);
if (request_len 0) {
@@ -218,9 +219,15 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
}
ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
- result = bus-ec-command_sendrecv(bus-ec, EC_CMD_I2C_PASSTHRU,
- request, request_len,
- response, response_len);
+
+ msg.version = 0;
+ msg.command = EC_CMD_I2C_PASSTHRU;
+ msg.outdata = request;
+ msg.outsize = request_len;
+ msg.indata = response;
+ msg.insize = response_len;
+
+ result = bus-ec-cmd_xfer(bus-ec, msg);
if (result)
goto exit;
@@ -258,7 +265,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
u32 remote_bus;
int err;
- if (!ec-command_sendrecv) {
+ if (!ec-cmd_xfer) {
dev_err(dev, Missing sendrecv\n);
return -EINVAL;
}
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 4083796..dc37b6b 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
*kb_state)
{
- return ckdev-ec-command_recv(ckdev-ec, EC_CMD_MKBP_STATE,
- kb_state, ckdev-cols);
+ int ret;
+ struct cros_ec_command msg = {
+ .version = 0,
+ .command = EC_CMD_MKBP_STATE,
+ .outdata = NULL,
+ .outsize = 0,
+ .indata = kb_state,
+ .insize = ckdev-cols,
+ };
+
+ ret = ckdev-ec-cmd_xfer(ckdev-ec, msg);
+ return ret;
}
static int cros_ec_keyb_work(struct notifier_block *nb,
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index d242714..6dd91e9 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -44,34 +44,6 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
-static int cros_ec_command_sendrecv(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *out_buf, int out_len,
- void *in_buf, int in_len)
-{
- struct cros_ec_command msg;
-
- msg.version = cmd 8;
- msg.command = cmd 0xff;
- msg.outdata = out_buf;
- msg.outsize = out_len;
- msg.indata = in_buf;
- msg.insize = in_len;
-
- return ec_dev-cmd_xfer(ec_dev, msg);
-}
-
-static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *buf, int buf_len)
-{
- return cros_ec_command_sendrecv(ec_dev, cmd, NULL, 0, buf, buf_len);
-}
-
-static int cros_ec_command_send(struct cros_ec_device *ec_dev,
- uint16_t cmd, void *buf, int buf_len)
-{
- return cros_ec_command_sendrecv(ec_dev, cmd, buf, buf_len, NULL, 0);
-}
-
static irqreturn_t ec_irq_thread(int irq, void *data)
{
struct cros_ec_device *ec_dev = data;
@@ -104,10 +76,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
BLOCKING_INIT_NOTIFIER_HEAD(ec_dev-event_notifier);
- ec_dev-command_send = cros_ec_command_send;
- ec_dev-command_recv = cros_ec_command_recv;
- ec_dev-command_sendrecv = cros_ec_command_sendrecv;
-
if (ec_dev-din_size) {
ec_dev-din = devm_kzalloc(dev, ec_dev-din_size, GFP_KERNEL);
if (!ec_dev-din)
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2b0c598..60c0880 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -63,9 +63,10 @@ struct cros_ec_command {
*
[PATCH v4 2/2] elantech: Call psmouse_reset when elantech probe fails
elantech_init() calls elantech_set_absolute_mode which sets the driver in an absolute mode. When after this the elantech_init fails, it is best to turn the ps/2 mouse emulation mode back on by calling psmouse_reset() so that it can work as a regular mouse. Signed-off-by: Ulrik De Bie ulrik.debie...@e2big.org --- drivers/input/mouse/elantech.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c index 5dd620a..771291c 100644 --- a/drivers/input/mouse/elantech.c +++ b/drivers/input/mouse/elantech.c @@ -1620,6 +1620,7 @@ int elantech_init(struct psmouse *psmouse) sysfs_remove_group(psmouse-ps2dev.serio-dev.kobj, elantech_attr_group); init_fail: + psmouse_reset(psmouse); kfree(etd); return error; } -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] elantech: Add support for trackpoint found on some v3 models
Some elantech v3 touchpad equipped laptops also have a trackpoint, before
this commit, these give sync errors. With this patch, the trackpoint is
provided as another input device: 'Elantech PS/2 TrackPoint'
The patch will also output messages that do not follow the expected pattern.
In the mean time I've seen 2 unknown packets occasionally:
0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00
0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00
I don't know what those are for, but they can be safely ignored.
Currently all packets that are not known to v3 touchpad and where
packet[3] (the fourth byte) lowest nibble is 6 are now recognized as
PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint.
This has been verified to work on a laptop Lenovo L530 where the
touchpad/trackpoint combined identify themselves as:
psmouse serio1: elantech: assuming hardware version 3 (with firmware version
0x350f02)
psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c.
Reviewed-by: David Herrmann dh.herrm...@gmail.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Ulrik De Bie ulrik.debie...@e2big.org
---
drivers/input/mouse/elantech.c | 122 +++--
drivers/input/mouse/elantech.h | 3 +
2 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index ee2a04d..5dd620a 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -403,6 +403,71 @@ static void elantech_report_absolute_v2(struct psmouse
*psmouse)
input_sync(dev);
}
+static void elantech_report_trackpoint(struct psmouse *psmouse,
+ int packet_type)
+{
+ /*
+* byte 0: 0 0 ~sx ~sy 0 M R L
+* byte 1: sx 0 0 0 0 0 0 0
+* byte 2: sy 0 0 0 0 0 0 0
+* byte 3: 0 0 sy sx 0 1 1 0
+* byte 4: x7 x6 x5 x4 x3 x2 x1 x0
+* byte 5: y7 y6 y5 y4 y3 y2 y1 y0
+*
+* x and y are written in two's complement spread
+* over 9 bits with sx/sy the relative top bit and
+* x7..x0 and y7..y0 the lower bits.
+* The sign of y is opposite to what the input driver
+* expects for a relative movement
+*/
+
+ struct elantech_data *etd = psmouse-private;
+ struct input_dev *tp_dev = etd-tp_dev;
+ unsigned char *packet = psmouse-packet;
+ int x, y;
+ u32 t;
+
+ if (!tp_dev) {
+ static bool __section(.data.unlikely) __warned;
+
+ if (!__warned) {
+ __warned = true;
+ psmouse_err(psmouse, Unexpected trackpoint message\n);
+ if (etd-debug == 1)
+ elantech_packet_dump(psmouse);
+ }
+
+ return;
+ }
+
+ input_report_key(tp_dev, BTN_LEFT, packet[0] 0x01);
+ input_report_key(tp_dev, BTN_RIGHT, packet[0] 0x02);
+ input_report_key(tp_dev, BTN_MIDDLE, packet[0] 0x04);
+
+ x = ((packet[1] 0x80) ? 0U : 0xFF00U) | packet[4];
+ y = -(int)(((packet[2] 0x80) ? 0U : 0xFF00U) | packet[5]);
+
+ input_report_rel(tp_dev, REL_X, x);
+ input_report_rel(tp_dev, REL_Y, y);
+
+ t = (((u32)packet[0] 0xF8) 24) | ((u32)packet[1] 16)
+ | (u32)packet[2] 8 | (u32)packet[3];
+ switch (t) {
+ case 0x00808036U:
+ case 0x10008026U:
+ case 0x20800016U:
+ case 0x3006U:
+ break;
+ default:
+ /* Dump unexpected packet sequences if debug=1 (default) */
+ if (etd-debug == 1)
+ elantech_packet_dump(psmouse);
+ break;
+ }
+
+ input_sync(tp_dev);
+}
+
/*
* Interpret complete data packets and report absolute mode input events for
* hardware version 3. (12 byte packets for two fingers)
@@ -715,6 +780,8 @@ static int elantech_packet_check_v3(struct psmouse *psmouse)
if ((packet[0] 0x0c) == 0x0c (packet[3] 0xce) == 0x0c)
return PACKET_V3_TAIL;
+ if ((packet[3] 0x0f) == 0x06)
+ return PACKET_TRACKPOINT;
}
return PACKET_UNKNOWN;
@@ -798,7 +865,10 @@ static psmouse_ret_t elantech_process_byte(struct psmouse
*psmouse)
if (packet_type == PACKET_UNKNOWN)
return PSMOUSE_BAD_DATA;
- elantech_report_absolute_v3(psmouse, packet_type);
+ if (packet_type == PACKET_TRACKPOINT)
+ elantech_report_trackpoint(psmouse, packet_type);
+ else
+ elantech_report_absolute_v3(psmouse, packet_type);
break;
case 4:
@@ -1018,8 +1088,10 @@ static int elantech_get_resolution_v4(struct psmouse
*psmouse,
* Asus UX31 0x361f00
[PATCH v4 0/2] Input: Support in the elantech driver of the trackpoint present on for instance Lenovo L530
Patch 1 adds support for trackpoint on elantech driver for v3 models. Patch 2 adds a psmouse_reset when the elantech probes fails. Patch 2 depends on Patch 1. Changes since v3: * Patch1: added (correct) error after input_allocate_device failure in elantech_init() * Patch2: added more explanation to the why Changes since v2: * psmouse_reset change is now moved to a separate patch * comments/white spaces/newlines cleanup * Unexpected trackpoint message warning now only printed once * removed some unnecessary casts * Deleted etd-trackpoint_present and use instead etd-tp_dev to indicate the presence of a trackpoint * Propagate the error when elantech_init fails Changes since v1: * New patch now with reference to 3.14rc1 * Added etd-trackpoint_present to indicate presence of trackpoint (based on MSB of etd-capabilities[0]) * trackpoint will only be registered now when MSB of etd-capabilities[0] is set; got confirmation that this is the indicator of trackpoint * Added input_unregister_device/input_free_device in elantech_disconnect() * Fixed a bug in cleaning up when elantech_init fails * Rename commit to be more specific (now also applicable to future elantech v3 models with trackpoint) * input device name 'TPPS/2 IBM TrackPoint' changed to 'Elantech PS/2 TrackPoint', this patch is not ibm/lenovo specific! * dev2 renamed to tp_dev to indicate that this is the trackpoint device * etd-phys renamed to etd-tp_phys * Added Lenovo 530 and Fujitsu H730 to the laptop list because those are now also known. * Added psmouse_reset at the end of elantech_init when it fails * Added warning when trackpoint packets are received with no trackpoint detected The patches are also available from: https://github.com/ulrikdb/linux/commit/53d8424bc2143d34c2be76064892079fe1917a9e https://github.com/ulrikdb/linux/commit/cf12fcc6cdf51a7aad48d056750478aecd9d7eca Ulrik De Bie (2): elantech: Add support for trackpoint found on some v3 models elantech: Call psmouse_reset when elantech probe fails drivers/input/mouse/elantech.c | 123 +++-- drivers/input/mouse/elantech.h | 3 + 2 files changed, 122 insertions(+), 4 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] leds: USB: HID: Add support for MSI GT683R led panels
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- suppport for selecting status
Changes in v5:
- mode attribute documented under Documentation/ABI
- made array for led_classdev
- led devices uses now recommended naming scheme
Changes in v6:
- flush_work added
- using hid device name instead of hard coded gt683r
- allocating name buffers with devm_kzalloc
There was a bug with for, so I fixed it.
.../ABI/testing/sysfs-class-hid-driver-gt683r | 14 +
drivers/hid/Kconfig| 16 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c | 318 +
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c| 2 +-
7 files changed, 352 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
new file mode 100644
index 000..6d0bd80
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
@@ -0,0 +1,14 @@
+What: /sys/class/hidraw/hidraw/device/mode
+Date: Jun 2014
+KernelVersion: 3.17
+Contact: Janne Kanniainen janne.kanniai...@gmail.com
+Description:
+ Set the mode of LEDs
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
+
+ Normal: LEDs are on
+ Audio: LEDs brightness depends on sound level
+ Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..b88cabd 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,22 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following modes:
+ - Normal: LEDs are on
+ - Audio: LEDs brightness depends on sound level
+ - Breathing: LEDs brightness varies at human breathing rate
+
+ You can also select which leds you want to enable.
+
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..1b16250
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,318 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify
