Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1277895 > unrolled thread

[PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3

Started byAndrew Duggan <aduggan@synaptics.com>
First post2015-11-26 01:10 +0100
Last post2015-11-30 09:30 +0100
Articles 7 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3 Andrew Duggan <aduggan@synaptics.com> - 2015-11-26 01:10 +0100
    [PATCH 02/10] Input: synaptics-rmi4: Add I2C transport driver Andrew Duggan <aduggan@synaptics.com> - 2015-11-26 01:10 +0100
    [PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices Andrew Duggan <aduggan@synaptics.com> - 2015-11-26 01:10 +0100
      Re: [PATCH 03/10] Input: synaptics-rmi4: Add device tree support for  RMI4 I2C devices Rob Herring <robh@kernel.org> - 2015-11-27 22:30 +0100
    Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver  rebased on 4.3 Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2015-11-26 11:50 +0100
      Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver  rebased on 4.3 Andrew Duggan <aduggan@synaptics.com> - 2015-11-28 21:30 +0100
    Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver  rebased on 4.3 Linus Walleij <linus.walleij@linaro.org> - 2015-11-30 09:30 +0100

#1277895 — [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3

FromAndrew Duggan <aduggan@synaptics.com>
Date2015-11-26 01:10 +0100
Subject[PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3
Message-ID<qySim-4XI-5@gated-at.bofh.it>
This is a new patch series which squashes all of the development
history of the RMI4 driver into patches based on functionality. The
first patch adds the core RMI4 functionality needed by all RMI4 devices
and then the additional patches add transport and function drivers for
supporting various devices.

Touchpads which are currently using hid-rmi should have the same
functionality, but now knowledge of RMI is handled in the core instead
of in hid-rmi. These patches also provide basic finger reporting for a
wide range of RMI4 touchscreens connected to I2C and SPI busses.
However, additional work may need to be done to implement product specific
features.

I tried to include all of the feedback I received from the previous
patches I posted. However, I did not come up with a satisfactory solution
for allowing function drivers to be built as modules. I think it is fine
to allow function drivers to be enabled or disabled in the core at build
time. However, if supporting function drivers as modules is a must have
for upstreaming I can continue to try to find a solution. Also, I went
ahead and removed support for polling.

Thanks,
Andrew

Andrew Duggan (10):
  Input: synaptics-rmi4: Add support for Synaptics RMI4 devices
  Input: synaptics-rmi4: Add I2C transport driver
  Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
  Input: synaptics-rmi4: Add support for 2D sensors and F11
  Input: synaptics-rmi4: Add device tree support for 2d sensors and F11
  Input: synaptics-rmi4: Add support for F12
  Input: synaptics-rmi4: Add support for F30
  Input: synaptics-rmi4: Add SPI transport driver
  Input: synaptics-rmi4: Add device tree support to the SPI transport
    driver
  HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4

 .../bindings/input/rmi4/rmi_2d_sensor.txt          |   55 +
 .../devicetree/bindings/input/rmi4/rmi_f01.txt     |   40 +
 .../devicetree/bindings/input/rmi4/rmi_i2c.txt     |   53 +
 .../devicetree/bindings/input/rmi4/rmi_spi.txt     |   57 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 drivers/hid/hid-rmi.c                              |  922 ++-----------
 drivers/input/Kconfig                              |    2 +
 drivers/input/Makefile                             |    2 +
 drivers/input/rmi4/Kconfig                         |   94 ++
 drivers/input/rmi4/Makefile                        |   15 +
 drivers/input/rmi4/rmi_2d_sensor.c                 |  323 +++++
 drivers/input/rmi4/rmi_2d_sensor.h                 |   88 ++
 drivers/input/rmi4/rmi_bus.c                       |  419 ++++++
 drivers/input/rmi4/rmi_bus.h                       |  195 +++
 drivers/input/rmi4/rmi_driver.c                    | 1112 ++++++++++++++++
 drivers/input/rmi4/rmi_driver.h                    |  126 ++
 drivers/input/rmi4/rmi_f01.c                       |  570 ++++++++
 drivers/input/rmi4/rmi_f11.c                       | 1354 ++++++++++++++++++++
 drivers/input/rmi4/rmi_f12.c                       |  487 +++++++
 drivers/input/rmi4/rmi_f30.c                       |  419 ++++++
 drivers/input/rmi4/rmi_i2c.c                       |  270 ++++
 drivers/input/rmi4/rmi_spi.c                       |  464 +++++++
 include/linux/rmi.h                                |  415 ++++++
 include/uapi/linux/input.h                         |    1 +
 24 files changed, 6638 insertions(+), 846 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
 create mode 100644 drivers/input/rmi4/Kconfig
 create mode 100644 drivers/input/rmi4/Makefile
 create mode 100644 drivers/input/rmi4/rmi_2d_sensor.c
 create mode 100644 drivers/input/rmi4/rmi_2d_sensor.h
 create mode 100644 drivers/input/rmi4/rmi_bus.c
 create mode 100644 drivers/input/rmi4/rmi_bus.h
 create mode 100644 drivers/input/rmi4/rmi_driver.c
 create mode 100644 drivers/input/rmi4/rmi_driver.h
 create mode 100644 drivers/input/rmi4/rmi_f01.c
 create mode 100644 drivers/input/rmi4/rmi_f11.c
 create mode 100644 drivers/input/rmi4/rmi_f12.c
 create mode 100644 drivers/input/rmi4/rmi_f30.c
 create mode 100644 drivers/input/rmi4/rmi_i2c.c
 create mode 100644 drivers/input/rmi4/rmi_spi.c
 create mode 100644 include/linux/rmi.h

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1277898 — [PATCH 02/10] Input: synaptics-rmi4: Add I2C transport driver

FromAndrew Duggan <aduggan@synaptics.com>
Date2015-11-26 01:10 +0100
Subject[PATCH 02/10] Input: synaptics-rmi4: Add I2C transport driver
Message-ID<qySim-4XI-13@gated-at.bofh.it>
In reply to#1277895
Add the transport driver for devices using RMI4 over I2C.

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
---
 drivers/input/rmi4/Kconfig   |  11 ++
 drivers/input/rmi4/Makefile  |   3 +
 drivers/input/rmi4/rmi_i2c.c | 260 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 274 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_i2c.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index 45a9ff4..e1c07fc 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -24,3 +24,14 @@ config RMI4_DEBUG
 	  if you are actively developing/debugging RMI4 features.
 
 	  If unsure, say N.
+
+config RMI4_I2C
+	tristate "RMI4 I2C Support"
+	depends on RMI4_CORE && I2C
+	help
+	  Say Y here if you want to support RMI4 devices connected to an I2C
+	  bus.
+
+	  If unsure, say Y.
+
+	  This feature is not currently available as a loadable module.
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index b33768f..0bb318d 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -1,4 +1,7 @@
 obj-$(CONFIG_RMI4_CORE) += rmi_core.o
 rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
 
+# Transports
+obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
+
 ccflags-$(CONFIG_RMI4_DEBUG) += -DDEBUG
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
new file mode 100644
index 0000000..c6e680d
--- /dev/null
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright (c) 2011-2015 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/i2c.h>
+#include <linux/rmi.h>
+#include "rmi_driver.h"
+
+#define BUFFER_SIZE_INCREMENT 32
+
+/**
+ * struct rmi_i2c_xport - stores information for i2c communication
+ *
+ * @xport: The transport interface structure
+ *
+ * @page_mutex: Locks current page to avoid changing pages in unexpected ways.
+ * @page: Keeps track of the current virtual page
+ *
+ * @tx_buf: Buffer used for transmitting data to the sensor over i2c.
+ * @tx_buf_size: Size of the buffer
+ */
+struct rmi_i2c_xport {
+	struct rmi_transport_dev xport;
+	struct i2c_client *client;
+
+	struct mutex page_mutex;
+	int page;
+
+	u8 *tx_buf;
+	size_t tx_buf_size;
+};
+
+#define RMI_PAGE_SELECT_REGISTER 0xff
+#define RMI_I2C_PAGE(addr) (((addr) >> 8) & 0xff)
+
+/*
+ * rmi_set_page - Set RMI page
+ * @xport: The pointer to the rmi_transport_dev struct
+ * @page: The new page address.
+ *
+ * RMI devices have 16-bit addressing, but some of the transport
+ * implementations (like SMBus) only have 8-bit addressing. So RMI implements
+ * a page address at 0xff of every page so we can reliable page addresses
+ * every 256 registers.
+ *
+ * The page_mutex lock must be held when this function is entered.
+ *
+ * Returns zero on success, non-zero on failure.
+ */
+static int rmi_set_page(struct rmi_i2c_xport *rmi_i2c, u8 page)
+{
+	struct i2c_client *client = rmi_i2c->client;
+	u8 txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
+	int retval;
+
+	retval = i2c_master_send(client, txbuf, sizeof(txbuf));
+	if (retval != sizeof(txbuf)) {
+		dev_err(&client->dev,
+			"%s: set page failed: %d.", __func__, retval);
+		return (retval < 0) ? retval : -EIO;
+	}
+
+	rmi_i2c->page = page;
+	return 0;
+}
+
+static int rmi_i2c_write_block(struct rmi_transport_dev *xport, u16 addr,
+			       const void *buf, size_t len)
+{
+	struct rmi_i2c_xport *rmi_i2c =
+		container_of(xport, struct rmi_i2c_xport, xport);
+	struct i2c_client *client = rmi_i2c->client;
+	size_t tx_size = len + 1;
+	int retval;
+
+	mutex_lock(&rmi_i2c->page_mutex);
+
+	if (!rmi_i2c->tx_buf || rmi_i2c->tx_buf_size < tx_size) {
+		if (rmi_i2c->tx_buf)
+			devm_kfree(&client->dev, rmi_i2c->tx_buf);
+		rmi_i2c->tx_buf_size = tx_size + BUFFER_SIZE_INCREMENT;
+		rmi_i2c->tx_buf = devm_kzalloc(&client->dev,
+					       rmi_i2c->tx_buf_size,
+					       GFP_KERNEL);
+		if (!rmi_i2c->tx_buf) {
+			rmi_i2c->tx_buf_size = 0;
+			retval = -ENOMEM;
+			goto exit;
+		}
+	}
+
+	rmi_i2c->tx_buf[0] = addr & 0xff;
+	memcpy(rmi_i2c->tx_buf + 1, buf, len);
+
+	if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
+		retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
+		if (retval)
+			goto exit;
+	}
+
+	retval = i2c_master_send(client, rmi_i2c->tx_buf, tx_size);
+	if (retval == tx_size)
+		retval = 0;
+	else if (retval >= 0)
+		retval = -EIO;
+
+exit:
+	dev_dbg(&client->dev,
+		"write %zd bytes at %#06x: %d (%*ph)\n",
+		len, addr, retval, (int)len, buf);
+
+	mutex_unlock(&rmi_i2c->page_mutex);
+	return retval;
+}
+
+static int rmi_i2c_read_block(struct rmi_transport_dev *xport, u16 addr,
+			      void *buf, size_t len)
+{
+	struct rmi_i2c_xport *rmi_i2c =
+		container_of(xport, struct rmi_i2c_xport, xport);
+	struct i2c_client *client = rmi_i2c->client;
+	u8 addr_offset = addr & 0xff;
+	int retval;
+	struct i2c_msg msgs[] = {
+		{
+			.addr	= client->addr,
+			.len	= sizeof(addr_offset),
+			.buf	= &addr_offset,
+		},
+		{
+			.addr	= client->addr,
+			.flags	= I2C_M_RD,
+			.len	= len,
+			.buf	= buf,
+		},
+	};
+
+	mutex_lock(&rmi_i2c->page_mutex);
+
+	if (RMI_I2C_PAGE(addr) != rmi_i2c->page) {
+		retval = rmi_set_page(rmi_i2c, RMI_I2C_PAGE(addr));
+		if (retval)
+			goto exit;
+	}
+
+	retval = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+	if (retval == ARRAY_SIZE(msgs))
+		retval = 0; /* success */
+	else if (retval >= 0)
+		retval = -EIO;
+
+exit:
+	dev_dbg(&client->dev,
+		"read %zd bytes at %#06x: %d (%*ph)\n",
+		len, addr, retval, (int)len, buf);
+
+	mutex_unlock(&rmi_i2c->page_mutex);
+	return retval;
+}
+
+static const struct rmi_transport_ops rmi_i2c_ops = {
+	.write_block	= rmi_i2c_write_block,
+	.read_block	= rmi_i2c_read_block,
+};
+
+static int rmi_i2c_probe(struct i2c_client *client,
+			 const struct i2c_device_id *id)
+{
+	struct rmi_device_platform_data *pdata;
+	struct rmi_device_platform_data *client_pdata =
+					dev_get_platdata(&client->dev);
+	struct rmi_i2c_xport *rmi_i2c;
+	int retval;
+
+	rmi_i2c = devm_kzalloc(&client->dev, sizeof(struct rmi_i2c_xport),
+				GFP_KERNEL);
+	if (!rmi_i2c)
+		return -ENOMEM;
+
+	pdata = &rmi_i2c->xport.pdata;
+
+	if (client_pdata)
+		*pdata = *client_pdata;
+
+	dev_dbg(&client->dev, "Probing %s.\n", dev_name(&client->dev));
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+		dev_err(&client->dev,
+			"adapter does not support required functionality.\n");
+		return -ENODEV;
+	}
+
+	rmi_i2c->client = client;
+	mutex_init(&rmi_i2c->page_mutex);
+
+	rmi_i2c->xport.dev = &client->dev;
+	rmi_i2c->xport.proto_name = "i2c";
+	rmi_i2c->xport.ops = &rmi_i2c_ops;
+	rmi_i2c->xport.irq = client->irq;
+	rmi_i2c->xport.irq_flags = pdata->irq_flags;
+
+	/*
+	 * Setting the page to zero will (a) make sure the PSR is in a
+	 * known state, and (b) make sure we can talk to the device.
+	 */
+	retval = rmi_set_page(rmi_i2c, 0);
+	if (retval) {
+		dev_err(&client->dev, "Failed to set page select to 0.\n");
+		return retval;
+	}
+
+	retval = rmi_register_transport_device(&rmi_i2c->xport);
+	if (retval) {
+		dev_err(&client->dev, "Failed to register transport driver at 0x%.2X.\n",
+			client->addr);
+		return retval;
+	}
+
+	i2c_set_clientdata(client, rmi_i2c);
+
+	dev_info(&client->dev, "registered rmi i2c driver at %#04x.\n",
+			client->addr);
+	return 0;
+}
+
+static int rmi_i2c_remove(struct i2c_client *client)
+{
+	struct rmi_i2c_xport *rmi_i2c = i2c_get_clientdata(client);
+
+	rmi_unregister_transport_device(&rmi_i2c->xport);
+
+	return 0;
+}
+
+static const struct i2c_device_id rmi_id[] = {
+	{ "rmi_i2c", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, rmi_id);
+
+static struct i2c_driver rmi_i2c_driver = {
+	.driver = {
+		.owner	= THIS_MODULE,
+		.name	= "rmi_i2c",
+	},
+	.id_table	= rmi_id,
+	.probe		= rmi_i2c_probe,
+	.remove		= rmi_i2c_remove,
+};
+
+module_i2c_driver(rmi_i2c_driver);
+
+MODULE_AUTHOR("Christopher Heiny <cheiny@synaptics.com>");
+MODULE_DESCRIPTION("RMI I2C driver");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(RMI_DRIVER_VERSION);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277901 — [PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices

FromAndrew Duggan <aduggan@synaptics.com>
Date2015-11-26 01:10 +0100
Subject[PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Message-ID<qySim-4XI-21@gated-at.bofh.it>
In reply to#1277895
Add devicetree binding for I2C devices and add bindings for optional
parameters in the function drivers. Parameters for function drivers are
defined in child nodes for each of the functions.

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
---
 .../devicetree/bindings/input/rmi4/rmi_f01.txt     | 39 ++++++++++++
 .../devicetree/bindings/input/rmi4/rmi_i2c.txt     | 53 ++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 drivers/input/rmi4/rmi_bus.c                       | 71 ++++++++++++++++++++++
 drivers/input/rmi4/rmi_driver.c                    | 28 +++++++++
 drivers/input/rmi4/rmi_i2c.c                       | 12 +++-
 6 files changed, 203 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
 create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt

diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
new file mode 100644
index 0000000..df34dd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
@@ -0,0 +1,39 @@
+Synaptics RMI4 F01 Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices which contain Function 1. Complete documentation
+for transports and other functions can be found in:
+Documentation/devicetree/bindings/input/rmi4.
+
+Additional documentation for F01 can be found at:
+http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
+
+Optional Properties:
+- syna,nosleep-mode: If set the device will run at full power without sleeping.
+			nosleep has 3 modes, 0 will not change the default
+			setting, 1 will disable nosleep (allow sleeping),
+			and 2 will enable nosleep (disabling sleep).
+- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
+				background capacitance that will cause the
+				device to wake from dozing.
+- syna,doze-holdoff: The delay to wait after the last finger lift and the
+				first doze cycle (in 0.1 second units).
+- syna,doze-interval: The time period that the device sleeps between finger
+				activity (in 10 ms units).
+
+
+Example of a RMI4 I2C device with F01:
+	Example:
+	&i2c1 {
+		rmi-i2c-dev@2c {
+			compatible = "syna,rmi-i2c";
+
+			...
+
+			rmi-f01@1 {
+				reg = <0x1>;
+				syna,nosleep-mode = <1>;
+			};
+		};
+	};
diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
new file mode 100644
index 0000000..0f4a8e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
@@ -0,0 +1,53 @@
+Synaptics RMI4 I2C Device Binding
+
+The Synaptics RMI4 core is able to support RMI4 devices using differnet
+transports and differnet functions. This file describes the device tree
+bindings for devices using the I2C tranport driver. Complete documentation
+for other transports and functions cen be found ini
+Documentation/devicetree/bindings/input/rmi4.
+
+Required Properties:
+- compatible: syna,rmi-i2c
+- reg: I2C address
+- #address-cells: Set to 1 to indicate that the function child nodes
+		    consist of only on uint32 value.
+- #size-cells: Set to 0 to indicate that the function child nodes do not
+		have a size property.
+
+Optional Properties:
+- interrupts: interrupt which the rmi device is connected to.
+- interrupt-parent: The interrupt controller.
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
+			device.
+
+Function Parameters:
+Parameters specific to RMI functions are contained in child nodes of the rmi device
+ node. Documentation for the parameters of each function can be found in:
+Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
+
+
+
+Example:
+	&i2c1 {
+		rmi-i2c-dev@2c {
+			compatible = "syna,rmi-i2c";
+			reg = <0x2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupt-parent = <&gpio>;
+			interrupts = <4 2>;
+
+			rmi-f01@1 {
+				reg = <0x1>;
+				syna,nosleep-mode = <1>;
+			};
+
+			rmi-f11@11 {
+				reg = <0x11>;
+				syna,flip-y;
+				syna,sensor-type = <2>;
+			};
+		};
+	};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..fd075b8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -212,6 +212,7 @@ sprd	Spreadtrum Communications Inc.
 st	STMicroelectronics
 ste	ST-Ericsson
 stericsson	ST-Ericsson
+syna	Synaptics Inc.
 synology	Synology, Inc.
 tbs	TBS Technologies
 tcl	Toby Churchill Ltd.
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index f3e1f2c..aa12f4a 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -130,6 +130,21 @@ static int rmi_function_match(struct device *dev, struct device_driver *drv)
 	return fn->fd.function_number == handler->func;
 }
 
+#ifdef CONFIG_OF
+static void rmi_function_of_probe(struct rmi_function *fn)
+{
+	char of_name[8];
+
+	snprintf(of_name, sizeof(of_name), "rmi-f%02x",
+		fn->fd.function_number);
+	fn->dev.of_node = of_find_node_by_name(
+				fn->rmi_dev->xport->dev->of_node, of_name);
+}
+#else
+static inline void rmi_function_of_probe(struct rmi_function *fn)
+{}
+#endif
+
 static int rmi_function_probe(struct device *dev)
 {
 	struct rmi_function *fn = to_rmi_function(dev);
@@ -137,6 +152,8 @@ static int rmi_function_probe(struct device *dev)
 					to_rmi_function_handler(dev->driver);
 	int error;
 
+	rmi_function_of_probe(fn);
+
 	if (handler->probe) {
 		error = handler->probe(fn);
 		return error;
@@ -263,6 +280,60 @@ struct bus_type rmi_bus_type = {
 	.name		= "rmi",
 };
 
+int rmi_of_property_read_u32(struct device *dev, u32 *result,
+				const char *prop, bool optional)
+{
+	int retval;
+	u32 val = 0;
+
+	retval = of_property_read_u32(dev->of_node, prop, &val);
+	if (retval && (!optional && retval == -EINVAL)) {
+		dev_err(dev, "Failed to get %s value: %d\n",
+			prop, retval);
+		return retval;
+	}
+	*result = val;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rmi_of_property_read_u32);
+
+int rmi_of_property_read_u16(struct device *dev, u16 *result,
+				const char *prop, bool optional)
+{
+	int retval;
+	u16 val = 0;
+
+	retval = of_property_read_u16(dev->of_node, prop, &val);
+	if (retval && (!optional && retval == -EINVAL)) {
+		dev_err(dev, "Failed to get %s value: %d\n",
+			prop, retval);
+		return retval;
+	}
+	*result = val;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rmi_of_property_read_u16);
+
+int rmi_of_property_read_u8(struct device *dev, u8 *result,
+				const char *prop, bool optional)
+{
+	int retval;
+	u8 val = 0;
+
+	retval = of_property_read_u8(dev->of_node, prop, &val);
+	if (retval && (!optional && retval == -EINVAL)) {
+		dev_err(dev, "Failed to get %s value: %d\n",
+			prop, retval);
+		return retval;
+	}
+	*result = val;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rmi_of_property_read_u8);
+
 static int __init rmi_bus_init(void)
 {
 	int error;
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 0d74d26..3a4697f 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -20,6 +20,7 @@
 #include <linux/kconfig.h>
 #include <linux/pm.h>
 #include <linux/slab.h>
+#include <linux/of.h>
 #include <uapi/linux/input.h>
 #include <linux/rmi.h>
 #include "rmi_bus.h"
@@ -864,6 +865,27 @@ static int rmi_driver_remove(struct device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static int rmi_driver_of_probe(struct device *dev,
+				struct rmi_device_platform_data *pdata)
+{
+	int retval;
+
+	retval = rmi_of_property_read_u32(dev, &pdata->reset_delay_ms,
+					"syna,reset-delay-ms", 1);
+	if (retval)
+		return retval;
+
+	return 0;
+}
+#else
+static inline int rmi_driver_of_probe(struct device *dev,
+					struct rmi_device_platform_data *pdata)
+{
+	return -ENODEV;
+}
+#endif
+
 static int rmi_driver_probe(struct device *dev)
 {
 	struct rmi_driver *rmi_driver;
@@ -888,6 +910,12 @@ static int rmi_driver_probe(struct device *dev)
 
 	pdata = rmi_get_platform_data(rmi_dev);
 
+	if (rmi_dev->xport->dev->of_node) {
+		retval = rmi_driver_of_probe(rmi_dev->xport->dev, pdata);
+		if (retval)
+			return retval;
+	}
+
 	data = devm_kzalloc(dev, sizeof(struct rmi_driver_data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
index c6e680d..32f7cae 100644
--- a/drivers/input/rmi4/rmi_i2c.c
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -9,6 +9,7 @@
 
 #include <linux/i2c.h>
 #include <linux/rmi.h>
+#include <linux/of.h>
 #include "rmi_driver.h"
 
 #define BUFFER_SIZE_INCREMENT 32
@@ -168,6 +169,14 @@ static const struct rmi_transport_ops rmi_i2c_ops = {
 	.read_block	= rmi_i2c_read_block,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id rmi_i2c_of_match[] = {
+	{ .compatible = "syna,rmi-i2c" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rmi_i2c_of_match);
+#endif
+
 static int rmi_i2c_probe(struct i2c_client *client,
 			 const struct i2c_device_id *id)
 {
@@ -184,7 +193,7 @@ static int rmi_i2c_probe(struct i2c_client *client,
 
 	pdata = &rmi_i2c->xport.pdata;
 
-	if (client_pdata)
+	if (!client->dev.of_node && client_pdata)
 		*pdata = *client_pdata;
 
 	dev_dbg(&client->dev, "Probing %s.\n", dev_name(&client->dev));
@@ -246,6 +255,7 @@ static struct i2c_driver rmi_i2c_driver = {
 	.driver = {
 		.owner	= THIS_MODULE,
 		.name	= "rmi_i2c",
+		.of_match_table = of_match_ptr(rmi_i2c_of_match),
 	},
 	.id_table	= rmi_id,
 	.probe		= rmi_i2c_probe,
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278985 — Re: [PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices

FromRob Herring <robh@kernel.org>
Date2015-11-27 22:30 +0100
SubjectRe: [PATCH 03/10] Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
Message-ID<qzyKC-89k-11@gated-at.bofh.it>
In reply to#1277901
On Wed, Nov 25, 2015 at 04:07:21PM -0800, Andrew Duggan wrote:
> Add devicetree binding for I2C devices and add bindings for optional
> parameters in the function drivers. Parameters for function drivers are
> defined in child nodes for each of the functions.
> 
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
>  .../devicetree/bindings/input/rmi4/rmi_f01.txt     | 39 ++++++++++++
>  .../devicetree/bindings/input/rmi4/rmi_i2c.txt     | 53 ++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  drivers/input/rmi4/rmi_bus.c                       | 71 ++++++++++++++++++++++
>  drivers/input/rmi4/rmi_driver.c                    | 28 +++++++++
>  drivers/input/rmi4/rmi_i2c.c                       | 12 +++-
>  6 files changed, 203 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
> new file mode 100644
> index 0000000..df34dd5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
> @@ -0,0 +1,39 @@
> +Synaptics RMI4 F01 Device Binding
> +
> +The Synaptics RMI4 core is able to support RMI4 devices using differnet
> +transports and differnet functions. This file describes the device tree

s/differnet/different/

> +bindings for devices which contain Function 1. Complete documentation
> +for transports and other functions can be found in:
> +Documentation/devicetree/bindings/input/rmi4.
> +
> +Additional documentation for F01 can be found at:
> +http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
> +
> +Optional Properties:
> +- syna,nosleep-mode: If set the device will run at full power without sleeping.
> +			nosleep has 3 modes, 0 will not change the default
> +			setting, 1 will disable nosleep (allow sleeping),
> +			and 2 will enable nosleep (disabling sleep).
> +- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
> +				background capacitance that will cause the
> +				device to wake from dozing.

> +- syna,doze-holdoff: The delay to wait after the last finger lift and the
> +				first doze cycle (in 0.1 second units).
> +- syna,doze-interval: The time period that the device sleeps between finger
> +				activity (in 10 ms units).

Use millisec units and -msec suffix.


> +
> +
> +Example of a RMI4 I2C device with F01:
> +	Example:
> +	&i2c1 {
> +		rmi-i2c-dev@2c {
> +			compatible = "syna,rmi-i2c";
> +
> +			...
> +
> +			rmi-f01@1 {
> +				reg = <0x1>;
> +				syna,nosleep-mode = <1>;
> +			};
> +		};
> +	};
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> new file mode 100644
> index 0000000..0f4a8e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
> @@ -0,0 +1,53 @@
> +Synaptics RMI4 I2C Device Binding
> +
> +The Synaptics RMI4 core is able to support RMI4 devices using differnet
> +transports and differnet functions. This file describes the device tree

s/differnet/different/

> +bindings for devices using the I2C tranport driver. Complete documentation
> +for other transports and functions cen be found ini
> +Documentation/devicetree/bindings/input/rmi4.
> +
> +Required Properties:
> +- compatible: syna,rmi-i2c

This is not very specific. Perhaps at least "rmi4" instead of just rmi.

> +- reg: I2C address
> +- #address-cells: Set to 1 to indicate that the function child nodes
> +		    consist of only on uint32 value.
> +- #size-cells: Set to 0 to indicate that the function child nodes do not
> +		have a size property.
> +
> +Optional Properties:
> +- interrupts: interrupt which the rmi device is connected to.
> +- interrupt-parent: The interrupt controller.
> +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +- syna,reset-delay-ms: The number of milliseconds to wait after resetting the

"-msec" is the more commonly used abreviation in bindings.

> +			device.
> +
> +Function Parameters:
> +Parameters specific to RMI functions are contained in child nodes of the rmi device
> + node. Documentation for the parameters of each function can be found in:
> +Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
> +
> +
> +
> +Example:
> +	&i2c1 {
> +		rmi-i2c-dev@2c {
> +			compatible = "syna,rmi-i2c";
> +			reg = <0x2c>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			interrupt-parent = <&gpio>;
> +			interrupts = <4 2>;
> +
> +			rmi-f01@1 {
> +				reg = <0x1>;
> +				syna,nosleep-mode = <1>;
> +			};
> +
> +			rmi-f11@11 {
> +				reg = <0x11>;
> +				syna,flip-y;
> +				syna,sensor-type = <2>;
> +			};
> +		};
> +	};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278142 — Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3

FromBenjamin Tissoires <benjamin.tissoires@redhat.com>
Date2015-11-26 11:50 +0100
SubjectRe: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3
Message-ID<qz2hH-3Y1-1@gated-at.bofh.it>
In reply to#1277895
Hi Andrew,

On Nov 25 2015 or thereabouts, Andrew Duggan wrote:
> This is a new patch series which squashes all of the development
> history of the RMI4 driver into patches based on functionality. The
> first patch adds the core RMI4 functionality needed by all RMI4 devices
> and then the additional patches add transport and function drivers for
> supporting various devices.

Thanks for this hard work. I did not do a full review of the series yet,
but caught some general design questions that I am writing here.

> 
> Touchpads which are currently using hid-rmi should have the same
> functionality, but now knowledge of RMI is handled in the core instead

I tried applying the series on top of a 4.4-rc2, and git am failed. I
think it's good to keep this one in the series, but we might want to
postpone its application when rmi4 hits Linus' tree so Jiri will be able
to take it without conflicting with Dmitry's tree. Well, Jiri and Dmitry
can sort this out :)

> of in hid-rmi. These patches also provide basic finger reporting for a
> wide range of RMI4 touchscreens connected to I2C and SPI busses.
> However, additional work may need to be done to implement product specific
> features.
> 
> I tried to include all of the feedback I received from the previous
> patches I posted. However, I did not come up with a satisfactory solution
> for allowing function drivers to be built as modules. I think it is fine
> to allow function drivers to be enabled or disabled in the core at build

I agree. I do not like the implementation however (I know, I contributed
a lot to it). How about we keep a static array of struct
rmi_function_handler? If we add a .registered file in struct
rmi_function_handler, we could simplify the registering/unregistering of
the functions more easily by looping through the array.

> time. However, if supporting function drivers as modules is a must have
> for upstreaming I can continue to try to find a solution. Also, I went
> ahead and removed support for polling.

Thanks for removing polling.

I have 2 other general concerns for rmi_bus:
- interrupts:
the current implementation has 2 type of interrupt handling depending on
the transport driver: either generic irqs or specific ones that are
triggered by the transport driver.

I think it would make sense to remove the generic irq handling in rmi4_bus
and let the transport driver handle it. This way, it will be easier for
the transport driver to decide whether or not forwarding the interrupts to
the bus.

This is what is done with the HID bus for the record. The transport
driver calls hid_input_report() when an irq has been processed.

- suspend/resume:
with the smbus implementation, we have quite some troubles with the
suspend/resume part. The reason is that both the rmi_bus and the serio
bus are registering to the pm subsystem and this leads to races between
them. Our current solution is to disable the pm registering in rmi_bus
and let the transport driver handle it at his level (which is in fine
triggered by the serio pm resume actually, not its own pm registration). 

I wonder if having the pm functions directly in the bus is a good idea
and if we should not let the transport driver handle those. We should
still keep the rmi specific functions in rmi_core/bus, I am just talking
about the registration of the bus to the subsystem.

[just thinking out loud: maybe we encounter problems of ordering due to
the fact that the bus is registered to the pm subsystem. Maybe if the
device itself in the transport driver registers, there will be guarantee
that the serio resume is called before the rmi_smbus one, which would
solve our problems].

Cheers,
Benjamin

> 
> Thanks,
> Andrew
> 
> Andrew Duggan (10):
>   Input: synaptics-rmi4: Add support for Synaptics RMI4 devices
>   Input: synaptics-rmi4: Add I2C transport driver
>   Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
>   Input: synaptics-rmi4: Add support for 2D sensors and F11
>   Input: synaptics-rmi4: Add device tree support for 2d sensors and F11
>   Input: synaptics-rmi4: Add support for F12
>   Input: synaptics-rmi4: Add support for F30
>   Input: synaptics-rmi4: Add SPI transport driver
>   Input: synaptics-rmi4: Add device tree support to the SPI transport
>     driver
>   HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
> 
>  .../bindings/input/rmi4/rmi_2d_sensor.txt          |   55 +
>  .../devicetree/bindings/input/rmi4/rmi_f01.txt     |   40 +
>  .../devicetree/bindings/input/rmi4/rmi_i2c.txt     |   53 +
>  .../devicetree/bindings/input/rmi4/rmi_spi.txt     |   57 +
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  drivers/hid/hid-rmi.c                              |  922 ++-----------
>  drivers/input/Kconfig                              |    2 +
>  drivers/input/Makefile                             |    2 +
>  drivers/input/rmi4/Kconfig                         |   94 ++
>  drivers/input/rmi4/Makefile                        |   15 +
>  drivers/input/rmi4/rmi_2d_sensor.c                 |  323 +++++
>  drivers/input/rmi4/rmi_2d_sensor.h                 |   88 ++
>  drivers/input/rmi4/rmi_bus.c                       |  419 ++++++
>  drivers/input/rmi4/rmi_bus.h                       |  195 +++
>  drivers/input/rmi4/rmi_driver.c                    | 1112 ++++++++++++++++
>  drivers/input/rmi4/rmi_driver.h                    |  126 ++
>  drivers/input/rmi4/rmi_f01.c                       |  570 ++++++++
>  drivers/input/rmi4/rmi_f11.c                       | 1354 ++++++++++++++++++++
>  drivers/input/rmi4/rmi_f12.c                       |  487 +++++++
>  drivers/input/rmi4/rmi_f30.c                       |  419 ++++++
>  drivers/input/rmi4/rmi_i2c.c                       |  270 ++++
>  drivers/input/rmi4/rmi_spi.c                       |  464 +++++++
>  include/linux/rmi.h                                |  415 ++++++
>  include/uapi/linux/input.h                         |    1 +
>  24 files changed, 6638 insertions(+), 846 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>  create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
>  create mode 100644 drivers/input/rmi4/Kconfig
>  create mode 100644 drivers/input/rmi4/Makefile
>  create mode 100644 drivers/input/rmi4/rmi_2d_sensor.c
>  create mode 100644 drivers/input/rmi4/rmi_2d_sensor.h
>  create mode 100644 drivers/input/rmi4/rmi_bus.c
>  create mode 100644 drivers/input/rmi4/rmi_bus.h
>  create mode 100644 drivers/input/rmi4/rmi_driver.c
>  create mode 100644 drivers/input/rmi4/rmi_driver.h
>  create mode 100644 drivers/input/rmi4/rmi_f01.c
>  create mode 100644 drivers/input/rmi4/rmi_f11.c
>  create mode 100644 drivers/input/rmi4/rmi_f12.c
>  create mode 100644 drivers/input/rmi4/rmi_f30.c
>  create mode 100644 drivers/input/rmi4/rmi_i2c.c
>  create mode 100644 drivers/input/rmi4/rmi_spi.c
>  create mode 100644 include/linux/rmi.h
> 
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279217 — Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3

FromAndrew Duggan <aduggan@synaptics.com>
Date2015-11-28 21:30 +0100
SubjectRe: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3
Message-ID<qzUi6-57x-5@gated-at.bofh.it>
In reply to#1278142

On 11/26/2015 02:41 AM, Benjamin Tissoires wrote:
> Hi Andrew,
>
> On Nov 25 2015 or thereabouts, Andrew Duggan wrote:
>> This is a new patch series which squashes all of the development
>> history of the RMI4 driver into patches based on functionality. The
>> first patch adds the core RMI4 functionality needed by all RMI4 devices
>> and then the additional patches add transport and function drivers for
>> supporting various devices.
> Thanks for this hard work. I did not do a full review of the series yet,
> but caught some general design questions that I am writing here.
>
>> Touchpads which are currently using hid-rmi should have the same
>> functionality, but now knowledge of RMI is handled in the core instead
> I tried applying the series on top of a 4.4-rc2, and git am failed. I
> think it's good to keep this one in the series, but we might want to
> postpone its application when rmi4 hits Linus' tree so Jiri will be able
> to take it without conflicting with Dmitry's tree. Well, Jiri and Dmitry
> can sort this out :)

I forgot there were in changes to hid-rmi in 4.4. I can fix it up to 
work with whatever version the core ends up being applied to.

>> of in hid-rmi. These patches also provide basic finger reporting for a
>> wide range of RMI4 touchscreens connected to I2C and SPI busses.
>> However, additional work may need to be done to implement product specific
>> features.
>>
>> I tried to include all of the feedback I received from the previous
>> patches I posted. However, I did not come up with a satisfactory solution
>> for allowing function drivers to be built as modules. I think it is fine
>> to allow function drivers to be enabled or disabled in the core at build
> I agree. I do not like the implementation however (I know, I contributed
> a lot to it). How about we keep a static array of struct
> rmi_function_handler? If we add a .registered file in struct
> rmi_function_handler, we could simplify the registering/unregistering of
> the functions more easily by looping through the array.

Sounds like a good idea. Right you it takes several lines in multiple 
files to register and unregister function drivers and its really easy to 
forget something.

>> time. However, if supporting function drivers as modules is a must have
>> for upstreaming I can continue to try to find a solution. Also, I went
>> ahead and removed support for polling.
> Thanks for removing polling.
>
> I have 2 other general concerns for rmi_bus:
> - interrupts:
> the current implementation has 2 type of interrupt handling depending on
> the transport driver: either generic irqs or specific ones that are
> triggered by the transport driver.
>
> I think it would make sense to remove the generic irq handling in rmi4_bus
> and let the transport driver handle it. This way, it will be easier for
> the transport driver to decide whether or not forwarding the interrupts to
> the bus.
>
> This is what is done with the HID bus for the record. The transport
> driver calls hid_input_report() when an irq has been processed.

The driver was handling the IRQs originally to avoid duplicating a lot 
of code in each of the transport devices. But, now that the custom GPIO 
code has been removed the reasoning for handling it in rmi_driver is 
less compelling. Plus, now we have SMBus and HID transports which don't 
handle the IRQs directly. It might also be better to enable and disable 
IRQs in the transport drivers pm callbacks.

> - suspend/resume:
> with the smbus implementation, we have quite some troubles with the
> suspend/resume part. The reason is that both the rmi_bus and the serio
> bus are registering to the pm subsystem and this leads to races between
> them. Our current solution is to disable the pm registering in rmi_bus
> and let the transport driver handle it at his level (which is in fine
> triggered by the serio pm resume actually, not its own pm registration).

The interaction between the SMBus and the PS/2 interface does complicate 
things. I have not noticed any similar issues with PS/2 + HID/I2C. 
Probably, because PS/2 + HID/I2C was designed to work without any driver 
interaction.

> I wonder if having the pm functions directly in the bus is a good idea
> and if we should not let the transport driver handle those. We should
> still keep the rmi specific functions in rmi_core/bus, I am just talking
> about the registration of the bus to the subsystem.

I guess we could just call rmi_driver_suspend/resume() from the 
transports and have it loop through all of the function drivers and call 
their suspend/resume functions. So far it has just made sense to use the 
pm subsystem instead of doing things manually. But, none of the other 
transports have dependencies on devices in separate driver stacks.

> [just thinking out loud: maybe we encounter problems of ordering due to
> the fact that the bus is registered to the pm subsystem. Maybe if the
> device itself in the transport driver registers, there will be guarantee
> that the serio resume is called before the rmi_smbus one, which would
> solve our problems].

Well if rmi_smbus can register itself with the pm subsystem, could we 
just make the transport device the parent of the bus device? Would that 
ensure that all of the pm callbacks get called together? Sounds like 
some more investigating is needed for figuring out how best to handle 
suspend/resume.

Thanks,
Andrew

> Cheers,
> Benjamin
>
>> Thanks,
>> Andrew
>>
>> Andrew Duggan (10):
>>    Input: synaptics-rmi4: Add support for Synaptics RMI4 devices
>>    Input: synaptics-rmi4: Add I2C transport driver
>>    Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
>>    Input: synaptics-rmi4: Add support for 2D sensors and F11
>>    Input: synaptics-rmi4: Add device tree support for 2d sensors and F11
>>    Input: synaptics-rmi4: Add support for F12
>>    Input: synaptics-rmi4: Add support for F30
>>    Input: synaptics-rmi4: Add SPI transport driver
>>    Input: synaptics-rmi4: Add device tree support to the SPI transport
>>      driver
>>    HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
>>
>>   .../bindings/input/rmi4/rmi_2d_sensor.txt          |   55 +
>>   .../devicetree/bindings/input/rmi4/rmi_f01.txt     |   40 +
>>   .../devicetree/bindings/input/rmi4/rmi_i2c.txt     |   53 +
>>   .../devicetree/bindings/input/rmi4/rmi_spi.txt     |   57 +
>>   .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>>   drivers/hid/hid-rmi.c                              |  922 ++-----------
>>   drivers/input/Kconfig                              |    2 +
>>   drivers/input/Makefile                             |    2 +
>>   drivers/input/rmi4/Kconfig                         |   94 ++
>>   drivers/input/rmi4/Makefile                        |   15 +
>>   drivers/input/rmi4/rmi_2d_sensor.c                 |  323 +++++
>>   drivers/input/rmi4/rmi_2d_sensor.h                 |   88 ++
>>   drivers/input/rmi4/rmi_bus.c                       |  419 ++++++
>>   drivers/input/rmi4/rmi_bus.h                       |  195 +++
>>   drivers/input/rmi4/rmi_driver.c                    | 1112 ++++++++++++++++
>>   drivers/input/rmi4/rmi_driver.h                    |  126 ++
>>   drivers/input/rmi4/rmi_f01.c                       |  570 ++++++++
>>   drivers/input/rmi4/rmi_f11.c                       | 1354 ++++++++++++++++++++
>>   drivers/input/rmi4/rmi_f12.c                       |  487 +++++++
>>   drivers/input/rmi4/rmi_f30.c                       |  419 ++++++
>>   drivers/input/rmi4/rmi_i2c.c                       |  270 ++++
>>   drivers/input/rmi4/rmi_spi.c                       |  464 +++++++
>>   include/linux/rmi.h                                |  415 ++++++
>>   include/uapi/linux/input.h                         |    1 +
>>   24 files changed, 6638 insertions(+), 846 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>>   create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
>>   create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
>>   create mode 100644 Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
>>   create mode 100644 drivers/input/rmi4/Kconfig
>>   create mode 100644 drivers/input/rmi4/Makefile
>>   create mode 100644 drivers/input/rmi4/rmi_2d_sensor.c
>>   create mode 100644 drivers/input/rmi4/rmi_2d_sensor.h
>>   create mode 100644 drivers/input/rmi4/rmi_bus.c
>>   create mode 100644 drivers/input/rmi4/rmi_bus.h
>>   create mode 100644 drivers/input/rmi4/rmi_driver.c
>>   create mode 100644 drivers/input/rmi4/rmi_driver.h
>>   create mode 100644 drivers/input/rmi4/rmi_f01.c
>>   create mode 100644 drivers/input/rmi4/rmi_f11.c
>>   create mode 100644 drivers/input/rmi4/rmi_f12.c
>>   create mode 100644 drivers/input/rmi4/rmi_f30.c
>>   create mode 100644 drivers/input/rmi4/rmi_i2c.c
>>   create mode 100644 drivers/input/rmi4/rmi_spi.c
>>   create mode 100644 include/linux/rmi.h
>>
>> -- 
>> 2.5.0
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279663 — Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3

FromLinus Walleij <linus.walleij@linaro.org>
Date2015-11-30 09:30 +0100
SubjectRe: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3
Message-ID<qAs0p-17U-1@gated-at.bofh.it>
In reply to#1277895
On Thu, Nov 26, 2015 at 1:07 AM, Andrew Duggan <aduggan@synaptics.com> wrote:

> I tried to include all of the feedback I received from the previous
> patches I posted. However, I did not come up with a satisfactory solution
> for allowing function drivers to be built as modules. I think it is fine
> to allow function drivers to be enabled or disabled in the core at build
> time.

I am happy with this. If people need something else they can put
in the work, I'm just happy to have my hardware working.

A large slew of the systems using this will be Androids with
tailored kernels anyway, they will all build this in.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web