* Re: [PATCH] Input: twl4030 - convert to using managed resources
From: Jingoo Han @ 2014-01-07 0:38 UTC (permalink / raw)
To: 'Sebastian Reichel'
Cc: 'Dmitry Torokhov', linux-input, 'Fugang Duan',
'Peter Ujfalusi', ".linux-kernel",
'Jingoo Han'
In-Reply-To: <20140106221405.GA22325@earth.universe>
On Tuesday, January 07, 2014 7:14 AM, Sebastian Reichel wrote:
> On Mon, Jan 06, 2014 at 11:50:46AM +0900, Jingoo Han wrote:
> > If you repeat at least twice insmod & rmmod 'twl4030_keypad.ko',
> > it will be good. If there are some bugs, it will make the error
> > messages or kernel panic.
>
> I tried load & unloading the twl4030_keypad module multiple times.
> I didn't get any error messages or kernel panics. Everything seems
> to behave correctly.
Thank you for your testing. :-)
I checked the sequence; it looks good.
See you later.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH] Input: twl4030 - convert to using managed resources
From: Jingoo Han @ 2014-01-07 0:39 UTC (permalink / raw)
To: 'Dmitry Torokhov', 'Sebastian Reichel'
Cc: linux-input, 'Fugang Duan', 'Peter Ujfalusi',
".linux-kernel", 'Jingoo Han'
In-Reply-To: <20140104090147.GA16680@core.coreip.homeip.net>
On Saturday, January 04, 2014 6:02 PM, Dmitry Torokhov wrote:
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
It looks good.
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
>
> Compile-tested only.
>
>
> drivers/input/keyboard/twl4030_keypad.c | 70 +++++++++++----------------------
> 1 file changed, 22 insertions(+), 48 deletions(-)
^ permalink raw reply
* [PATCH v2] Input: add i2c/smbus driver for elan touchpad
From: Duson Lin @ 2014-01-07 3:08 UTC (permalink / raw)
To: linux-kernel, linux-input, dmitry.torokhov
Cc: bleung, agnescheng, phoenix, jeff.chuang, Duson Lin
This driver adds support for elan i2c/smbus touchpad found on some laptops PC
Signed-off-by: Duson Lin <dusonlin@emc.com.tw>
---
drivers/input/mouse/Kconfig | 10 +
drivers/input/mouse/Makefile | 1 +
drivers/input/mouse/elan_i2c.c | 890 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 901 insertions(+)
create mode 100644 drivers/input/mouse/elan_i2c.c
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index effa9c5..095eccc 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -215,6 +215,16 @@ config MOUSE_CYAPA
To compile this driver as a module, choose M here: the module will be
called cyapa.
+config MOUSE_ELAN_I2C
+ tristate "ELAN I2C Touchpad support"
+ depends on I2C
+ help
+ This driver adds support for Elan I2C Trackpads.
+ Say Y here if you have a ELAN I2C Touchpad.
+
+ To compile this driver as a module, choose M here: the module will be
+ called elan_i2c.
+
config MOUSE_INPORT
tristate "InPort/MS/ATIXL busmouse"
depends on ISA
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index c25efdb..24a12a6 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o
obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o
obj-$(CONFIG_MOUSE_BCM5974) += bcm5974.o
obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o
+obj-$(CONFIG_MOUSE_ELAN_I2C) += elan_i2c.o
obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o
obj-$(CONFIG_MOUSE_INPORT) += inport.o
obj-$(CONFIG_MOUSE_LOGIBM) += logibm.o
diff --git a/drivers/input/mouse/elan_i2c.c b/drivers/input/mouse/elan_i2c.c
new file mode 100644
index 0000000..f7bfa22
--- /dev/null
+++ b/drivers/input/mouse/elan_i2c.c
@@ -0,0 +1,890 @@
+/*
+ * Elan I2C/SMBus Touchpad driver
+ *
+ * Copyright (c) 2013 ELAN Microelectronics Corp.
+ *
+ * Author: 林政維 (Duson Lin) <dusonlin@emc.com.tw>
+ * Version: 1.4.6
+ *
+ * Based on cyapa driver:
+ * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
+ * copyright (c) 2011-2012 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/firmware.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/input/mt.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/debugfs.h>
+#include <linux/cdev.h>
+#include <linux/kernel.h>
+#include <linux/major.h>
+#include <linux/sched.h>
+#include <linux/input.h>
+#include <linux/uaccess.h>
+#include <linux/jiffies.h>
+
+#define DRIVER_NAME "elan_i2c"
+#define ELAN_DRIVER_VERSION "1.4.6"
+#define ETP_PRESSURE_OFFSET 25
+#define ETP_MAX_PRESSURE 255
+#define ETP_FWIDTH_REDUCE 90
+#define ETP_FINGER_WIDTH 15
+
+#define ELAN_ADAPTER_FUNC_NONE 0
+#define ELAN_ADAPTER_FUNC_I2C 1
+#define ELAN_ADAPTER_FUNC_SMBUS 2
+#define ELAN_ADAPTER_FUNC_BOTH 3
+
+/* Length of Elan touchpad information */
+#define ETP_INF_LENGTH 2
+#define ETP_MAX_FINGERS 5
+#define ETP_FINGER_DATA_LEN 5
+#define ETP_REPORT_ID 0x5D
+#define ETP_MAX_REPORT_LEN 34
+#define ETP_ENABLE_ABS 0x0001
+#define ETP_ENABLE_CALIBRATE 0x0002
+#define ETP_DISABLE_CALIBRATE 0x0000
+
+/* Elan smbus command */
+#define ETP_SMBUS_IAP_CMD 0x00
+#define ETP_SMBUS_ENABLE_TP 0x20
+#define ETP_SMBUS_SLEEP_CMD 0x21
+#define ETP_SMBUS_IAP_PASSWORD_WRITE 0x29
+#define ETP_SMBUS_IAP_PASSWORD_READ 0x80
+#define ETP_SMBUS_WRITE_FW_BLOCK 0x2A
+#define ETP_SMBUS_IAP_RESET_CMD 0x2B
+#define ETP_SMBUS_RANGE_CMD 0xA0
+#define ETP_SMBUS_FW_VERSION_CMD 0xA1
+#define ETP_SMBUS_XY_TRACENUM_CMD 0xA2
+#define ETP_SMBUS_SM_VERSION_CMD 0xA3
+#define ETP_SMBUS_UNIQUEID_CMD 0xA3
+#define ETP_SMBUS_RESOLUTION_CMD 0xA4
+#define ETP_SMBUS_HELLOPACKET_CMD 0xA7
+#define ETP_SMBUS_PACKET_QUERY 0xA8
+#define ETP_SMBUS_IAP_VERSION_CMD 0xAC
+#define ETP_SMBUS_IAP_CTRL_CMD 0xAD
+#define ETP_SMBUS_IAP_CHECKSUM_CMD 0xAE
+#define ETP_SMBUS_FW_CHECKSUM_CMD 0xAF
+#define ETP_SMBUS_MAX_BASELINE_CMD 0xC3
+#define ETP_SMBUS_MIN_BASELINE_CMD 0xC4
+#define ETP_SMBUS_CALIBRATE_QUERY 0xC5
+#define ETP_SMBUS_REPORT_LEN 32
+#define ETP_SMBUS_FINGER_DATA_OFFSET 2
+#define ETP_SMBUS_HELLOPACKET_LEN 5
+#define ETP_SMBUS_IAP_PASSWORD 0x1234
+#define ETP_SMBUS_IAP_MODE_ON (1<<6)
+
+/* Elan i2c command */
+#define ETP_I2C_RESET 0x0100
+#define ETP_I2C_WAKE_UP 0x0800
+#define ETP_I2C_SLEEP 0x0801
+#define ETP_I2C_DESC_CMD 0x0001
+#define ETP_I2C_REPORT_DESC_CMD 0x0002
+#define ETP_I2C_STAND_CMD 0x0005
+#define ETP_I2C_UNIQUEID_CMD 0x0101
+#define ETP_I2C_FW_VERSION_CMD 0x0102
+#define ETP_I2C_SM_VERSION_CMD 0x0103
+#define ETP_I2C_XY_TRACENUM_CMD 0x0105
+#define ETP_I2C_MAX_X_AXIS_CMD 0x0106
+#define ETP_I2C_MAX_Y_AXIS_CMD 0x0107
+#define ETP_I2C_RESOLUTION_CMD 0x0108
+#define ETP_I2C_IAP_VERSION_CMD 0x0110
+#define ETP_I2C_SET_CMD 0x0300
+#define ETP_I2C_MAX_BASELINE_CMD 0x0306
+#define ETP_I2C_MIN_BASELINE_CMD 0x0307
+#define ETP_I2C_FW_CHECKSUM_CMD 0x030F
+#define ETP_I2C_IAP_CTRL_CMD 0x0310
+#define ETP_I2C_IAP_CMD 0x0311
+#define ETP_I2C_IAP_RESET_CMD 0x0314
+#define ETP_I2C_IAP_CHECKSUM_CMD 0x0315
+#define ETP_I2C_CALIBRATE_CMD 0x0316
+#define ETP_I2C_REPORT_LEN 34
+#define ETP_I2C_FINGER_DATA_OFFSET 4
+#define ETP_I2C_REPORT_ID_OFFSET 2
+#define ETP_I2C_DESC_LENGTH 30
+#define ETP_I2C_REPORT_DESC_LENGTH 158
+#define ETP_I2C_IAP_PASSWORD 0x1EA5
+#define ETP_I2C_IAP_RESET 0xF0F0
+#define ETP_I2C_MAIN_MODE_ON (1<<9)
+#define ETP_I2C_IAP_REG_L 0x01
+#define ETP_I2C_IAP_REG_H 0x06
+
+/* The main device structure */
+struct elan_tp_data {
+ struct i2c_client *client;
+ struct input_dev *input;
+ unsigned int max_x;
+ unsigned int max_y;
+ unsigned int width_x;
+ unsigned int width_y;
+ unsigned int irq;
+ u16 unique_id;
+ u16 fw_version;
+ u16 sm_version;
+ u16 iap_version;
+ bool smbus;
+};
+
+/*
+ *******************************************************************
+ * Elan smbus interface
+ *******************************************************************
+ */
+static int elan_smbus_initialize(struct i2c_client *client)
+{
+ u8 check[ETP_SMBUS_HELLOPACKET_LEN] = {0x55, 0x55, 0x55, 0x55, 0x55};
+ u8 values[ETP_SMBUS_HELLOPACKET_LEN] = {0, 0, 0, 0, 0};
+ int ret;
+
+ /* Get hello packet */
+ ret = i2c_smbus_read_block_data(client,
+ ETP_SMBUS_HELLOPACKET_CMD, values);
+ if (ret != ETP_SMBUS_HELLOPACKET_LEN) {
+ dev_err(&client->dev, "hello packet length fail\n");
+ return -1;
+ }
+
+ /* compare hello packet */
+ if (memcmp(values, check, ETP_SMBUS_HELLOPACKET_LEN)) {
+ dev_err(&client->dev, "hello packet fail [%x %x %x %x %x]\n",
+ values[0], values[1], values[2], values[3], values[4]);
+ return -1;
+ }
+
+ /* enable tp */
+ ret = i2c_smbus_write_byte(client, ETP_SMBUS_ENABLE_TP);
+ return ret;
+}
+
+static int elan_smbus_enable_absolute_mode(struct i2c_client *client)
+{
+ u8 cmd[4] = {0x00, 0x07, 0x00, ETP_ENABLE_ABS};
+
+ return i2c_smbus_write_block_data(client, ETP_SMBUS_IAP_CMD, 4, cmd);
+}
+
+/*
+ ******************************************************************
+ * Elan i2c interface
+ ******************************************************************
+ */
+static int elan_i2c_read_block(struct i2c_client *client,
+ u16 reg, u8 *val, u16 len)
+{
+ struct i2c_msg msgs[2];
+ u8 buf[2];
+ int ret;
+
+ buf[0] = reg & 0xff;
+ buf[1] = (reg >> 8) & 0xff;
+
+ msgs[0].addr = client->addr;
+ msgs[0].flags = client->flags & I2C_M_TEN;
+ msgs[0].len = 2;
+ msgs[0].buf = buf;
+
+ msgs[1].addr = client->addr;
+ msgs[1].flags = client->flags & I2C_M_TEN;
+ msgs[1].flags |= I2C_M_RD;
+ msgs[1].len = len;
+ msgs[1].buf = val;
+
+ ret = i2c_transfer(client->adapter, msgs, 2);
+ return ret != 2 ? -EIO : 0;
+}
+
+static int elan_i2c_read_cmd(struct i2c_client *client, u16 reg, u8 *val)
+{
+ int retval;
+
+ retval = elan_i2c_read_block(client, reg, val, ETP_INF_LENGTH);
+ if (retval < 0) {
+ dev_err(&client->dev, "reading cmd (0x%04x) fail.\n", reg);
+ return retval;
+ }
+ return 0;
+}
+
+static int elan_i2c_write_cmd(struct i2c_client *client, u16 reg, u16 cmd)
+{
+ struct i2c_msg msg;
+ u8 buf[4];
+ int ret;
+
+ buf[0] = reg & 0xff;
+ buf[1] = (reg >> 8) & 0xff;
+ buf[2] = cmd & 0xff;
+ buf[3] = (cmd >> 8) & 0xff;
+
+ msg.addr = client->addr;
+ msg.flags = client->flags & I2C_M_TEN;
+ msg.len = 4;
+ msg.buf = buf;
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ return ret != 1 ? -EIO : 0;
+}
+
+static int elan_i2c_reset(struct i2c_client *client)
+{
+ return elan_i2c_write_cmd(client, ETP_I2C_STAND_CMD,
+ ETP_I2C_RESET);
+}
+
+static int elan_i2c_wake_up(struct i2c_client *client)
+{
+ return elan_i2c_write_cmd(client, ETP_I2C_STAND_CMD,
+ ETP_I2C_WAKE_UP);
+}
+
+static int elan_i2c_sleep(struct i2c_client *client)
+{
+ return elan_i2c_write_cmd(client, ETP_I2C_STAND_CMD,
+ ETP_I2C_SLEEP);
+}
+
+static int elan_i2c_enable_absolute_mode(struct i2c_client *client)
+{
+ return elan_i2c_write_cmd(client, ETP_I2C_SET_CMD,
+ ETP_ENABLE_ABS);
+}
+
+static int elan_i2c_get_desc(struct i2c_client *client, u8 *val)
+{
+ return elan_i2c_read_block(client, ETP_I2C_DESC_CMD, val,
+ ETP_I2C_DESC_LENGTH);
+}
+
+static int elan_i2c_get_report_desc(struct i2c_client *client, u8 *val)
+{
+ return elan_i2c_read_block(client, ETP_I2C_REPORT_DESC_CMD,
+ val, ETP_I2C_REPORT_DESC_LENGTH);
+}
+
+static int elan_i2c_initialize(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ int rc;
+ u8 val[256];
+
+ rc = elan_i2c_reset(client);
+ if (rc < 0) {
+ dev_err(dev, "device reset failed.\n");
+ return -1;
+ }
+
+ /* wait for get reset return flag */
+ msleep(100);
+ /* get reset return flag 0000 */
+ rc = i2c_master_recv(client, val, ETP_INF_LENGTH);
+ if (rc < 0) {
+ dev_err(dev, "get device reset return value failed.\n");
+ return -1;
+ }
+
+ rc = elan_i2c_get_desc(client, val);
+ if (rc < 0) {
+ dev_err(dev, "cannot get device descriptor.\n");
+ return -1;
+ }
+
+ rc = elan_i2c_get_report_desc(client, val);
+ if (rc < 0) {
+ dev_err(dev, "fetching report descriptor failed.\n");
+ return -1;
+ }
+ return 0;
+}
+
+/*
+ ******************************************************************
+ * General functions
+ ******************************************************************
+ */
+/*
+ * (value from firmware) * 10 + 790 = dpi
+ * we also have to convert dpi to dots/mm (*10/254 to avoid floating point)
+ */
+static unsigned int elan_convert_res(char val)
+{
+ int res;
+ if (val & 0x80) {
+ val = ~val + 1;
+ res = (790 - val * 10) * 10 / 254;
+ } else
+ res = (val * 10 + 790) * 10 / 254;
+ return res;
+}
+
+static int elan_get_iap_version(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_IAP_VERSION_CMD, val);
+ ret = val[2];
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_IAP_VERSION_CMD, val);
+ ret = val[0];
+ }
+ return ret;
+}
+
+static int elan_get_x_max(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_RANGE_CMD, val);
+ ret = (0x0f & val[0]) << 8 | val[1];
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_MAX_X_AXIS_CMD, val);
+ ret = (0x0f & val[1]) << 8 | val[0];
+ }
+ return ret;
+}
+
+static int elan_get_y_max(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_RANGE_CMD, val);
+ ret = (0xf0 & val[0]) << 4 | val[2];
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_MAX_Y_AXIS_CMD, val);
+ ret = (0x0f & val[1]) << 8 | val[0];
+ }
+ return ret;
+}
+
+static int elan_get_x_tracenum(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_XY_TRACENUM_CMD, val);
+ ret = (val[1] - 1);
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_XY_TRACENUM_CMD, val);
+ ret = (val[0] - 1);
+ }
+ return ret;
+}
+
+static int elan_get_y_tracenum(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_XY_TRACENUM_CMD, val);
+ ret = (val[2] - 1);
+ } else {
+ ret = elan_i2c_read_cmd(data->client,
+ ETP_I2C_XY_TRACENUM_CMD, val);
+ ret = (val[1] - 1);
+ }
+ return ret;
+}
+
+static int elan_get_fw_version(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_FW_VERSION_CMD, val);
+ ret = val[2];
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_FW_VERSION_CMD, val);
+ ret = val[0];
+ }
+ return ret;
+}
+
+static int elan_get_sm_version(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus)
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_SM_VERSION_CMD, val);
+ else
+ elan_i2c_read_block(data->client,
+ ETP_I2C_SM_VERSION_CMD, val, 1);
+ ret = val[0];
+ return ret;
+}
+
+static int elan_get_unique_id(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_UNIQUEID_CMD, val);
+ ret = val[1];
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_UNIQUEID_CMD, val);
+ ret = val[0];
+ }
+ return ret;
+}
+
+static int elan_get_x_resolution(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_RESOLUTION_CMD, val);
+ ret = elan_convert_res(val[1] & 0x0F);
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_RESOLUTION_CMD, val);
+ ret = elan_convert_res(val[0]);
+ }
+ return ret;
+}
+
+static int elan_get_y_resolution(struct elan_tp_data *data)
+{
+ int ret;
+ u8 val[3];
+ if (data->smbus) {
+ i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_RESOLUTION_CMD, val);
+ ret = elan_convert_res((val[1] & 0xF0) >> 4);
+ } else {
+ elan_i2c_read_cmd(data->client,
+ ETP_I2C_RESOLUTION_CMD, val);
+ ret = elan_convert_res(val[1]);
+ }
+ return ret;
+}
+
+static int elan_initialize(struct elan_tp_data *data)
+{
+ int ret;
+ if (data->smbus) {
+ ret = elan_smbus_initialize(data->client);
+ if (ret < 0) {
+ dev_err(&data->client->dev,
+ "device initialize failed.\n");
+ goto err_initialize;
+ }
+
+ ret = elan_smbus_enable_absolute_mode(data->client);
+ if (ret < 0)
+ dev_err(&data->client->dev,
+ "cannot switch to absolute mode.\n");
+ } else {
+ ret = elan_i2c_initialize(data->client);
+ if (ret < 0) {
+ dev_err(&data->client->dev,
+ "device initialize failed.\n");
+ goto err_initialize;
+ }
+
+ ret = elan_i2c_enable_absolute_mode(data->client);
+ if (ret < 0) {
+ dev_err(&data->client->dev,
+ "cannot switch to absolute mode.\n");
+ goto err_initialize;
+ }
+
+ ret = elan_i2c_wake_up(data->client);
+ if (ret < 0)
+ dev_err(&data->client->dev,
+ "device wake up failed.\n");
+ }
+err_initialize:
+ return ret;
+}
+
+
+/*
+ ******************************************************************
+ * Elan isr functions
+ ******************************************************************
+ */
+static int elan_check_packet(struct elan_tp_data *data, u8 *packet)
+{
+ u8 rid;
+
+ if (data->smbus)
+ rid = packet[0];
+ else
+ rid = packet[ETP_I2C_REPORT_ID_OFFSET];
+
+ /* check report id */
+ if (rid != ETP_REPORT_ID) {
+ dev_err(&data->client->dev, "report id [%x] fail.\n", rid);
+ return -1;
+ }
+ return 0;
+}
+
+static void elan_report_absolute(struct elan_tp_data *data, u8 *packet)
+{
+ struct input_dev *input = data->input;
+ u8 *finger_data;
+ bool finger_on;
+ int pos_x, pos_y;
+ int pressure, mk_x, mk_y;
+ int i, area_x, area_y, major, minor, new_pressure;
+ int finger_count = 0;
+ int btn_click;
+ u8 tp_info;
+
+ if (data->smbus) {
+ finger_data = &packet[ETP_SMBUS_FINGER_DATA_OFFSET];
+ tp_info = packet[1];
+ } else {
+ finger_data = &packet[ETP_I2C_FINGER_DATA_OFFSET];
+ tp_info = packet[3];
+ }
+
+ btn_click = (tp_info & 0x01);
+ for (i = 0; i < ETP_MAX_FINGERS; i++) {
+ finger_on = (tp_info >> (3 + i)) & 0x01;
+
+ /* analyze touched finger raw data*/
+ if (finger_on) {
+ pos_x = ((finger_data[0] & 0xf0) << 4) |
+ finger_data[1];
+ pos_y = ((finger_data[0] & 0x0f) << 8) |
+ finger_data[2];
+ pos_y = data->max_y - pos_y;
+ mk_x = (finger_data[3] & 0x0f);
+ mk_y = (finger_data[3] >> 4);
+ pressure = finger_data[4];
+
+ /*
+ * to avoid fat finger be as palm, so reduce the
+ * width x and y per trace
+ */
+ area_x = mk_x * (data->width_x - ETP_FWIDTH_REDUCE);
+ area_y = mk_y * (data->width_y - ETP_FWIDTH_REDUCE);
+
+ major = max(area_x, area_y);
+ minor = min(area_x, area_y);
+
+ new_pressure = pressure + ETP_PRESSURE_OFFSET;
+ if (new_pressure > ETP_MAX_PRESSURE)
+ new_pressure = ETP_MAX_PRESSURE;
+
+ input_mt_slot(input, i);
+ input_mt_report_slot_state(input, MT_TOOL_FINGER,
+ true);
+ input_report_abs(input, ABS_MT_POSITION_X, pos_x);
+ input_report_abs(input, ABS_MT_POSITION_Y, pos_y);
+ input_report_abs(input, ABS_MT_PRESSURE, new_pressure);
+ input_report_abs(input, ABS_TOOL_WIDTH, mk_x);
+ input_report_abs(input, ABS_MT_TOUCH_MAJOR, major);
+ input_report_abs(input, ABS_MT_TOUCH_MINOR, minor);
+ finger_data += ETP_FINGER_DATA_LEN;
+ finger_count++;
+ } else {
+ input_mt_slot(input, i);
+ input_mt_report_slot_state(input,
+ MT_TOOL_FINGER, false);
+ }
+ }
+
+ input_report_key(input, BTN_LEFT, (btn_click == 1));
+ input_mt_report_pointer_emulation(input, true);
+ input_sync(input);
+}
+
+static irqreturn_t elan_isr(int irq, void *dev_id)
+{
+ struct elan_tp_data *data = dev_id;
+ u8 raw[ETP_MAX_REPORT_LEN];
+ int retval;
+ int report_len;
+
+ if (data->smbus) {
+ report_len = ETP_SMBUS_REPORT_LEN;
+ retval = i2c_smbus_read_block_data(data->client,
+ ETP_SMBUS_PACKET_QUERY,
+ raw);
+ } else {
+ report_len = ETP_I2C_REPORT_LEN;
+ retval = i2c_master_recv(data->client, raw, report_len);
+ }
+
+ if (retval != report_len) {
+ dev_err(&data->client->dev, "wrong packet len(%d)", retval);
+ goto elan_isr_end;
+ }
+
+ if (elan_check_packet(data, raw) < 0) {
+ dev_err(&data->client->dev, "wrong packet format.");
+ goto elan_isr_end;
+ }
+ elan_report_absolute(data, raw);
+
+elan_isr_end:
+ return IRQ_HANDLED;
+}
+
+/*
+ ******************************************************************
+ * Elan initial functions
+ ******************************************************************
+ */
+static int elan_input_dev_create(struct elan_tp_data *data)
+{
+ struct i2c_client *client = data->client;
+ struct input_dev *input;
+ unsigned int x_res, y_res;
+ int ret, max_width, min_width;
+
+ data->input = input = input_allocate_device();
+ if (!input)
+ return -ENOMEM;
+ input->name = "Elan Touchpad";
+ input->id.bustype = BUS_I2C;
+ input->dev.parent = &data->client->dev;
+
+ __set_bit(EV_ABS, input->evbit);
+ __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
+ __set_bit(BTN_LEFT, input->keybit);
+
+ data->unique_id = elan_get_unique_id(data);
+ data->fw_version = elan_get_fw_version(data);
+ data->sm_version = elan_get_sm_version(data);
+ data->iap_version = elan_get_iap_version(data);
+ data->max_x = elan_get_x_max(data);
+ data->max_y = elan_get_y_max(data);
+ data->width_x = data->max_x / elan_get_x_tracenum(data);
+ data->width_y = data->max_y / elan_get_y_tracenum(data);
+ x_res = elan_get_x_resolution(data);
+ y_res = elan_get_y_resolution(data);
+ max_width = max(data->width_x, data->width_y);
+ min_width = min(data->width_x, data->width_y);
+
+ dev_dbg(&client->dev,
+ "Elan Touchpad Information:\n"
+ " Module unique ID: 0x%04x\n"
+ " Firmware Version: 0x%04x\n"
+ " Sample Version: 0x%04x\n"
+ " IAP Version: 0x%04x\n"
+ " Max ABS X,Y: %d,%d\n"
+ " Width X,Y: %d,%d\n"
+ " Resolution X,Y: %d,%d (dots/mm)\n",
+ data->unique_id,
+ data->fw_version,
+ data->sm_version,
+ data->iap_version,
+ data->max_x, data->max_y,
+ data->width_x, data->width_y,
+ x_res, y_res);
+
+ input_set_abs_params(input, ABS_X, 0, data->max_x, 0, 0);
+ input_set_abs_params(input, ABS_Y, 0, data->max_y, 0, 0);
+ input_abs_set_res(input, ABS_X, x_res);
+ input_abs_set_res(input, ABS_Y, y_res);
+ input_set_abs_params(input, ABS_PRESSURE, 0, ETP_MAX_PRESSURE, 0, 0);
+ input_set_abs_params(input, ABS_TOOL_WIDTH, 0, ETP_FINGER_WIDTH, 0, 0);
+
+ /* handle pointer emulation and unused slots in core */
+ ret = input_mt_init_slots(input, ETP_MAX_FINGERS,
+ INPUT_MT_POINTER | INPUT_MT_DROP_UNUSED);
+ if (ret) {
+ dev_err(&client->dev, "allocate MT slots failed, %d\n", ret);
+ goto err_free_device;
+ }
+ input_set_abs_params(input, ABS_MT_POSITION_X, 0, data->max_x, 0, 0);
+ input_set_abs_params(input, ABS_MT_POSITION_Y, 0, data->max_y, 0, 0);
+ input_abs_set_res(input, ABS_MT_POSITION_X, x_res);
+ input_abs_set_res(input, ABS_MT_POSITION_Y, y_res);
+ input_set_abs_params(input, ABS_MT_PRESSURE, 0,
+ ETP_MAX_PRESSURE, 0, 0);
+ input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0,
+ ETP_FINGER_WIDTH * max_width, 0, 0);
+ input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0,
+ ETP_FINGER_WIDTH * min_width, 0, 0);
+
+ /* Register the device in input subsystem */
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(&client->dev, "input_dev register failed, %d\n", ret);
+ goto err_free_device;
+ }
+
+ return 0;
+
+err_free_device:
+ input_free_device(input);
+ return ret;
+}
+
+static u8 elan_check_adapter_functionality(struct i2c_client *client)
+{
+ u8 ret = ELAN_ADAPTER_FUNC_NONE;
+
+ if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
+ ret |= ELAN_ADAPTER_FUNC_I2C;
+ if (i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_BLOCK_DATA |
+ I2C_FUNC_SMBUS_I2C_BLOCK))
+ ret |= ELAN_ADAPTER_FUNC_SMBUS;
+ return ret;
+}
+
+static int elan_probe(struct i2c_client *client,
+ const struct i2c_device_id *dev_id)
+{
+ struct elan_tp_data *data;
+ int ret;
+ u8 adapter_func;
+ union i2c_smbus_data dummy;
+ struct device *dev = &client->dev;
+
+ adapter_func = elan_check_adapter_functionality(client);
+ if (adapter_func == ELAN_ADAPTER_FUNC_NONE) {
+ dev_err(dev, "not a supported I2C/SMBus adapter\n");
+ return -EIO;
+ }
+
+ /* Make sure there is something at this address */
+ if (i2c_smbus_xfer(client->adapter, client->addr, 0,
+ I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &dummy) < 0)
+ return -ENODEV;
+
+ data = kzalloc(sizeof(struct elan_tp_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* check protocol type */
+ if (adapter_func == ELAN_ADAPTER_FUNC_SMBUS)
+ data->smbus = true;
+ else
+ data->smbus = false;
+ data->client = client;
+ data->irq = client->irq;
+
+ ret = request_threaded_irq(client->irq, NULL, elan_isr,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ client->name, data);
+ if (ret < 0) {
+ dev_err(&client->dev, "cannot register irq=%d\n",
+ client->irq);
+ goto err_irq;
+ }
+
+ /* initial elan touch pad */
+ ret = elan_initialize(data);
+ if (ret < 0)
+ goto err_init;
+
+ /* create input device */
+ ret = elan_input_dev_create(data);
+ if (ret < 0)
+ goto err_input_dev;
+
+ device_init_wakeup(&client->dev, 1);
+ i2c_set_clientdata(client, data);
+ return 0;
+
+err_input_dev:
+err_init:
+ free_irq(data->irq, data);
+err_irq:
+ kfree(data);
+ dev_err(&client->dev, "Elan Trackpad probe fail!\n");
+ return ret;
+}
+
+static int elan_remove(struct i2c_client *client)
+{
+ struct elan_tp_data *data = i2c_get_clientdata(client);
+ free_irq(data->irq, data);
+ input_unregister_device(data->input);
+ kfree(data);
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int elan_suspend(struct device *dev)
+{
+ int ret = 0;
+ struct elan_tp_data *data = dev_get_drvdata(dev);
+
+ disable_irq(data->irq);
+ if (data->smbus)
+ ret = i2c_smbus_write_byte(data->client,
+ ETP_SMBUS_SLEEP_CMD);
+ else
+ ret = elan_i2c_sleep(data->client);
+
+ if (ret < 0)
+ dev_err(dev, "suspend mode failed, %d\n", ret);
+
+ return ret;
+}
+
+static int elan_resume(struct device *dev)
+{
+ int ret = 0;
+ struct elan_tp_data *data = dev_get_drvdata(dev);
+
+ ret = elan_initialize(data);
+ if (ret < 0)
+ dev_err(dev, "resume active power failed, %d\n", ret);
+
+ enable_irq(data->irq);
+ return ret;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(elan_pm_ops, elan_suspend, elan_resume);
+
+static const struct i2c_device_id elan_id[] = {
+ { DRIVER_NAME, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, elan_id);
+
+static struct i2c_driver elan_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .owner = THIS_MODULE,
+ .pm = &elan_pm_ops,
+ },
+ .probe = elan_probe,
+ .remove = elan_remove,
+ .id_table = elan_id,
+};
+
+module_i2c_driver(elan_driver);
+
+MODULE_AUTHOR("Duson Lin <dusonlin@emc.com.tw>");
+MODULE_DESCRIPTION("Elan I2C/SMBus Touchpad driver");
+MODULE_LICENSE("GPL");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
From: Dmitry Torokhov @ 2014-01-07 7:14 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: linux-input, linux-kernel
In-Reply-To: <20140104054133.GC32576@core.coreip.homeip.net>
On Fri, Jan 03, 2014 at 09:41:33PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 03, 2014 at 09:03:11PM -0800, Andrey Smirnov wrote:
> > On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote:
> > >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov
> > >> <dmitry.torokhov@gmail.com> wrote:
> > >> > Hi Andrey,
> > >> >
> > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote:
> > >> >> New version of the PCU firmware supports two new commands:
> > >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the
> > >> >> registers of one finger navigation(OFN) chip present on the device
> > >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the
> > >> >> registers of said chip.
> > >> >>
> > >> >> This commit adds two helper functions to use those commands and sysfs
> > >> >> attributes to use them. It also exposes some OFN configuration
> > >> >> parameters via sysfs.
> > >> >
> > >> > Thank you for making the changes. I do not still quite like the games we
> > >> > play with the OFN attributes, how about the patch below (on top of
> > >> > yours)?
> > >> >
> > >>
> > >> Yeah, I agree I like it the "two separate sysfs groups" group approach
> > >> better. The only small nitpick about your patch is that I think we
> > >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case
> > >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)).
> > >> Let me test it and if everything works as expected I'll apply you
> > >> patch, convert it to "get_unaligned_le16", squash and send v3 of the
> > >> patch.
> > >
> > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is
> > > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary.
> >
> > * The "pcu" structure is allocated with kmalloc which doesn't give any
> > guarantees about address alignment.
> > * I am not sure if the cmd_buf field in that structure is aligned, and
> > even if it is, any future changes to that structure may shift its
> > offset.
> > * Also even if the data we are interested in is aligned on 2-byte
> > border, I think all those architectures require 4-byte border
> > alignment.
>
> As far as I know word access only requires word alignment. Please see
> the other patch I just posted that adds alignment check in balcklight
> handling code.
Andrey, were you able to test the patch?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: am335x: IIO/ADC fixes if used together with TSC, v2
From: Lee Jones @ 2014-01-07 8:54 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Samuel Ortiz, Jonathan Cameron, Dmitry Torokhov, Zubair Lutfullah,
Felipe Balbi, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1387466911-3732-1-git-send-email-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Dmitry, Jonathan,
This is for you.
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.linaro.org/people/ljones/mfd.git tags/ib-iio-input-3.13-1
for you to fetch changes up to 7ca6740cd1cd410828a01151a044b51910d06eff:
mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization (2014-01-07 08:45:00 +0000)
----------------------------------------------------------------
Immutable branch for IIO and Input
----------------------------------------------------------------
Sebastian Andrzej Siewior (5):
iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()
mfd: ti_am335x_tscadc: Make am335x_tsc_se_update() local
mfd: ti_am335x_tscadc: Don't read back REG_SE
mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path
mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization
drivers/iio/adc/ti_am335x_adc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------
drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++--
drivers/mfd/ti_am335x_tscadc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
include/linux/mfd/ti_am335x_tscadc.h | 8 ++++++--
4 files changed, 117 insertions(+), 34 deletions(-)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-01-07 12:11 UTC (permalink / raw)
To: David Herrmann
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <CANq1E4TOHvb3--H6SoRhB09sUwuYkrvSAXCNN2Y0PaVSOEte=w@mail.gmail.com>
On Fri, 27 Dec 2013, David Herrmann wrote:
> >> I also haven't figured out a nice way to make HID-core honor the
> >> "size" parameter. hid-input depends on getting the whole
> >> input-report.
> >
> > I think this needs clearly fixing.
>
> And we have a volunteer, yippie! ;)
>
> I think hid_input_report() in hid-core.c is the only place that relies
> on this. Maybe it really is easier to fix it. But I am not even
> slightly familiar with that code. So if no-one of the HID core
> developers steps up to fix it, we should take the transport-driver
> fixes instead. As nearly all transport-drivers are affected by this,
> maybe we should even move this buffer into hid_device and provide
> hid_input_truncated_report() which does this.
>
> Anyhow, waiting for Jiri's comments on this.
Hmm, this is really unfortunate situation.
I am now looking into making hid_input_report() honor 'size' properly, but
no matter how it'll be done in the end, it'll absolutely not be a simple
'fix'. So definitely can be done for 3.15 or so, but not as a fix for
current kernels.
So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
the buffer around, seems like only viable solution for now, with the
outlook of removing this ugliness once hid-core honors 'size' properly.
I will keep looking into this and maybe some easy way how to hack this
together will materialize, but I don't currently see it.
Hmm ...
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Patch from down stream which has been forgotten
From: Jonathan Aquilina @ 2014-01-07 13:56 UTC (permalink / raw)
To: linux-input
I have a down stream bug from ubuntu which has been forgotten.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399
This fixes multitouch track pads issue where the track pad doesnt work at all.
Can I get an update as to the status of the patch which was upstreamed.
Thanks
Jonathan
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Tommy Will @ 2014-01-07 16:24 UTC (permalink / raw)
To: Chris Diamand, Dmitry Torokhov, Kevin Cernekee, Yunkang Tang,
david turvene
Cc: linux-input
In-Reply-To: <CAKvfdtK18rQ4TOqwKCj1P3oQs-BQZr2h3db5NH18WdtNjjnH=g@mail.gmail.com>
Hi Chris,
> This is the touchpad used on the Dell Vostro 3360. Without
> this change, the driver reports this as follows:
> psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 02 02
> It seems to use the ALPS V5 protocol, so identify it
> as such by allowing ec[1] == 0x02.
> This is based on src/alps.c from the DKMS driver here:
> http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/
Thanks for your patch!
Umm, however, I had submited a similar patch for supporting dolphin v2
device last month and it was now applied into latest mainline. Detail
please check the source code in below link.
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
Thanks
--
Best Regards,
Tommy
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: David Herrmann @ 2014-01-07 16:34 UTC (permalink / raw)
To: Jiri Kosina
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <alpine.LNX.2.00.1401071308020.4962@pobox.suse.cz>
Hi Jiri
On Tue, Jan 7, 2014 at 1:11 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 27 Dec 2013, David Herrmann wrote:
>
>> >> I also haven't figured out a nice way to make HID-core honor the
>> >> "size" parameter. hid-input depends on getting the whole
>> >> input-report.
>> >
>> > I think this needs clearly fixing.
>>
>> And we have a volunteer, yippie! ;)
>>
>> I think hid_input_report() in hid-core.c is the only place that relies
>> on this. Maybe it really is easier to fix it. But I am not even
>> slightly familiar with that code. So if no-one of the HID core
>> developers steps up to fix it, we should take the transport-driver
>> fixes instead. As nearly all transport-drivers are affected by this,
>> maybe we should even move this buffer into hid_device and provide
>> hid_input_truncated_report() which does this.
>>
>> Anyhow, waiting for Jiri's comments on this.
>
> Hmm, this is really unfortunate situation.
>
> I am now looking into making hid_input_report() honor 'size' properly, but
> no matter how it'll be done in the end, it'll absolutely not be a simple
> 'fix'. So definitely can be done for 3.15 or so, but not as a fix for
> current kernels.
>
> So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
> the buffer around, seems like only viable solution for now, with the
> outlook of removing this ugliness once hid-core honors 'size' properly.
Should I resend the patches and move it to hid_input_report() for now?
Or are you getting something in yourself?
Given the amount of reports on the list and bugzilla, I think we
should get this fix in asap. We can always fix it properly in -next.
Thanks
David
> I will keep looking into this and maybe some easy way how to hack this
> together will materialize, but I don't currently see it.
>
> Hmm ...
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-01-07 17:13 UTC (permalink / raw)
To: David Herrmann
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <CANq1E4SxrDnbOCsohZXYoYL-HQjEc-xcOnXfAm=npHG2QfMS9A@mail.gmail.com>
On Tue, 7 Jan 2014, David Herrmann wrote:
> > So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
> > the buffer around, seems like only viable solution for now, with the
> > outlook of removing this ugliness once hid-core honors 'size' properly.
>
> Should I resend the patches and move it to hid_input_report() for now?
> Or are you getting something in yourself?
Due to various reasons I will not have access to any testing HW for the
upcoming 2-3 days, so if you can cook something up in that timeframe, it'd
be appreciated.
Otherwise I'll be working on it by the end of this week.
> Given the amount of reports on the list and bugzilla, I think we should
> get this fix in asap. We can always fix it properly in -next.
Agreed.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Chris Diamand @ 2014-01-07 18:30 UTC (permalink / raw)
To: Tommy Will
Cc: Dmitry Torokhov, Kevin Cernekee, Yunkang Tang, david turvene,
linux-input
In-Reply-To: <CA+F6ckNx8nxjtXLrgzYyNUBnnmb09tFx8zSe=y0JxtMiVrTooQ@mail.gmail.com>
Hi, and thanks for your reply.
> Umm, however, I had submited a similar patch for supporting dolphin v2
> device last month and it was now applied into latest mainline.
Do you mean commit 'ee65d4...add support for "Dolphin" devices'?
It's in the dtor/input.git kernel but I don't think it's been merged
into mainline (torvalds/linux.git).
Running 'git log drivers/input/mouse/alps.c' with the latest mainline
kernel shows the last commit as '95f75e...add support for DualPoint
device on Dell XT2 model', which doesn't work with my device (Dell
Vostro 3360).
Are there any plans for it to be merged? It looks like your patch fixes
it much better than mine ;)
Regards,
Chris
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Dmitry Torokhov @ 2014-01-07 18:59 UTC (permalink / raw)
To: Chris Diamand
Cc: Tommy Will, Kevin Cernekee, Yunkang Tang, david turvene,
linux-input
In-Reply-To: <52CC47C5.4090307@diamand.org>
Hi Chris,
On Tue, Jan 07, 2014 at 06:30:29PM +0000, Chris Diamand wrote:
> Hi, and thanks for your reply.
>
> >Umm, however, I had submited a similar patch for supporting dolphin v2
> >device last month and it was now applied into latest mainline.
>
> Do you mean commit 'ee65d4...add support for "Dolphin" devices'?
>
> It's in the dtor/input.git kernel but I don't think it's been merged
> into mainline (torvalds/linux.git).
>
> Running 'git log drivers/input/mouse/alps.c' with the latest
> mainline kernel shows the last commit as '95f75e...add support for
> DualPoint device on Dell XT2 model', which doesn't work with my
> device (Dell Vostro 3360).
>
> Are there any plans for it to be merged? It looks like your patch
> fixes it much better than mine ;)
Yes, it will be merged together with all other changes to the input
subsystem when the next merge window opens.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
From: Andrey Smirnov @ 2014-01-07 19:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20140107071436.GB20074@core.coreip.homeip.net>
Sorry, haven't had the chance yet. I'll try to do this and hopefully
send v3 of the patch by the end of this week
On Mon, Jan 6, 2014 at 11:14 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Fri, Jan 03, 2014 at 09:41:33PM -0800, Dmitry Torokhov wrote:
>> On Fri, Jan 03, 2014 at 09:03:11PM -0800, Andrey Smirnov wrote:
>> > On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov
>> > <dmitry.torokhov@gmail.com> wrote:
>> > > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote:
>> > >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov
>> > >> <dmitry.torokhov@gmail.com> wrote:
>> > >> > Hi Andrey,
>> > >> >
>> > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote:
>> > >> >> New version of the PCU firmware supports two new commands:
>> > >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the
>> > >> >> registers of one finger navigation(OFN) chip present on the device
>> > >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the
>> > >> >> registers of said chip.
>> > >> >>
>> > >> >> This commit adds two helper functions to use those commands and sysfs
>> > >> >> attributes to use them. It also exposes some OFN configuration
>> > >> >> parameters via sysfs.
>> > >> >
>> > >> > Thank you for making the changes. I do not still quite like the games we
>> > >> > play with the OFN attributes, how about the patch below (on top of
>> > >> > yours)?
>> > >> >
>> > >>
>> > >> Yeah, I agree I like it the "two separate sysfs groups" group approach
>> > >> better. The only small nitpick about your patch is that I think we
>> > >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case
>> > >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)).
>> > >> Let me test it and if everything works as expected I'll apply you
>> > >> patch, convert it to "get_unaligned_le16", squash and send v3 of the
>> > >> patch.
>> > >
>> > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is
>> > > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary.
>> >
>> > * The "pcu" structure is allocated with kmalloc which doesn't give any
>> > guarantees about address alignment.
>> > * I am not sure if the cmd_buf field in that structure is aligned, and
>> > even if it is, any future changes to that structure may shift its
>> > offset.
>> > * Also even if the data we are interested in is aligned on 2-byte
>> > border, I think all those architectures require 4-byte border
>> > alignment.
>>
>> As far as I know word access only requires word alignment. Please see
>> the other patch I just posted that adds alignment check in balcklight
>> handling code.
>
> Andrey, were you able to test the patch?
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH] input synaptics-rmi4: PDT scan cleanup
From: Christopher Heiny @ 2014-01-07 20:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
Eliminates copy-paste code that handled scans of the Page Descriptor Table,
replacing it with a single PDT scan routine that invokes a callback function.
The scan routine is not static so that it can be used by the firmware update
code (under development, not yet submitted).
Updated the copyright dates while we were at it.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_driver.c | 155 ++++++++++++++++++++--------------------
drivers/input/rmi4/rmi_driver.h | 6 +-
2 files changed, 83 insertions(+), 78 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index eb790ff..cbd6485 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This driver provides the core support for a single RMI4-based device.
@@ -566,85 +566,80 @@ err_free_mem:
return error;
}
-/*
- * Scan the PDT for F01 so we can force a reset before anything else
- * is done. This forces the sensor into a known state, and also
- * forces application of any pending updates from reflashing the
- * firmware or configuration.
- *
- * We have to do this before actually building the PDT because the reflash
- * updates (if any) might cause various registers to move around.
- */
-static int rmi_initial_reset(struct rmi_device *rmi_dev)
+
+#define RMI_SCAN_CONTINUE 0
+#define RMI_SCAN_DONE 1
+
+static int rmi_initial_reset(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *pdt_entry, int page)
{
- struct pdt_entry pdt_entry;
- int page;
- struct device *dev = &rmi_dev->dev;
- bool done = false;
- bool has_f01 = false;
- int i;
int retval;
- const struct rmi_device_platform_data *pdata =
- to_rmi_platform_data(rmi_dev);
- dev_dbg(dev, "Initial reset.\n");
+ if (pdt_entry->function_number == 0x01) {
+ u16 cmd_addr = page + pdt_entry->command_base_addr;
+ u8 cmd_buf = RMI_DEVICE_RESET_CMD;
+ const struct rmi_device_platform_data *pdata =
+ to_rmi_platform_data(rmi_dev);
- for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
- u16 page_start = RMI4_PAGE_SIZE * page;
- u16 pdt_start = page_start + PDT_START_SCAN_LOCATION;
- u16 pdt_end = page_start + PDT_END_SCAN_LOCATION;
+ retval = rmi_write_block(rmi_dev, cmd_addr, &cmd_buf, 1);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "Initial reset failed. Code = %d.\n", retval);
+ return retval;
+ }
+ mdelay(pdata->reset_delay_ms);
- done = true;
- for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
- retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
- if (retval < 0)
- return retval;
+ return RMI_SCAN_DONE;
+ }
- if (RMI4_END_OF_PDT(pdt_entry.function_number))
- break;
- done = false;
+ /* F01 should always be on page 0. If we don't find it there, fail. */
+ return (!page) ? RMI_SCAN_CONTINUE : -ENODEV;
+}
- if (pdt_entry.function_number == 0x01) {
- u16 cmd_addr = page_start +
- pdt_entry.command_base_addr;
- u8 cmd_buf = RMI_DEVICE_RESET_CMD;
- retval = rmi_write_block(rmi_dev, cmd_addr,
- &cmd_buf, 1);
- if (retval < 0) {
- dev_err(dev, "Initial reset failed. Code = %d.\n",
- retval);
- return retval;
- }
- mdelay(pdata->reset_delay_ms);
- done = true;
- has_f01 = true;
- break;
- }
- }
- }
+static int rmi_create_functions_clbk(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page)
+{
+ int *irq_count = (int *)clbk_ctx;
- if (!has_f01) {
- dev_warn(dev, "WARNING: Failed to find F01 for initial reset.\n");
- return -ENODEV;
- }
+ return create_function(rmi_dev, entry, irq_count,
+ RMI4_PAGE_SIZE * page);
+}
+
+static int rmi_create_functions(struct rmi_device *rmi_dev)
+{
+ struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
+ struct device *dev = &rmi_dev->dev;
+ int irq_count = 0;
+ int retval;
+
+ // XXX need to make sure we create F01 first...
+ // XXX or do we? It might not be required in the updated structure.
+ retval = rmi_scan_pdt(rmi_dev, &irq_count, rmi_create_functions_clbk);
+
+ if (retval)
+ return retval;
+
+ // TODO: I think we need to count the IRQs before creating the
+ // functions.
+ data->irq_count = irq_count;
+ data->num_of_irq_regs = (irq_count + 7) / 8;
return 0;
}
-static int rmi_scan_pdt(struct rmi_device *rmi_dev)
+int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
+ int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page))
{
- struct rmi_driver_data *data;
+ struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
struct pdt_entry pdt_entry;
int page;
- struct device *dev = &rmi_dev->dev;
- int irq_count = 0;
- bool done = false;
int i;
- int retval;
-
- dev_dbg(dev, "Scanning PDT...\n");
+ bool done = false;
+ int retval = 0;
- data = dev_get_drvdata(&rmi_dev->dev);
+ // TODO: With F01 and reflash as part of the core now, is this
+ // lock still required?
mutex_lock(&data->pdt_mutex);
for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
@@ -656,27 +651,27 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev)
for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
if (retval < 0)
- goto error_exit;
+ return retval;
if (RMI4_END_OF_PDT(pdt_entry.function_number))
break;
- dev_dbg(dev, "Found F%02X on page %#04x\n",
+ dev_dbg(&rmi_dev->dev, "Found F%02X on page %#04x\n",
pdt_entry.function_number, page);
done = false;
- // XXX need to make sure we create F01 first...
- retval = create_function(rmi_dev,
- &pdt_entry, &irq_count, page_start);
-
- if (retval)
+ retval = rmi_pdt_scan_clbk(rmi_dev, ctx,
+ &pdt_entry, page);
+ if (retval < 0) {
goto error_exit;
+ } else if (retval == RMI_SCAN_DONE) {
+ done = true;
+ break;
+ }
}
done = done || data->f01_bootloader_mode;
}
- data->irq_count = irq_count;
- data->num_of_irq_regs = (irq_count + 7) / 8;
- dev_dbg(dev, "%s: Done with PDT scan.\n", __func__);
+
retval = 0;
error_exit:
@@ -684,6 +679,7 @@ error_exit:
return retval;
}
+
#ifdef CONFIG_PM_SLEEP
static int rmi_driver_suspend(struct device *dev)
{
@@ -797,10 +793,15 @@ static int rmi_driver_probe(struct device *dev)
/*
* Right before a warm boot, the sensor might be in some unusual state,
- * such as F54 diagnostics, or F34 bootloader mode. In order to clear
- * the sensor to a known state, we issue a initial reset to clear any
+ * such as F54 diagnostics, or F34 bootloader mode after a firmware
+ * or configuration update. In order to clear the sensor to a known
+ * state and/or apply any updates, we issue a initial reset to clear any
* previous settings and force it into normal operation.
*
+ * We have to do this before actually building the PDT because
+ * the reflash updates (if any) might cause various registers to move
+ * around.
+ *
* For a number of reasons, this initial reset may fail to return
* within the specified time, but we'll still be able to bring up the
* driver normally after that failure. This occurs most commonly in
@@ -813,11 +814,11 @@ static int rmi_driver_probe(struct device *dev)
*/
if (!pdata->reset_delay_ms)
pdata->reset_delay_ms = DEFAULT_RESET_DELAY_MS;
- retval = rmi_initial_reset(rmi_dev);
+ retval = rmi_scan_pdt(rmi_dev, NULL, rmi_initial_reset);
if (retval)
dev_warn(dev, "RMI initial reset failed! Continuing in spite of this.\n");
- retval = rmi_scan_pdt(rmi_dev);
+ retval = rmi_create_functions(rmi_dev);
if (retval) {
dev_err(dev, "PDT scan for %s failed with code %d.\n",
pdata->sensor_name, retval);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index df9ddd8..f73be73 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -108,6 +108,10 @@ struct pdt_entry {
int rmi_read_pdt_entry(struct rmi_device *rmi_dev, struct pdt_entry *entry,
u16 pdt_address);
+int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
+ int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page));
+
bool rmi_is_physical_driver(struct device_driver *);
int rmi_register_physical_driver(void);
void rmi_unregister_physical_driver(void);
^ permalink raw reply related
* [PATCH] input synaptics-rmi4: Add rmi_version.h
From: Christopher Heiny @ 2014-01-07 21:37 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
Adds a file containing driver versioning #defines, allowing convenient
script-based tweakage of various versioning info. This is helpful to
differentiate various custom and/or development versions of the driver from
the main branch of the code.
Since rmi_driver.h changes as a result, its copyright date gets updated.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_driver.h | 5 ++---
drivers/input/rmi4/rmi_version.h | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index df9ddd8..4438b20 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -14,8 +14,7 @@
#include <linux/hrtimer.h>
#include <linux/ktime.h>
#include "rmi_bus.h"
-
-#define RMI_DRIVER_VERSION "1.6"
+#include "rmi_version.h"
#define SYNAPTICS_INPUT_DEVICE_NAME "Synaptics RMI4 Touch Sensor"
#define SYNAPTICS_VENDOR_ID 0x06cb
diff --git a/drivers/input/rmi4/rmi_version.h b/drivers/input/rmi4/rmi_version.h
new file mode 100644
index 0000000..ed001fa
--- /dev/null
+++ b/drivers/input/rmi4/rmi_version.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#ifndef RMI_VERSION_H
+#define RMI_VERSION_H
+
+#define RMI_VERSION_MAJOR "1"
+#define RMI_VERSION_MINOR "19"
+#define RMI_VERSION_SUBMINOR "0"
+
+#define RMI_VERSION_BRANCH "synaptics-rmi4"
+#define RMI_EXTRA_NUMBER "0"
+#define RMI_EXTRA_STRING "0"
+
+#define RMI_DRIVER_VERSION RMI_VERSION_MAJOR "." \
+ RMI_VERSION_MINOR "." RMI_VERSION_SUBMINOR "-" \
+ RMI_EXTRA_STRING
+
+#endif
^ permalink raw reply related
* [PATCH] input synaptics-rmi4 trivial: rmi_f01.c tidy-up
From: Christopher Heiny @ 2014-01-08 0:07 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
This has two trivial changes:
1) use CONFIG_PM_SLEEP instead of CONFIG_PM for consistency.
2) Update the copyright date.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_f01.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index 628b082..d547633 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -138,7 +138,7 @@ struct f01_data {
int irq_count;
int num_of_irq_regs;
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
bool suspended;
bool old_nosleep;
#endif
^ permalink raw reply related
* [PATCH] input synaptics-rmi4: move rmi_f01 query register parsing to its own function
From: Christopher Heiny @ 2014-01-08 1:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
In the near future, query register parsing is going to get a lot more
complicated. It's also going to be needed by the reflash code. Now is the
time to move this from the F01 initialization into its own function,
while the code is still fairly simple.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_f01.c | 71 +++++++++++++++++++++++++++-----------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index d547633..1cb11ea 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -167,6 +167,46 @@ static int rmi_f01_alloc_memory(struct rmi_function *fn,
return 0;
}
+static int rmi_f01_read_properties(struct rmi_device *rmi_dev,
+ u16 query_base_addr,
+ struct f01_basic_properties *props)
+{
+ u8 basic_query[RMI_F01_BASIC_QUERY_LEN];
+ int error;
+
+ error = rmi_read_block(rmi_dev, query_base_addr,
+ basic_query, sizeof(basic_query));
+ if (error < 0) {
+ dev_err(&rmi_dev->dev, "Failed to read device query registers.\n");
+ return error;
+ }
+
+ /* Now parse what we got */
+ props->manufacturer_id = basic_query[0];
+
+ props->has_lts = basic_query[1] & RMI_F01_QRY1_HAS_LTS;
+ props->has_adjustable_doze =
+ basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE;
+ props->has_adjustable_doze_holdoff =
+ basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE_HOFF;
+
+ snprintf(props->dom, sizeof(props->dom),
+ "20%02x%02x%02x",
+ basic_query[5] & RMI_F01_QRY5_YEAR_MASK,
+ basic_query[6] & RMI_F01_QRY6_MONTH_MASK,
+ basic_query[7] & RMI_F01_QRY7_DAY_MASK);
+
+ memcpy(props->product_id, &basic_query[11],
+ RMI_PRODUCT_ID_LENGTH);
+ props->product_id[RMI_PRODUCT_ID_LENGTH] = '\0';
+
+ props->productinfo =
+ ((basic_query[2] & RMI_F01_QRY2_PRODINFO_MASK) << 7) |
+ (basic_query[3] & RMI_F01_QRY2_PRODINFO_MASK);
+
+ return 0;
+}
+
static int rmi_f01_initialize(struct rmi_function *fn)
{
u8 temp;
@@ -176,7 +216,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
struct rmi_driver_data *driver_data = dev_get_drvdata(&rmi_dev->dev);
struct f01_data *data = fn->data;
struct rmi_device_platform_data *pdata = to_rmi_platform_data(rmi_dev);
- u8 basic_query[RMI_F01_BASIC_QUERY_LEN];
mutex_init(&data->control_mutex);
@@ -248,36 +287,12 @@ static int rmi_f01_initialize(struct rmi_function *fn)
return error;
}
- error = rmi_read_block(rmi_dev, fn->fd.query_base_addr,
- basic_query, sizeof(basic_query));
+ error = rmi_f01_read_properties(rmi_dev, fn->fd.query_base_addr,
+ &data->properties);
if (error < 0) {
- dev_err(&fn->dev, "Failed to read device query registers.\n");
+ dev_err(&fn->dev, "Failed to read F01 properties.\n");
return error;
}
-
- /* Now parse what we got */
- data->properties.manufacturer_id = basic_query[0];
-
- data->properties.has_lts = basic_query[1] & RMI_F01_QRY1_HAS_LTS;
- data->properties.has_adjustable_doze =
- basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE;
- data->properties.has_adjustable_doze_holdoff =
- basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE_HOFF;
-
- snprintf(data->properties.dom, sizeof(data->properties.dom),
- "20%02x%02x%02x",
- basic_query[5] & RMI_F01_QRY5_YEAR_MASK,
- basic_query[6] & RMI_F01_QRY6_MONTH_MASK,
- basic_query[7] & RMI_F01_QRY7_DAY_MASK);
-
- memcpy(data->properties.product_id, &basic_query[11],
- RMI_PRODUCT_ID_LENGTH);
- data->properties.product_id[RMI_PRODUCT_ID_LENGTH] = '\0';
-
- data->properties.productinfo =
- ((basic_query[2] & RMI_F01_QRY2_PRODINFO_MASK) << 7) |
- (basic_query[3] & RMI_F01_QRY2_PRODINFO_MASK);
-
dev_info(&fn->dev, "found RMI device, manufacturer: %s, product: %s\n",
data->properties.manufacturer_id == 1 ?
"Synaptics" : "unknown",
^ permalink raw reply related
* Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 7:57 UTC (permalink / raw)
To: linux-input, linux-arm-kernel@lists.infradead.org; +Cc: Joonyoung Shim
Hello,
I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
board. The capacitive glass used is a "GE Touch"
SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
correctly detected (with one warning/error).
The power supply of VDD and AVDD is 2.8V. AVDD will be raised later to 3.3V.
When I push on glass, nothing occurs in evetst nor on /CHG pin of MXT224.
Does someone has some informations or the protocol guide, please ?
Thanks a lot for your help.
Gaëtan Carlier.
Below some code and logs.
Here is my initialization :
8---------------------------------------------------------
/* TSP */
static struct mxt_platform_data mxt_platform_data = {
.x_line = 18,
.y_line = 11,
.x_size = 480,
.y_size = 640,
.blen = 0x1,
.threshold = 0x28,
.voltage = 2800000, /* 2.8V */
.orient = MXT_DIAGONAL_COUNTER,
.irqflags = IRQF_TRIGGER_FALLING,
};
static struct i2c_board_info imx27gc_i2c0_devices[] = {
{
I2C_BOARD_INFO("atmel_mxt_ts", 0x4b),
.platform_data = &mxt_platform_data,
/* irq number is run-time assigned */
},
/* more devices can be added using expansion connectors */
};
static void __init dvip01_init(void)
{
dvip01_i2c0_devices[0].irq = gpio_to_irq(MXT_KEY);
}
8---------------------------------------------------------
Here is log of start-up:
8---------------------------------------------------------
atmel_mxt_ts 0-004b: Type 37 Start 106 Size 130 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 44 Start 236 Size 1 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 5 Start 237 Size 9 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 6 Start 246 Size 6 Instances 1 ReportIDs
1 : 1
atmel_mxt_ts 0-004b: Type 38 Start 252 Size 8 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 7 Start 260 Size 3 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 8 Start 263 Size 10 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 9 Start 273 Size 35 Instances 1 ReportIDs
2 : 11
atmel_mxt_ts 0-004b: Type 18 Start 308 Size 2 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 19 Start 310 Size 6 Instances 1 ReportIDs
12 : 12
atmel_mxt_ts 0-004b: Type 25 Start 316 Size 6 Instances 1 ReportIDs
13 : 13
atmel_mxt_ts 0-004b: Type 42 Start 322 Size 8 Instances 1 ReportIDs
14 : 14
atmel_mxt_ts 0-004b: Type 46 Start 330 Size 9 Instances 1 ReportIDs
15 : 15
atmel_mxt_ts 0-004b: Type 47 Start 339 Size 10 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 48 Start 349 Size 54 Instances 1 ReportIDs
16 : 16
atmel_mxt_ts 0-004b: Type 55 Start 403 Size 4 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: No cfg data defined, skipping reg init
atmel_mxt_ts 0-004b: Invalid object type
atmel_mxt_ts 0-004b: Family ID: 129 Variant ID: 1 Major.Minor.Build: 2.0.AB
atmel_mxt_ts 0-004b: Matrix X Size: 16 Matrix Y Size: 14 Object Num: 16
input: Atmel maXTouch Touchscreen as
/devices/platform/imx-i2c.0/i2c-0/0-004b/input/input0
8---------------------------------------------------------
Here is evtest information :
8---------------------------------------------------------
Input driver version is 1.0.1evdev: (EVIOCGBIT): Suspicious buffer size
511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtorl
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "Atmel maXTouch Touchscreen"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 330 (Touch)
Event type 3 (Absolute)
Event code 0 (X)
Value 0
Min 0
Max 479
Event code 1 (Y)
Value 0
Min 0
Max 639
Event code 24 (Pressure)
Value 0
Min 0
Max 255
Event code 47 (?)
Value 0
Min 0
Max 9
Event code 48 (?)
Value 0
Min 0
Max 255
Event code 53 (?)
Value 0
Min 0
Max 479
Event code 54 (?)
Value 0
Min 0
Max 639
Event code 57 (?)
Value 0
Min 0
Max 65535
Event code 58 (?)
Value 0
Min 0
Max 255
Testing ... (interrupt to exit)
8---------------------------------------------------------
Here is /proc/interrupts:
8---------------------------------------------------------
128: 0 gpio-mxc atmel_mxt_ts
8---------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: am335x: IIO/ADC fixes if used together with TSC, v2
From: Dmitry Torokhov @ 2014-01-08 8:03 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Andrzej Siewior, Samuel Ortiz, Jonathan Cameron,
Zubair Lutfullah, Felipe Balbi, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140107085456.GD3182@lee--X1>
On Tue, Jan 07, 2014 at 08:54:56AM +0000, Lee Jones wrote:
> Dmitry, Jonathan,
>
> This is for you.
>
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/ljones/mfd.git tags/ib-iio-input-3.13-1
>
> for you to fetch changes up to 7ca6740cd1cd410828a01151a044b51910d06eff:
>
> mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization (2014-01-07 08:45:00 +0000)
>
> ----------------------------------------------------------------
> Immutable branch for IIO and Input
>
> ----------------------------------------------------------------
> Sebastian Andrzej Siewior (5):
> iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()
> mfd: ti_am335x_tscadc: Make am335x_tsc_se_update() local
> mfd: ti_am335x_tscadc: Don't read back REG_SE
> mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path
> mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization
>
> drivers/iio/adc/ti_am335x_adc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------
> drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++--
> drivers/mfd/ti_am335x_tscadc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
> include/linux/mfd/ti_am335x_tscadc.h | 8 ++++++--
> 4 files changed, 117 insertions(+), 34 deletions(-)
I do not have any pending changes to ti_am335x_tsc.c so it can all go
through Jonathan's tree.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: am335x: IIO/ADC fixes if used together with TSC, v2
From: Lee Jones @ 2014-01-08 8:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Sebastian Andrzej Siewior, Samuel Ortiz, Jonathan Cameron,
Zubair Lutfullah, Felipe Balbi, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140108080359.GA16527-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
> > Dmitry, Jonathan,
> >
> > This is for you.
> >
> > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
> >
> > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.linaro.org/people/ljones/mfd.git tags/ib-iio-input-3.13-1
> >
> > for you to fetch changes up to 7ca6740cd1cd410828a01151a044b51910d06eff:
> >
> > mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization (2014-01-07 08:45:00 +0000)
> >
> > ----------------------------------------------------------------
> > Immutable branch for IIO and Input
> >
> > ----------------------------------------------------------------
> > Sebastian Andrzej Siewior (5):
> > iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()
> > mfd: ti_am335x_tscadc: Make am335x_tsc_se_update() local
> > mfd: ti_am335x_tscadc: Don't read back REG_SE
> > mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path
> > mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization
> >
> > drivers/iio/adc/ti_am335x_adc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------
> > drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++--
> > drivers/mfd/ti_am335x_tscadc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
> > include/linux/mfd/ti_am335x_tscadc.h | 8 ++++++--
> > 4 files changed, 117 insertions(+), 34 deletions(-)
>
> I do not have any pending changes to ti_am335x_tsc.c so it can all go
> through Jonathan's tree.
Well the patches are going through my tree, but in case either of you
have any changes to the above files you can merge this and Git will do
the rest during the merge-window. If neither of you do then no need to
pull. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Alexander Shiyan @ 2014-01-08 9:04 UTC (permalink / raw)
To: Gaëtan Carlier
Cc: Joonyoung Shim, linux-arm-kernel@lists.infradead.org, linux-input
In-Reply-To: <52CD04F1.8090100@gmail.com>
Среда, 8 января 2014, 8:57 +01:00 от Gaëtan Carlier <gcembed@gmail.com>:
> Hello,
> I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
> driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
> board. The capacitive glass used is a "GE Touch"
> SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
> correctly detected (with one warning/error).
> The power supply of VDD and AVDD is 2.8V. AVDD will be raised later to 3.3V.
> When I push on glass, nothing occurs in evetst nor on /CHG pin of MXT224.
Do not forget about setup IOMUX for IRQ pin?
---
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 11:24 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <1389171897.588258801@f329.i.mail.ru>
Hi,
On 01/08/2014 10:04 AM, Alexander Shiyan wrote:
> Do not forget about setup IOMUX for IRQ pin?
I don't think so. I follow the same canvas than PMIC_INT. I send my
email too fast. The init function was incomplete. Below all I do with
MXT_KEY (PB16) connected to /CHG pin of MXT224.
(Of course, PB16 (CSI_PIXCLK) is not used by another driver)
The problem is not interrupt in Kernel. It is MXT224 that does not send
it. /CHG pin stay High.
I can send you all source code of board declaration if you want.
Thanks a lot.
Gaëtan Carlier.
8---------------------------------------------------------
#define MXT_KEY IMX_GPIO_NR(2, 16)
static const int imx27gc_pins[] __initconst = {
/* UART1 */
PE12_PF_UART1_TXD,
PE13_PF_UART1_RXD,
PE14_PF_UART1_CTS,
PE15_PF_UART1_RTS,
/* UART3 */
PE8_PF_UART3_TXD,
PE9_PF_UART3_RXD,
PE10_PF_UART3_CTS,
PE11_PF_UART3_RTS,
/* FEC */
PD0_AIN_FEC_TXD0,
PD1_AIN_FEC_TXD1,
PD2_AIN_FEC_TXD2,
PD3_AIN_FEC_TXD3,
PD4_AOUT_FEC_RX_ER,
PD5_AOUT_FEC_RXD1,
PD6_AOUT_FEC_RXD2,
PD7_AOUT_FEC_RXD3,
PD8_AF_FEC_MDIO,
PD9_AIN_FEC_MDC,
PD10_AOUT_FEC_CRS,
PD11_AOUT_FEC_TX_CLK,
PD12_AOUT_FEC_RXD0,
PD13_AOUT_FEC_RX_DV,
PD14_AOUT_FEC_RX_CLK,
PD15_AOUT_FEC_COL,
PD16_AIN_FEC_TX_ER,
PF23_AIN_FEC_TX_EN,
/* CSPI2 */
PD22_PF_CSPI2_SCLK,
PD23_PF_CSPI2_MISO,
PD24_PF_CSPI2_MOSI,
SPI2_SS0 | GPIO_GPIO | GPIO_OUT,
/* I2C1 */
PD17_PF_I2C_DATA,
PD18_PF_I2C_CLK,
/* I2C2 */
PC5_PF_I2C2_SDA,
PC6_PF_I2C2_SCL,
/* PMIC INT */
PMIC_INT | GPIO_GPIO | GPIO_IN,
/* SLCD */
PA6_AIN_SLCDC_DAT0,
PA7_AIN_SLCDC_DAT1,
PA8_AIN_SLCDC_DAT2,
PA9_AIN_SLCDC_DAT3,
PA10_AIN_SLCDC_DAT4,
PA11_AIN_SLCDC_DAT5,
PA12_AIN_SLCDC_DAT6,
PA13_AIN_SLCDC_DAT7,
PA25_AIN_SLCDC_CLS, /* D/C */
PA26_AIN_SLCDC_CS,
PA27_AIN_SLCDC_CLK, /* E/RD */
SLCDC_RESET | GPIO_GPIO | GPIO_OUT,
SLCDC_BL_POWER | GPIO_GPIO | GPIO_OUT,
SLCDC_RW | GPIO_GPIO | GPIO_OUT, /* only for manual reading operation */
/* MXT */
MXT_KEY | GPIO_GPIO | GPIO_IN, /* Key */
/* SSI4 */
PC16_PF_SSI4_FS,
PC17_PF_SSI4_RXD,
PC18_PF_SSI4_TXD,
PC19_PF_SSI4_CLK,
/* Flash Led */
FLASH_ENABLE | GPIO_GPIO | GPIO_OUT,
THT_ENABLE | GPIO_GPIO | GPIO_OUT,
HP_ENABLE | GPIO_GPIO | GPIO_OUT,
HEATING_ENABLE | GPIO_GPIO | GPIO_OUT,
BTNLIGHT_ENABLE | GPIO_GPIO | GPIO_OUT,
/* GPIO KEY */
GPIO_KEY1 | GPIO_GPIO | GPIO_IN,
GPIO_KEY2 | GPIO_GPIO | GPIO_IN,
GPIO_KEY3 | GPIO_GPIO | GPIO_IN,
};
static void __init imx27gc_init(void)
{
mxc_gpio_setup_multiple_pins(imx27gc_pins, ARRAY_SIZE(imx27gc_pins),
"imx27gc");
...
imx27gc_i2c0_devices[0].irq = gpio_to_irq(MXT_KEY);
i2c_register_board_info(0, imx27gc_i2c0_devices,
ARRAY_SIZE(imx27gc_i2c0_devices));
imx27_add_imx_i2c(0, &imx27gc_i2c0_data);
....
}
8---------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Peter Meerwald @ 2014-01-08 11:42 UTC (permalink / raw)
To: Gaëtan Carlier
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <52CD04F1.8090100@gmail.com>
> I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
> driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
> board. The capacitive glass used is a "GE Touch"
> SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
> correctly detected (with one warning/error).
> Does someone has some informations or the protocol guide, please ?
you need to request them from the distributor I guess, they docs are
pretty good
> /* TSP */
> static struct mxt_platform_data mxt_platform_data = {
> .x_line = 18,
> .y_line = 11,
> .x_size = 480,
shouldn't this be 16/14?
> .y_size = 640,
> .blen = 0x1,
> .threshold = 0x28,
> .voltage = 2800000, /* 2.8V */
> .orient = MXT_DIAGONAL_COUNTER,
> .irqflags = IRQF_TRIGGER_FALLING,
> };
> atmel_mxt_ts 0-004b: No cfg data defined, skipping reg init
> atmel_mxt_ts 0-004b: Invalid object type
something goes wrong in the initialization; the object table of the
chip doesn't match the register data fed in -- the mxt224 can be a bitch
and play dead
regards, p.
--
Peter Meerwald
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 12:24 UTC (permalink / raw)
To: Peter Meerwald
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <alpine.DEB.2.01.1401081228580.1454@pmeerw.net>
On 01/08/2014 12:42 PM, Peter Meerwald wrote:
> you need to request them from the distributor I guess, they docs are
> pretty good
I am in Belgium and we deal with Gleichmann & Co. Electronics in Germany
to have their devkit (SMT-C-T10). I have signed a NDA with them to have
MXT224 protocol guide but they never send me Protocol Guide.
I will try another distributor.
> shouldn't this be 16/14?
You are right, I already try this and test it again but this does not
change anything.
> something goes wrong in the initialization; the object table of the
> chip doesn't match the register data fed in -- the mxt224 can be a bitch
> and play dead
So what can I do ? Maybe a problem with the embedded firmware that need
an update (atmel_mxt_ts 0-004b: Family ID: 129 Variant ID: 1
Major.Minor.Build: 2.0.AB)
When I do cat /proc/interrupts and I short-circuit /CHG to ground,
number increases so low-level handling of interrupt is working.
Thanks,
Gaëtan Carlier.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] HID: input: fix input sysfs path for hid devices
From: David Herrmann @ 2014-01-08 12:33 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Benjamin Tissoires, open list:HID CORE LAYER,
linux-kernel
In-Reply-To: <alpine.LNX.2.00.1312202335300.11949@pobox.suse.cz>
Hi Jiri
On Fri, Dec 20, 2013 at 11:36 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 19 Dec 2013, David Herrmann wrote:
>
>> <benjamin.tissoires@redhat.com> wrote:
>> > we used to set the parent of the input device as the parent of
>> > the hid bus. This was introduced when we created hid as a real bus, and
>> > to keep backward compatibility. Now, it's time to proper set the parent
>> > so that sysfs has an idea of which input device is attached to
>> > which hid device.
>> >
>> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> > ---
>> >
>> > Hi Jiri,
>> >
>> > well, the regression test did not showed anything bad, and a look at the hid
>> > drivers also showed that no drivers should be armed by that.
>> >
>> > I think this is valuable because it will give a better understanding of the
>> > actual mapping hardware/inputs. Like a touchscreen with pen + touch will have
>> > the same hid parent, and I expect X/Wayland to be able to detect this at some
>> > point to keep the mapping correctly between the two input devices and the screen.
>> >
>> > I also need that for hid-replay, so that I can be sure which input is attached
>> > to which uhid device, and give up the heuristics I currently use.
>>
>> I was just wondering where we have multiple HID devices on a single
>> parent, but yeah, uhid is a good example. I actually have no
>> objections to this patch and it looks fine. But I cannot tell whether
>> anyone relies on this.
>>
>> I'd say we should give it a try.
>
> Agreed, let's take it for 3.14, and if anyone complains about breakage
> caused by this (which I don't expect), we'll revert to the previous state.
You dropped the "Reviewed-by:" part in your commit-msg:
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
Not sure, whether you sometimes rebase your tree. If you do, you might
wanna fix it, otherwise, I don't care. Just wanted to point it out.
Cheers
David
^ 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