* [PATCH v6 0/6] Add ChromeOS Embedded Controller support
@ 2013-02-25 22:08 Simon Glass
2013-02-25 22:08 ` [PATCH v6 5/6] Input: matrix-keymap: Add function to read the new DT binding Simon Glass
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Simon Glass @ 2013-02-25 22:08 UTC (permalink / raw)
To: LKML
Cc: Samuel Ortiz, Simon Glass, Rob Landley, Felipe Balbi,
Grant Likely, Wolfram Sang, Luigi Semenzato, Rob Herring,
Che-Liang Chiou, Jonathan Kliegman, linux-input, Sourav Poddar,
devicetree-discuss, Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc, Dmitry Torokhov,
Tony Lindgren, Bill Pemberton
The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.
Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.
This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.
This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.
Changes in v6:
- Allow cros_ec to be a module
- Remove 'struct i2c_msg' definition
- Use %ph instead of for loop to output packet trace
- Fix incorrect indentation in cros_ec_keyb_process()
- Remove unnecessary assignment to NULL in probe function
Changes in v5:
- Remove cros_ec allocation functions
- Remove name access functions in cros_ec, using strings instead
- Fix Kconfig help message for MFD_CROS_EC_I2C
- Remove I2C retry logic
- Switch cros_ec_i2c driver to use devm
- Update cros_ec_i2c to work with new cros_ec interface
- Switch cros_ec_spi driver to use devm
- Update cros_ec_spi to work with new cros_ec interface
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm
Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required
Changes in v3:
- Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
- Put back full DT range checking in tca8418 driver
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev->key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()
Changes in v2:
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Add new patch to decode matrix-keypad DT binding
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols
Simon Glass (6):
mfd: Add ChromeOS EC messages header
mfd: Add ChromeOS EC implementation
mfd: Add ChromeOS EC I2C driver
mfd: Add ChromeOS EC SPI driver
Input: matrix-keymap: Add function to read the new DT binding
Input: Add ChromeOS EC keyboard driver
.../devicetree/bindings/input/cros-ec-keyb.txt | 72 +
Documentation/devicetree/bindings/mfd/cros-ec.txt | 56 +
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/cros_ec_keyb.c | 334 +++++
drivers/input/keyboard/lpc32xx-keys.c | 11 +-
drivers/input/keyboard/omap4-keypad.c | 16 +-
drivers/input/keyboard/tca8418_keypad.c | 7 +-
drivers/input/matrix-keymap.c | 19 +
drivers/mfd/Kconfig | 28 +
drivers/mfd/Makefile | 3 +
drivers/mfd/cros_ec.c | 189 +++
drivers/mfd/cros_ec_i2c.c | 206 +++
drivers/mfd/cros_ec_spi.c | 375 ++++++
include/linux/input/matrix_keypad.h | 19 +
include/linux/mfd/cros_ec.h | 170 +++
include/linux/mfd/cros_ec_commands.h | 1369 ++++++++++++++++++++
17 files changed, 2869 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
create mode 100644 drivers/mfd/cros_ec.c
create mode 100644 drivers/mfd/cros_ec_i2c.c
create mode 100644 drivers/mfd/cros_ec_spi.c
create mode 100644 include/linux/mfd/cros_ec.h
create mode 100644 include/linux/mfd/cros_ec_commands.h
--
1.8.1.3
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v6 5/6] Input: matrix-keymap: Add function to read the new DT binding
2013-02-25 22:08 [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
@ 2013-02-25 22:08 ` Simon Glass
[not found] ` <1361830121-32284-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Simon Glass @ 2013-02-25 22:08 UTC (permalink / raw)
To: LKML
Cc: Samuel Ortiz, Simon Glass, Dmitry Torokhov, Bill Pemberton,
Mark Brown, Javier Martinez Canillas, Sourav Poddar, Felipe Balbi,
Alban Bedel, linux-input
We now have a binding which adds two parameters to the matrix keypad DT
node. This is separate from the GPIO-driven matrix keypad binding, and
unfortunately incompatible, since that uses row-gpios/col-gpios for the
row and column counts.
So the easiest option here is to provide a function for non-GPIO drivers
to use to decode the binding.
Note: We could in fact create an entirely separate structure to hold
these two fields, but it does not seem worth it, yet. If we have more
parameters then we can add this, and then refactor each driver to hold
such a structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com> (v2)
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
- Put back full DT range checking in tca8418 driver
Changes in v2:
- Add new patch to decode matrix-keypad DT binding
drivers/input/keyboard/lpc32xx-keys.c | 11 ++++++-----
drivers/input/keyboard/omap4-keypad.c | 16 +++++-----------
drivers/input/keyboard/tca8418_keypad.c | 7 +++++--
drivers/input/matrix-keymap.c | 19 +++++++++++++++++++
include/linux/input/matrix_keypad.h | 19 +++++++++++++++++++
5 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/drivers/input/keyboard/lpc32xx-keys.c b/drivers/input/keyboard/lpc32xx-keys.c
index 1b8add6..4218143 100644
--- a/drivers/input/keyboard/lpc32xx-keys.c
+++ b/drivers/input/keyboard/lpc32xx-keys.c
@@ -144,12 +144,13 @@ static int lpc32xx_parse_dt(struct device *dev,
{
struct device_node *np = dev->of_node;
u32 rows = 0, columns = 0;
+ int err;
- of_property_read_u32(np, "keypad,num-rows", &rows);
- of_property_read_u32(np, "keypad,num-columns", &columns);
- if (!rows || rows != columns) {
- dev_err(dev,
- "rows and columns must be specified and be equal!\n");
+ err = matrix_keypad_parse_of_params(dev, &rows, &columns);
+ if (err)
+ return err;
+ if (rows != columns) {
+ dev_err(dev, "rows and columns must be equal!\n");
return -EINVAL;
}
diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
index e25b022..1b28909 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -215,18 +215,12 @@ static int omap4_keypad_parse_dt(struct device *dev,
struct omap4_keypad *keypad_data)
{
struct device_node *np = dev->of_node;
+ int err;
- if (!np) {
- dev_err(dev, "missing DT data");
- return -EINVAL;
- }
-
- of_property_read_u32(np, "keypad,num-rows", &keypad_data->rows);
- of_property_read_u32(np, "keypad,num-columns", &keypad_data->cols);
- if (!keypad_data->rows || !keypad_data->cols) {
- dev_err(dev, "number of keypad rows/columns not specified\n");
- return -EINVAL;
- }
+ err = matrix_keypad_parse_of_params(dev, &keypad_data->rows,
+ &keypad_data->cols);
+ if (err)
+ return err;
if (of_get_property(np, "linux,input-no-autorepeat", NULL))
keypad_data->no_autorepeat = true;
diff --git a/drivers/input/keyboard/tca8418_keypad.c b/drivers/input/keyboard/tca8418_keypad.c
index a34cc67..55c1530 100644
--- a/drivers/input/keyboard/tca8418_keypad.c
+++ b/drivers/input/keyboard/tca8418_keypad.c
@@ -288,8 +288,11 @@ static int tca8418_keypad_probe(struct i2c_client *client,
irq_is_gpio = pdata->irq_is_gpio;
} else {
struct device_node *np = dev->of_node;
- of_property_read_u32(np, "keypad,num-rows", &rows);
- of_property_read_u32(np, "keypad,num-columns", &cols);
+ int err;
+
+ err = matrix_keypad_parse_of_params(dev, &rows, &cols);
+ if (err)
+ return err;
rep = of_property_read_bool(np, "keypad,autorepeat");
}
diff --git a/drivers/input/matrix-keymap.c b/drivers/input/matrix-keymap.c
index 3ae496e..619b382 100644
--- a/drivers/input/matrix-keymap.c
+++ b/drivers/input/matrix-keymap.c
@@ -50,6 +50,25 @@ static bool matrix_keypad_map_key(struct input_dev *input_dev,
}
#ifdef CONFIG_OF
+int matrix_keypad_parse_of_params(struct device *dev,
+ unsigned int *rows, unsigned int *cols)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ dev_err(dev, "missing DT data");
+ return -EINVAL;
+ }
+ of_property_read_u32(np, "keypad,num-rows", rows);
+ of_property_read_u32(np, "keypad,num-columns", cols);
+ if (!*rows || !*cols) {
+ dev_err(dev, "number of keypad rows/columns not specified\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int matrix_keypad_parse_of_keymap(const char *propname,
unsigned int rows, unsigned int cols,
struct input_dev *input_dev)
diff --git a/include/linux/input/matrix_keypad.h b/include/linux/input/matrix_keypad.h
index 5f3aa6b..27e06ac 100644
--- a/include/linux/input/matrix_keypad.h
+++ b/include/linux/input/matrix_keypad.h
@@ -81,4 +81,23 @@ int matrix_keypad_build_keymap(const struct matrix_keymap_data *keymap_data,
unsigned short *keymap,
struct input_dev *input_dev);
+#ifdef CONFIG_OF
+/**
+ * matrix_keypad_parse_of_params() - Read parameters from matrix-keypad node
+ *
+ * @dev: Device containing of_node
+ * @rows: Returns number of matrix rows
+ * @cols: Returns number of matrix columns
+ * @return 0 if OK, <0 on error
+ */
+int matrix_keypad_parse_of_params(struct device *dev,
+ unsigned int *rows, unsigned int *cols);
+#else
+static inline int matrix_keypad_parse_of_params(struct device *dev,
+ unsigned int *rows, unsigned int *cols)
+{
+ return -ENOSYS;
+}
+#endif /* CONFIG_OF */
+
#endif /* _MATRIX_KEYPAD_H */
--
1.8.1.3
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v6 6/6] Input: Add ChromeOS EC keyboard driver
[not found] ` <1361830121-32284-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-02-25 22:08 ` Simon Glass
2013-02-25 22:12 ` Dmitry Torokhov
0 siblings, 1 reply; 14+ messages in thread
From: Simon Glass @ 2013-02-25 22:08 UTC (permalink / raw)
To: LKML
Cc: Roland Stigge, Vincent Palatin, Samuel Ortiz,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov, Wolfram Sang,
Rob Herring, Luigi Semenzato, Felipe Balbi,
linux-input-u79uwXL29TY76Z2rM5mHXA, Sourav Poddar,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.
The matrix-keypad FDT binding is used with a small addition to control
ghosting.
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Luigi Semenzato <semenzato-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v6:
- Fix incorrect indentation in cros_ec_keyb_process()
- Remove unnecessary assignment to NULL in probe function
Changes in v5:
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm
Changes in v4:
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required
Changes in v3:
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev->key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()
Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols
.../devicetree/bindings/input/cros-ec-keyb.txt | 72 +++++
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/cros_ec_keyb.c | 334 +++++++++++++++++++++
4 files changed, 419 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 0000000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 5a240c6..a087d3f 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -618,4 +618,16 @@ config KEYBOARD_W90P910
To compile this driver as a module, choose M here: the
module will be called w90p910_keypad.
+config KEYBOARD_CROS_EC
+ tristate "ChromeOS EC keyboard"
+ select INPUT_MATRIXKMAP
+ depends on MFD_CROS_EC
+ help
+ Say Y here to enable the matrix keyboard used by ChromeOS devices
+ and implemented on the ChromeOS EC. You must enable one bus option
+ (MFD_CROS_EC_I2C or MFD_CROS_EC_SPI) to use this.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_keyb.
+
endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..61b739c 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BFIN) += bf54x-keys.o
+obj-$(CONFIG_KEYBOARD_CROS_EC) += cros_ec_keyb.o
obj-$(CONFIG_KEYBOARD_DAVINCI) += davinci_keyscan.o
obj-$(CONFIG_KEYBOARD_EP93XX) += ep93xx_keypad.o
obj-$(CONFIG_KEYBOARD_GPIO) += gpio_keys.o
diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
new file mode 100644
index 0000000..49557f2
--- /dev/null
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -0,0 +1,334 @@
+/*
+ * ChromeOS EC keyboard driver
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard EC
+ * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
+ * but everything else (including deghosting) is done here. The main
+ * motivation for this is to keep the EC firmware as simple as possible, since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/kernel.h>
+#include <linux/notifier.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/mfd/cros_ec.h>
+#include <linux/mfd/cros_ec_commands.h>
+
+/*
+ * @rows: Number of rows in the keypad
+ * @cols: Number of columns in the keypad
+ * @row_shift: log2 or number of rows, rounded up
+ * @keymap_data: Matrix keymap data used to convert to keyscan values
+ * @ghost_filter: true to enable the matrix key-ghosting filter
+ * @dev: Device pointer
+ * @idev: Input device
+ * @ec: Top level ChromeOS device to use to talk to EC
+ * @event_notifier: interrupt event notifier for transport devices
+ */
+struct cros_ec_keyb {
+ unsigned int rows;
+ unsigned int cols;
+ int row_shift;
+ const struct matrix_keymap_data *keymap_data;
+ bool ghost_filter;
+
+ struct device *dev;
+ struct input_dev *idev;
+ struct cros_ec_device *ec;
+ struct notifier_block notifier;
+};
+
+
+static bool cros_ec_keyb_row_has_ghosting(struct cros_ec_keyb *ckdev,
+ uint8_t *buf, int row)
+{
+ int pressed_in_row = 0;
+ int row_has_teeth = 0;
+ int col, mask;
+
+ mask = 1 << row;
+ for (col = 0; col < ckdev->cols; col++) {
+ if (buf[col] & mask) {
+ pressed_in_row++;
+ row_has_teeth |= buf[col] & ~mask;
+ if (pressed_in_row > 1 && row_has_teeth) {
+ /* ghosting */
+ dev_dbg(ckdev->dev,
+ "ghost found at: r%d c%d, pressed %d, teeth 0x%x\n",
+ row, col, pressed_in_row,
+ row_has_teeth);
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
+/*
+ * Returns true when there is at least one combination of pressed keys that
+ * results in ghosting.
+ */
+static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t *buf)
+{
+ int row;
+
+ /*
+ * Ghosting happens if for any pressed key X there are other keys
+ * pressed both in the same row and column of X as, for instance,
+ * in the following diagram:
+ *
+ * . . Y . g .
+ * . . . . . .
+ * . . . . . .
+ * . . X . Z .
+ *
+ * In this case only X, Y, and Z are pressed, but g appears to be
+ * pressed too (see Wikipedia).
+ *
+ * We can detect ghosting in a single pass (*) over the keyboard state
+ * by maintaining two arrays. pressed_in_row counts how many pressed
+ * keys we have found in a row. row_has_teeth is true if any of the
+ * pressed keys for this row has other pressed keys in its column. If
+ * at any point of the scan we find that a row has multiple pressed
+ * keys, and at least one of them is at the intersection with a column
+ * with multiple pressed keys, we're sure there is ghosting.
+ * Conversely, if there is ghosting, we will detect such situation for
+ * at least one key during the pass.
+ *
+ * (*) This looks linear in the number of keys, but it's not. We can
+ * cheat because the number of rows is small.
+ */
+ for (row = 0; row < ckdev->rows; row++)
+ if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
+ return true;
+
+ return false;
+}
+
+/*
+ * Compares the new keyboard state to the old one and produces key
+ * press/release events accordingly. The keyboard state is 13 bytes (one byte
+ * per column)
+ */
+static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
+ uint8_t *kb_state, int len)
+{
+ struct input_dev *idev = ckdev->idev;
+ int col, row;
+ int new_state;
+ int num_cols;
+
+ num_cols = len;
+
+ if (ckdev->ghost_filter && cros_ec_keyb_has_ghosting(ckdev, kb_state)) {
+ /*
+ * Simple-minded solution: ignore this state. The obvious
+ * improvement is to only ignore changes to keys involved in
+ * the ghosting, but process the other changes.
+ */
+ dev_dbg(ckdev->dev, "ghosting found\n");
+ return;
+ }
+
+ for (col = 0; col < ckdev->cols; col++) {
+ for (row = 0; row < ckdev->rows; row++) {
+ int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
+ const unsigned short *keycodes = idev->keycode;
+ int code;
+
+ code = keycodes[pos];
+ new_state = kb_state[col] & (1 << row);
+ if (!!new_state != test_bit(code, idev->key)) {
+ dev_dbg(ckdev->dev,
+ "changed: [r%d c%d]: byte %02x\n",
+ row, col, new_state);
+
+ input_report_key(idev, code, new_state);
+ }
+ }
+ }
+ input_sync(ckdev->idev);
+}
+
+static int cros_ec_keyb_open(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+
+ return blocking_notifier_chain_register(&ckdev->ec->event_notifier,
+ &ckdev->notifier);
+}
+
+static void cros_ec_keyb_close(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+
+ blocking_notifier_chain_unregister(&ckdev->ec->event_notifier,
+ &ckdev->notifier);
+}
+
+static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
+{
+ return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
+ kb_state, ckdev->cols);
+}
+
+static int cros_ec_keyb_work(struct notifier_block *nb,
+ unsigned long state, void *_notify)
+{
+ int ret;
+ struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
+ notifier);
+ uint8_t kb_state[ckdev->cols];
+
+ ret = cros_ec_keyb_get_state(ckdev, kb_state);
+ if (ret >= 0)
+ cros_ec_keyb_process(ckdev, kb_state, ret);
+
+ return NOTIFY_DONE;
+}
+
+/* Clear any keys in the buffer */
+static void cros_ec_keyb_clear_keyboard(struct cros_ec_keyb *ckdev)
+{
+ uint8_t old_state[ckdev->cols];
+ uint8_t new_state[ckdev->cols];
+ unsigned long duration;
+ int i, ret;
+
+ /*
+ * Keep reading until we see that the scan state does not change.
+ * That indicates that we are done.
+ *
+ * Assume that the EC keyscan buffer is at most 32 deep.
+ */
+ duration = jiffies;
+ ret = cros_ec_keyb_get_state(ckdev, new_state);
+ for (i = 1; !ret && i < 32; i++) {
+ memcpy(old_state, new_state, sizeof(old_state));
+ ret = cros_ec_keyb_get_state(ckdev, new_state);
+ if (0 == memcmp(old_state, new_state, sizeof(old_state)))
+ break;
+ }
+ duration = jiffies - duration;
+ dev_info(ckdev->dev, "Discarded %d keyscan(s) in %dus\n", i,
+ jiffies_to_usecs(duration));
+}
+
+static int cros_ec_keyb_probe(struct platform_device *pdev)
+{
+ struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = ec->dev;
+ struct cros_ec_keyb *ckdev;
+ struct input_dev *idev;
+ struct device_node *np;
+ int err;
+
+ np = pdev->dev.of_node;
+ if (!np)
+ return -ENODEV;
+
+ ckdev = devm_kzalloc(&pdev->dev, sizeof(*ckdev), GFP_KERNEL);
+ if (!ckdev)
+ return -ENOMEM;
+ err = matrix_keypad_parse_of_params(&pdev->dev, &ckdev->rows,
+ &ckdev->cols);
+ if (err)
+ return err;
+
+ idev = devm_input_allocate_device(&pdev->dev);
+ if (!idev)
+ return -ENOMEM;
+
+ ckdev->ec = ec;
+ ckdev->notifier.notifier_call = cros_ec_keyb_work;
+ ckdev->dev = dev;
+ dev_set_drvdata(&pdev->dev, ckdev);
+
+ idev->name = ec->ec_name;
+ idev->phys = ec->phys_name;
+ __set_bit(EV_REP, idev->evbit);
+
+ idev->id.bustype = BUS_VIRTUAL;
+ idev->id.version = 1;
+ idev->id.product = 0;
+ idev->dev.parent = &pdev->dev;
+ idev->open = cros_ec_keyb_open;
+ idev->close = cros_ec_keyb_close;
+
+ ckdev->ghost_filter = of_property_read_bool(np,
+ "google,needs-ghost-filter");
+
+ err = matrix_keypad_build_keymap(NULL, NULL, ckdev->rows, ckdev->cols,
+ NULL, idev);
+ if (err) {
+ dev_err(dev, "cannot build key matrix\n");
+ return err;
+ }
+
+ ckdev->row_shift = get_count_order(ckdev->cols);
+
+ input_set_capability(idev, EV_MSC, MSC_SCAN);
+ input_set_drvdata(idev, ckdev);
+ ckdev->idev = idev;
+ err = input_register_device(ckdev->idev);
+ if (err) {
+ dev_err(dev, "cannot register input device\n");
+ return err;
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int cros_ec_keyb_resume(struct device *dev)
+{
+ struct cros_ec_keyb *ckdev = dev_get_drvdata(dev);
+
+ /*
+ * When the EC is not a wake source, then it could not have caused the
+ * resume, so we clear the EC's key scan buffer. If the EC was a
+ * wake source (e.g. the lid is open and the user might press a key to
+ * wake) then the key scan buffer should be preserved.
+ */
+ if (ckdev->ec->was_wake_device)
+ cros_ec_keyb_clear_keyboard(ckdev);
+
+ return 0;
+}
+
+#endif
+
+static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
+
+static struct platform_driver cros_ec_keyb_driver = {
+ .probe = cros_ec_keyb_probe,
+ .driver = {
+ .name = "cros-ec-keyb",
+ .pm = &cros_ec_keyb_pm_ops,
+ },
+};
+
+module_platform_driver(cros_ec_keyb_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ChromeOS EC keyboard driver");
+MODULE_ALIAS("platform:cros-ec-keyb");
--
1.8.1.3
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v6 6/6] Input: Add ChromeOS EC keyboard driver
2013-02-25 22:08 ` [PATCH v6 6/6] Input: Add ChromeOS EC keyboard driver Simon Glass
@ 2013-02-25 22:12 ` Dmitry Torokhov
0 siblings, 0 replies; 14+ messages in thread
From: Dmitry Torokhov @ 2013-02-25 22:12 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Samuel Ortiz, Luigi Semenzato, Vincent Palatin,
Grant Likely, Rob Herring, Rob Landley, Sourav Poddar,
Felipe Balbi, Tony Lindgren, Roland Stigge, Wolfram Sang,
devicetree-discuss, linux-doc, linux-input
On Mon, Feb 25, 2013 at 02:08:41PM -0800, Simon Glass wrote:
> Use the key-matrix layer to interpret key scan information from the EC
> and inject input based on the FDT-supplied key map. This driver registers
> itself with the ChromeOS EC driver to perform communications.
>
> The matrix-keypad FDT binding is used with a small addition to control
> ghosting.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
> Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> Changes in v6:
> - Fix incorrect indentation in cros_ec_keyb_process()
> - Remove unnecessary assignment to NULL in probe function
>
> Changes in v5:
> - Fix {} style nit in cros_ec_keyb_has_ghosting
> - Correct key lookup logic which was broken in previous version
> - Switch cros_ec_keyb driver to use devm
>
> Changes in v4:
> - Add 'depends on MFD_CROS_EC' to Kconfig
> - Remove use of wake_notifier
> - Remove manual code to locate device tree node
> - Add resume handler to clear keyboard scan buffer if required
>
> Changes in v3:
> - Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
> - Remove old_state by using input layer's idev->key
> - Move inner loop of cros_ec_keyb_has_ghosting() into its own function and simplify
> - Add check for not finding the device tree node
> - Remove comment about leaking matrix_keypad_build_keymap()
> - Use platform_get_drvdata() where possible
> - Remove call to input_free_device() after input_unregister_device()
>
> Changes in v2:
> - Remove use of __devinit/__devexit
> - Use function to read matrix-keypad parameters from DT
> - Remove key autorepeat parameters from DT binding and driver
> - Use unsigned int for rows/cols
>
> .../devicetree/bindings/input/cros-ec-keyb.txt | 72 +++++
> drivers/input/keyboard/Kconfig | 12 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/cros_ec_keyb.c | 334 +++++++++++++++++++++
> 4 files changed, 419 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
>
> diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> new file mode 100644
> index 0000000..0f6355c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> @@ -0,0 +1,72 @@
> +ChromeOS EC Keyboard
> +
> +Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
> +a separate EC (Embedded Controller) device. It provides a message for reading
> +key scans from the EC. These are then converted into keycodes for processing
> +by the kernel.
> +
> +This binding is based on matrix-keymap.txt and extends/modifies it as follows:
> +
> +Required properties:
> +- compatible: "google,cros-ec-keyb"
> +
> +Optional properties:
> +- google,needs-ghost-filter: True to enable a ghost filter for the matrix
> +keyboard. This is recommended if the EC does not have its own logic or
> +hardware for this.
> +
> +
> +Example:
> +
> +cros-ec-keyb {
> + compatible = "google,cros-ec-keyb";
> + keypad,num-rows = <8>;
> + keypad,num-columns = <13>;
> + google,needs-ghost-filter;
> + /*
> + * Keymap entries take the form of 0xRRCCKKKK where
> + * RR=Row CC=Column KKKK=Key Code
> + * The values below are for a US keyboard layout and
> + * are taken from the Linux driver. Note that the
> + * 102ND key is not used for US keyboards.
> + */
> + linux,keymap = <
> + /* CAPSLCK F1 B F10 */
> + 0x0001003a 0x0002003b 0x00030030 0x00040044
> + /* N = R_ALT ESC */
> + 0x00060031 0x0008000d 0x000a0064 0x01010001
> + /* F4 G F7 H */
> + 0x0102003e 0x01030022 0x01040041 0x01060023
> + /* ' F9 BKSPACE L_CTRL */
> + 0x01080028 0x01090043 0x010b000e 0x0200001d
> + /* TAB F3 T F6 */
> + 0x0201000f 0x0202003d 0x02030014 0x02040040
> + /* ] Y 102ND [ */
> + 0x0205001b 0x02060015 0x02070056 0x0208001a
> + /* F8 GRAVE F2 5 */
> + 0x02090042 0x03010029 0x0302003c 0x03030006
> + /* F5 6 - \ */
> + 0x0304003f 0x03060007 0x0308000c 0x030b002b
> + /* R_CTRL A D F */
> + 0x04000061 0x0401001e 0x04020020 0x04030021
> + /* S K J ; */
> + 0x0404001f 0x04050025 0x04060024 0x04080027
> + /* L ENTER Z C */
> + 0x04090026 0x040b001c 0x0501002c 0x0502002e
> + /* V X , M */
> + 0x0503002f 0x0504002d 0x05050033 0x05060032
> + /* L_SHIFT / . SPACE */
> + 0x0507002a 0x05080035 0x05090034 0x050B0039
> + /* 1 3 4 2 */
> + 0x06010002 0x06020004 0x06030005 0x06040003
> + /* 8 7 0 9 */
> + 0x06050009 0x06060008 0x0608000b 0x0609000a
> + /* L_ALT DOWN RIGHT Q */
> + 0x060a0038 0x060b006c 0x060c006a 0x07010010
> + /* E R W I */
> + 0x07020012 0x07030013 0x07040011 0x07050017
> + /* U R_SHIFT P O */
> + 0x07060016 0x07070036 0x07080019 0x07090018
> + /* UP LEFT */
> + 0x070b0067 0x070c0069>;
> +};
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 5a240c6..a087d3f 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -618,4 +618,16 @@ config KEYBOARD_W90P910
> To compile this driver as a module, choose M here: the
> module will be called w90p910_keypad.
>
> +config KEYBOARD_CROS_EC
> + tristate "ChromeOS EC keyboard"
> + select INPUT_MATRIXKMAP
> + depends on MFD_CROS_EC
> + help
> + Say Y here to enable the matrix keyboard used by ChromeOS devices
> + and implemented on the ChromeOS EC. You must enable one bus option
> + (MFD_CROS_EC_I2C or MFD_CROS_EC_SPI) to use this.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_keyb.
> +
> endif
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 44e7600..61b739c 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
> obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
> obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
> obj-$(CONFIG_KEYBOARD_BFIN) += bf54x-keys.o
> +obj-$(CONFIG_KEYBOARD_CROS_EC) += cros_ec_keyb.o
> obj-$(CONFIG_KEYBOARD_DAVINCI) += davinci_keyscan.o
> obj-$(CONFIG_KEYBOARD_EP93XX) += ep93xx_keypad.o
> obj-$(CONFIG_KEYBOARD_GPIO) += gpio_keys.o
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c
> new file mode 100644
> index 0000000..49557f2
> --- /dev/null
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -0,0 +1,334 @@
> +/*
> + * ChromeOS EC keyboard driver
> + *
> + * Copyright (C) 2012 Google, Inc
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * This driver uses the Chrome OS EC byte-level message-based protocol for
> + * communicating the keyboard state (which keys are pressed) from a keyboard EC
> + * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
> + * but everything else (including deghosting) is done here. The main
> + * motivation for this is to keep the EC firmware as simple as possible, since
> + * it cannot be easily upgraded and EC flash/IRAM space is relatively
> + * expensive.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/kernel.h>
> +#include <linux/notifier.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/input/matrix_keypad.h>
> +#include <linux/mfd/cros_ec.h>
> +#include <linux/mfd/cros_ec_commands.h>
> +
> +/*
> + * @rows: Number of rows in the keypad
> + * @cols: Number of columns in the keypad
> + * @row_shift: log2 or number of rows, rounded up
> + * @keymap_data: Matrix keymap data used to convert to keyscan values
> + * @ghost_filter: true to enable the matrix key-ghosting filter
> + * @dev: Device pointer
> + * @idev: Input device
> + * @ec: Top level ChromeOS device to use to talk to EC
> + * @event_notifier: interrupt event notifier for transport devices
> + */
> +struct cros_ec_keyb {
> + unsigned int rows;
> + unsigned int cols;
> + int row_shift;
> + const struct matrix_keymap_data *keymap_data;
> + bool ghost_filter;
> +
> + struct device *dev;
> + struct input_dev *idev;
> + struct cros_ec_device *ec;
> + struct notifier_block notifier;
> +};
> +
> +
> +static bool cros_ec_keyb_row_has_ghosting(struct cros_ec_keyb *ckdev,
> + uint8_t *buf, int row)
> +{
> + int pressed_in_row = 0;
> + int row_has_teeth = 0;
> + int col, mask;
> +
> + mask = 1 << row;
> + for (col = 0; col < ckdev->cols; col++) {
> + if (buf[col] & mask) {
> + pressed_in_row++;
> + row_has_teeth |= buf[col] & ~mask;
> + if (pressed_in_row > 1 && row_has_teeth) {
> + /* ghosting */
> + dev_dbg(ckdev->dev,
> + "ghost found at: r%d c%d, pressed %d, teeth 0x%x\n",
> + row, col, pressed_in_row,
> + row_has_teeth);
> + return true;
> + }
> + }
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Returns true when there is at least one combination of pressed keys that
> + * results in ghosting.
> + */
> +static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t *buf)
> +{
> + int row;
> +
> + /*
> + * Ghosting happens if for any pressed key X there are other keys
> + * pressed both in the same row and column of X as, for instance,
> + * in the following diagram:
> + *
> + * . . Y . g .
> + * . . . . . .
> + * . . . . . .
> + * . . X . Z .
> + *
> + * In this case only X, Y, and Z are pressed, but g appears to be
> + * pressed too (see Wikipedia).
> + *
> + * We can detect ghosting in a single pass (*) over the keyboard state
> + * by maintaining two arrays. pressed_in_row counts how many pressed
> + * keys we have found in a row. row_has_teeth is true if any of the
> + * pressed keys for this row has other pressed keys in its column. If
> + * at any point of the scan we find that a row has multiple pressed
> + * keys, and at least one of them is at the intersection with a column
> + * with multiple pressed keys, we're sure there is ghosting.
> + * Conversely, if there is ghosting, we will detect such situation for
> + * at least one key during the pass.
> + *
> + * (*) This looks linear in the number of keys, but it's not. We can
> + * cheat because the number of rows is small.
> + */
> + for (row = 0; row < ckdev->rows; row++)
> + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
> + return true;
> +
> + return false;
> +}
> +
> +/*
> + * Compares the new keyboard state to the old one and produces key
> + * press/release events accordingly. The keyboard state is 13 bytes (one byte
> + * per column)
> + */
> +static void cros_ec_keyb_process(struct cros_ec_keyb *ckdev,
> + uint8_t *kb_state, int len)
> +{
> + struct input_dev *idev = ckdev->idev;
> + int col, row;
> + int new_state;
> + int num_cols;
> +
> + num_cols = len;
> +
> + if (ckdev->ghost_filter && cros_ec_keyb_has_ghosting(ckdev, kb_state)) {
> + /*
> + * Simple-minded solution: ignore this state. The obvious
> + * improvement is to only ignore changes to keys involved in
> + * the ghosting, but process the other changes.
> + */
> + dev_dbg(ckdev->dev, "ghosting found\n");
> + return;
> + }
> +
> + for (col = 0; col < ckdev->cols; col++) {
> + for (row = 0; row < ckdev->rows; row++) {
> + int pos = MATRIX_SCAN_CODE(row, col, ckdev->row_shift);
> + const unsigned short *keycodes = idev->keycode;
> + int code;
> +
> + code = keycodes[pos];
> + new_state = kb_state[col] & (1 << row);
> + if (!!new_state != test_bit(code, idev->key)) {
> + dev_dbg(ckdev->dev,
> + "changed: [r%d c%d]: byte %02x\n",
> + row, col, new_state);
> +
> + input_report_key(idev, code, new_state);
> + }
> + }
> + }
> + input_sync(ckdev->idev);
> +}
> +
> +static int cros_ec_keyb_open(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> +
> + return blocking_notifier_chain_register(&ckdev->ec->event_notifier,
> + &ckdev->notifier);
> +}
> +
> +static void cros_ec_keyb_close(struct input_dev *dev)
> +{
> + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
> +
> + blocking_notifier_chain_unregister(&ckdev->ec->event_notifier,
> + &ckdev->notifier);
> +}
> +
> +static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t *kb_state)
> +{
> + return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
> + kb_state, ckdev->cols);
> +}
> +
> +static int cros_ec_keyb_work(struct notifier_block *nb,
> + unsigned long state, void *_notify)
> +{
> + int ret;
> + struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
> + notifier);
> + uint8_t kb_state[ckdev->cols];
> +
> + ret = cros_ec_keyb_get_state(ckdev, kb_state);
> + if (ret >= 0)
> + cros_ec_keyb_process(ckdev, kb_state, ret);
> +
> + return NOTIFY_DONE;
> +}
> +
> +/* Clear any keys in the buffer */
> +static void cros_ec_keyb_clear_keyboard(struct cros_ec_keyb *ckdev)
> +{
> + uint8_t old_state[ckdev->cols];
> + uint8_t new_state[ckdev->cols];
> + unsigned long duration;
> + int i, ret;
> +
> + /*
> + * Keep reading until we see that the scan state does not change.
> + * That indicates that we are done.
> + *
> + * Assume that the EC keyscan buffer is at most 32 deep.
> + */
> + duration = jiffies;
> + ret = cros_ec_keyb_get_state(ckdev, new_state);
> + for (i = 1; !ret && i < 32; i++) {
> + memcpy(old_state, new_state, sizeof(old_state));
> + ret = cros_ec_keyb_get_state(ckdev, new_state);
> + if (0 == memcmp(old_state, new_state, sizeof(old_state)))
> + break;
> + }
> + duration = jiffies - duration;
> + dev_info(ckdev->dev, "Discarded %d keyscan(s) in %dus\n", i,
> + jiffies_to_usecs(duration));
> +}
> +
> +static int cros_ec_keyb_probe(struct platform_device *pdev)
> +{
> + struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
> + struct device *dev = ec->dev;
> + struct cros_ec_keyb *ckdev;
> + struct input_dev *idev;
> + struct device_node *np;
> + int err;
> +
> + np = pdev->dev.of_node;
> + if (!np)
> + return -ENODEV;
> +
> + ckdev = devm_kzalloc(&pdev->dev, sizeof(*ckdev), GFP_KERNEL);
> + if (!ckdev)
> + return -ENOMEM;
> + err = matrix_keypad_parse_of_params(&pdev->dev, &ckdev->rows,
> + &ckdev->cols);
> + if (err)
> + return err;
> +
> + idev = devm_input_allocate_device(&pdev->dev);
> + if (!idev)
> + return -ENOMEM;
> +
> + ckdev->ec = ec;
> + ckdev->notifier.notifier_call = cros_ec_keyb_work;
> + ckdev->dev = dev;
> + dev_set_drvdata(&pdev->dev, ckdev);
> +
> + idev->name = ec->ec_name;
> + idev->phys = ec->phys_name;
> + __set_bit(EV_REP, idev->evbit);
> +
> + idev->id.bustype = BUS_VIRTUAL;
> + idev->id.version = 1;
> + idev->id.product = 0;
> + idev->dev.parent = &pdev->dev;
> + idev->open = cros_ec_keyb_open;
> + idev->close = cros_ec_keyb_close;
> +
> + ckdev->ghost_filter = of_property_read_bool(np,
> + "google,needs-ghost-filter");
> +
> + err = matrix_keypad_build_keymap(NULL, NULL, ckdev->rows, ckdev->cols,
> + NULL, idev);
> + if (err) {
> + dev_err(dev, "cannot build key matrix\n");
> + return err;
> + }
> +
> + ckdev->row_shift = get_count_order(ckdev->cols);
> +
> + input_set_capability(idev, EV_MSC, MSC_SCAN);
> + input_set_drvdata(idev, ckdev);
> + ckdev->idev = idev;
> + err = input_register_device(ckdev->idev);
> + if (err) {
> + dev_err(dev, "cannot register input device\n");
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int cros_ec_keyb_resume(struct device *dev)
> +{
> + struct cros_ec_keyb *ckdev = dev_get_drvdata(dev);
> +
> + /*
> + * When the EC is not a wake source, then it could not have caused the
> + * resume, so we clear the EC's key scan buffer. If the EC was a
> + * wake source (e.g. the lid is open and the user might press a key to
> + * wake) then the key scan buffer should be preserved.
> + */
> + if (ckdev->ec->was_wake_device)
> + cros_ec_keyb_clear_keyboard(ckdev);
> +
> + return 0;
> +}
> +
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(cros_ec_keyb_pm_ops, NULL, cros_ec_keyb_resume);
> +
> +static struct platform_driver cros_ec_keyb_driver = {
> + .probe = cros_ec_keyb_probe,
> + .driver = {
> + .name = "cros-ec-keyb",
> + .pm = &cros_ec_keyb_pm_ops,
> + },
> +};
> +
> +module_platform_driver(cros_ec_keyb_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ChromeOS EC keyboard driver");
> +MODULE_ALIAS("platform:cros-ec-keyb");
> --
> 1.8.1.3
>
--
Dmitry
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-02-25 22:08 [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
2013-02-25 22:08 ` [PATCH v6 5/6] Input: matrix-keymap: Add function to read the new DT binding Simon Glass
[not found] ` <1361830121-32284-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2013-02-27 5:13 ` Simon Glass
2013-02-27 8:40 ` Samuel Ortiz
2013-03-20 0:56 ` Samuel Ortiz
3 siblings, 1 reply; 14+ messages in thread
From: Simon Glass @ 2013-02-27 5:13 UTC (permalink / raw)
To: LKML, Samuel Ortiz
Cc: Simon Glass, Rob Landley, Felipe Balbi, Grant Likely,
Wolfram Sang, Luigi Semenzato, Rob Herring, Che-Liang Chiou,
Jonathan Kliegman, linux-input, Sourav Poddar, devicetree-discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc, Dmitry Torokhov,
Tony Lindgren, Bill Pemberton, Doug Anderson, Olof Johansson
Hi Samuel,
On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass <sjg@chromium.org> wrote:
> The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> line is used to indicate when the EC needs service.
>
> Functions performed by the EC vary by platform, but typically include
> battery charging, keyboard scanning and power sequencing.
>
> This series includes support for the EC message protocol, and implements
> a matrix keyboard handler for Linux using the protocol. The EC performs
> key scanning and passes scan data in response to AP requests. This is
> used on the Samsung ARM Chromebook. No driver is available for LPC at
> present.
>
> This series can in principle operate on any hardware, but for it to actually
> work on the Samsung ARM Chromebook, it needs patches which are currently in
> progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
>
> The driver is device-tree-enabled and a suitable binding is included in
> this series. Example device tree nodes are included in the examples,
> but no device tree patch for exynos5250-snow is provided at this stage, since
> we must wait for the above-mentioned patches to land to avoid errors from
> dtc. This can be added with a follow-on patch when that work is complete.
>
Are you happy with this series? Do you think it is ready to be picked
up for mfd?
Regards,
Simon
> Changes in v6:
> - Allow cros_ec to be a module
> - Remove 'struct i2c_msg' definition
> - Use %ph instead of for loop to output packet trace
> - Fix incorrect indentation in cros_ec_keyb_process()
> - Remove unnecessary assignment to NULL in probe function
>
> Changes in v5:
> - Remove cros_ec allocation functions
> - Remove name access functions in cros_ec, using strings instead
> - Fix Kconfig help message for MFD_CROS_EC_I2C
> - Remove I2C retry logic
> - Switch cros_ec_i2c driver to use devm
> - Update cros_ec_i2c to work with new cros_ec interface
> - Switch cros_ec_spi driver to use devm
> - Update cros_ec_spi to work with new cros_ec interface
> - Fix {} style nit in cros_ec_keyb_has_ghosting
> - Correct key lookup logic which was broken in previous version
> - Switch cros_ec_keyb driver to use devm
>
> Changes in v4:
> - Fix up trvial logging comments
> - Remove messages reporting out of memory
> - Add compatible string for cros-ec-keyb
> - Remove wake notifier and let drivers use their own handlers instead
> - Add 'depends on MFD_CROS_EC' to Kconfig
> - Remove use of wake_notifier
> - Remove manual code to locate device tree node
> - Add resume handler to clear keyboard scan buffer if required
>
> Changes in v3:
> - Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
> - Put back full DT range checking in tca8418 driver
> - Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
> - Remove old_state by using input layer's idev->key
> - Move inner loop of cros_ec_keyb_has_ghosting() into its own function and simplify
> - Add check for not finding the device tree node
> - Remove comment about leaking matrix_keypad_build_keymap()
> - Use platform_get_drvdata() where possible
> - Remove call to input_free_device() after input_unregister_device()
>
> Changes in v2:
> - Remove use of __devinit/__devexit
> - Remove use of __devinit/__devexit
> - Remove use of __devinit/__devexit
> - Add new patch to decode matrix-keypad DT binding
> - Remove use of __devinit/__devexit
> - Use function to read matrix-keypad parameters from DT
> - Remove key autorepeat parameters from DT binding and driver
> - Use unsigned int for rows/cols
>
> Simon Glass (6):
> mfd: Add ChromeOS EC messages header
> mfd: Add ChromeOS EC implementation
> mfd: Add ChromeOS EC I2C driver
> mfd: Add ChromeOS EC SPI driver
> Input: matrix-keymap: Add function to read the new DT binding
> Input: Add ChromeOS EC keyboard driver
>
> .../devicetree/bindings/input/cros-ec-keyb.txt | 72 +
> Documentation/devicetree/bindings/mfd/cros-ec.txt | 56 +
> drivers/input/keyboard/Kconfig | 12 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/cros_ec_keyb.c | 334 +++++
> drivers/input/keyboard/lpc32xx-keys.c | 11 +-
> drivers/input/keyboard/omap4-keypad.c | 16 +-
> drivers/input/keyboard/tca8418_keypad.c | 7 +-
> drivers/input/matrix-keymap.c | 19 +
> drivers/mfd/Kconfig | 28 +
> drivers/mfd/Makefile | 3 +
> drivers/mfd/cros_ec.c | 189 +++
> drivers/mfd/cros_ec_i2c.c | 206 +++
> drivers/mfd/cros_ec_spi.c | 375 ++++++
> include/linux/input/matrix_keypad.h | 19 +
> include/linux/mfd/cros_ec.h | 170 +++
> include/linux/mfd/cros_ec_commands.h | 1369 ++++++++++++++++++++
> 17 files changed, 2869 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
> create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
> create mode 100644 drivers/mfd/cros_ec.c
> create mode 100644 drivers/mfd/cros_ec_i2c.c
> create mode 100644 drivers/mfd/cros_ec_spi.c
> create mode 100644 include/linux/mfd/cros_ec.h
> create mode 100644 include/linux/mfd/cros_ec_commands.h
>
> --
> 1.8.1.3
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-02-27 5:13 ` [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
@ 2013-02-27 8:40 ` Samuel Ortiz
2013-02-28 0:25 ` Simon Glass
2013-03-18 18:41 ` Simon Glass
0 siblings, 2 replies; 14+ messages in thread
From: Samuel Ortiz @ 2013-02-27 8:40 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input, Sourav Poddar, devicetree-discuss, Alban Bedel,
Roland Stigge, Vincent Palatin, Javier Martinez Canillas,
Mark Brown, linux-doc, Dmitry Torokhov, Tony Lindgren,
Bill Pemberton, Doug Anderson, Olof Johansson
Hi Simon,
On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
> Hi Samuel,
>
> On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass <sjg@chromium.org> wrote:
> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> > line is used to indicate when the EC needs service.
> >
> > Functions performed by the EC vary by platform, but typically include
> > battery charging, keyboard scanning and power sequencing.
> >
> > This series includes support for the EC message protocol, and implements
> > a matrix keyboard handler for Linux using the protocol. The EC performs
> > key scanning and passes scan data in response to AP requests. This is
> > used on the Samsung ARM Chromebook. No driver is available for LPC at
> > present.
> >
> > This series can in principle operate on any hardware, but for it to actually
> > work on the Samsung ARM Chromebook, it needs patches which are currently in
> > progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
> >
> > The driver is device-tree-enabled and a suitable binding is included in
> > this series. Example device tree nodes are included in the examples,
> > but no device tree patch for exynos5250-snow is provided at this stage, since
> > we must wait for the above-mentioned patches to land to avoid errors from
> > dtc. This can be added with a follow-on patch when that work is complete.
> >
>
> Are you happy with this series? Do you think it is ready to be picked
> up for mfd?
It probably is, and it will be part of the next merge window. I'll apply the
after the merge window closes.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-02-27 8:40 ` Samuel Ortiz
@ 2013-02-28 0:25 ` Simon Glass
2013-03-18 18:41 ` Simon Glass
1 sibling, 0 replies; 14+ messages in thread
From: Simon Glass @ 2013-02-28 0:25 UTC (permalink / raw)
To: Samuel Ortiz
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input, Sourav Poddar, devicetree-discuss, Alban Bedel,
Roland Stigge, Vincent Palatin, Javier Martinez Canillas,
Mark Brown, linux-doc, Dmitry Torokhov, Tony Lindgren,
Bill Pemberton, Doug Anderson, Olof Johansson
Hi Samuel,
On Wed, Feb 27, 2013 at 12:40 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Simon,
>
> On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
>> Hi Samuel,
>>
>> On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass <sjg@chromium.org> wrote:
>> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
>> > line is used to indicate when the EC needs service.
>> >
>> > Functions performed by the EC vary by platform, but typically include
>> > battery charging, keyboard scanning and power sequencing.
>> >
>> > This series includes support for the EC message protocol, and implements
>> > a matrix keyboard handler for Linux using the protocol. The EC performs
>> > key scanning and passes scan data in response to AP requests. This is
>> > used on the Samsung ARM Chromebook. No driver is available for LPC at
>> > present.
>> >
>> > This series can in principle operate on any hardware, but for it to actually
>> > work on the Samsung ARM Chromebook, it needs patches which are currently in
>> > progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
>> >
>> > The driver is device-tree-enabled and a suitable binding is included in
>> > this series. Example device tree nodes are included in the examples,
>> > but no device tree patch for exynos5250-snow is provided at this stage, since
>> > we must wait for the above-mentioned patches to land to avoid errors from
>> > dtc. This can be added with a follow-on patch when that work is complete.
>> >
>>
>> Are you happy with this series? Do you think it is ready to be picked
>> up for mfd?
> It probably is, and it will be part of the next merge window. I'll apply the
> after the merge window closes.
Thank you.
Regards,
Simon
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-02-27 8:40 ` Samuel Ortiz
2013-02-28 0:25 ` Simon Glass
@ 2013-03-18 18:41 ` Simon Glass
1 sibling, 0 replies; 14+ messages in thread
From: Simon Glass @ 2013-03-18 18:41 UTC (permalink / raw)
To: Samuel Ortiz
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input@vger.kernel.org, Sourav Poddar, Devicetree Discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc@vger.kernel.org,
Dmitry Torokhov, Tony Lindgren, Bill Pemberton
Hi Samuel,
On Wed, Feb 27, 2013 at 12:40 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Simon,
>
> On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
>> Hi Samuel,
>>
>> On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass <sjg@chromium.org> wrote:
>> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
>> > line is used to indicate when the EC needs service.
>> >
>> > Functions performed by the EC vary by platform, but typically include
>> > battery charging, keyboard scanning and power sequencing.
>> >
>> > This series includes support for the EC message protocol, and implements
>> > a matrix keyboard handler for Linux using the protocol. The EC performs
>> > key scanning and passes scan data in response to AP requests. This is
>> > used on the Samsung ARM Chromebook. No driver is available for LPC at
>> > present.
>> >
>> > This series can in principle operate on any hardware, but for it to actually
>> > work on the Samsung ARM Chromebook, it needs patches which are currently in
>> > progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
>> >
>> > The driver is device-tree-enabled and a suitable binding is included in
>> > this series. Example device tree nodes are included in the examples,
>> > but no device tree patch for exynos5250-snow is provided at this stage, since
>> > we must wait for the above-mentioned patches to land to avoid errors from
>> > dtc. This can be added with a follow-on patch when that work is complete.
>> >
>>
>> Are you happy with this series? Do you think it is ready to be picked
>> up for mfd?
> It probably is, and it will be part of the next merge window. I'll apply the
> after the merge window closes.
I'm just checking that we are still good to do this?
Regards,
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-02-25 22:08 [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
` (2 preceding siblings ...)
2013-02-27 5:13 ` [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
@ 2013-03-20 0:56 ` Samuel Ortiz
2013-03-20 1:12 ` Samuel Ortiz
3 siblings, 1 reply; 14+ messages in thread
From: Samuel Ortiz @ 2013-03-20 0:56 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input, Sourav Poddar, devicetree-discuss, Alban Bedel,
Roland Stigge, Vincent Palatin, Javier Martinez Canillas,
Mark Brown, linux-doc, Dmitry Torokhov, Tony Lindgren,
Bill Pemberton
Hi Simon,
On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> line is used to indicate when the EC needs service.
All 6 patches applied to my mfd-next tree, thanks a lot.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-03-20 0:56 ` Samuel Ortiz
@ 2013-03-20 1:12 ` Samuel Ortiz
2013-03-20 2:01 ` Simon Glass
0 siblings, 1 reply; 14+ messages in thread
From: Samuel Ortiz @ 2013-03-20 1:12 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input, Sourav Poddar, devicetree-discuss, Alban Bedel,
Roland Stigge, Vincent Palatin, Javier Martinez Canillas,
Mark Brown, linux-doc, Dmitry Torokhov, Tony Lindgren,
Bill Pemberton
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
> Hi Simon,
>
> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> > line is used to indicate when the EC needs service.
> All 6 patches applied to my mfd-next tree, thanks a lot.
Actually, this one fails to build when CONFIG_OF is not set:
drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
‘of_device_is_available’ [-Werror=implicit-function-declaration]
If the check in cros_ec_probe_i2c() is really needed then you'll need to inline
of_device_is_available() into a NOP in include/linux/of.h.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
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 [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-03-20 1:12 ` Samuel Ortiz
@ 2013-03-20 2:01 ` Simon Glass
2013-03-20 8:14 ` Samuel Ortiz
0 siblings, 1 reply; 14+ messages in thread
From: Simon Glass @ 2013-03-20 2:01 UTC (permalink / raw)
To: Samuel Ortiz
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input@vger.kernel.org, Sourav Poddar, Devicetree Discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc@vger.kernel.org,
Dmitry Torokhov, Tony Lindgren, Bill Pemberton
Hi Samuel,
On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
>> Hi Simon,
>>
>> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
>> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
>> > line is used to indicate when the EC needs service.
>> All 6 patches applied to my mfd-next tree, thanks a lot.
> Actually, this one fails to build when CONFIG_OF is not set:
>
> drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
> ‘of_device_is_available’ [-Werror=implicit-function-declaration]
>
> If the check in cros_ec_probe_i2c() is really needed then you'll need to inline
> of_device_is_available() into a NOP in include/linux/of.h.
Actually I suppose that call is not really needed. Would you like to
remove it, or shall I send a new patch?
Regards,
Simon
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
--
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 [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-03-20 2:01 ` Simon Glass
@ 2013-03-20 8:14 ` Samuel Ortiz
2013-03-20 8:52 ` Samuel Ortiz
0 siblings, 1 reply; 14+ messages in thread
From: Samuel Ortiz @ 2013-03-20 8:14 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input@vger.kernel.org, Sourav Poddar, Devicetree Discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc@vger.kernel.org,
Dmitry Torokhov, Tony Lindgren, Bill Pemberton
Hi Simon,
On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote:
> Hi Samuel,
>
> On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> > On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
> >> Hi Simon,
> >>
> >> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> >> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> >> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> >> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> >> > line is used to indicate when the EC needs service.
> >> All 6 patches applied to my mfd-next tree, thanks a lot.
> > Actually, this one fails to build when CONFIG_OF is not set:
> >
> > drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
> > ‘of_device_is_available’ [-Werror=implicit-function-declaration]
> >
> > If the check in cros_ec_probe_i2c() is really needed then you'll need to inline
> > of_device_is_available() into a NOP in include/linux/of.h.
>
> Actually I suppose that call is not really needed. Would you like to
> remove it, or shall I send a new patch?
I will remove it.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-03-20 8:14 ` Samuel Ortiz
@ 2013-03-20 8:52 ` Samuel Ortiz
2013-03-21 1:40 ` Simon Glass
0 siblings, 1 reply; 14+ messages in thread
From: Samuel Ortiz @ 2013-03-20 8:52 UTC (permalink / raw)
To: Simon Glass
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input@vger.kernel.org, Sourav Poddar, Devicetree Discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc@vger.kernel.org,
Dmitry Torokhov, Tony Lindgren, Bill Pemberton
Hi Simon,
On Wed, Mar 20, 2013 at 09:14:56AM +0100, Samuel Ortiz wrote:
> On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote:
> > Hi Samuel,
> >
> > On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> > > On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
> > >> Hi Simon,
> > >>
> > >> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
> > >> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> > >> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
> > >> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
> > >> > line is used to indicate when the EC needs service.
> > >> All 6 patches applied to my mfd-next tree, thanks a lot.
> > > Actually, this one fails to build when CONFIG_OF is not set:
> > >
> > > drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
> > > ‘of_device_is_available’ [-Werror=implicit-function-declaration]
> > >
> > > If the check in cros_ec_probe_i2c() is really needed then you'll need to inline
> > > of_device_is_available() into a NOP in include/linux/of.h.
> >
> > Actually I suppose that call is not really needed. Would you like to
> > remove it, or shall I send a new patch?
> I will remove it.
This is fixed and pushed. I also fixed some warnings and another build failure
for the case when all of your code is modular.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
2013-03-20 8:52 ` Samuel Ortiz
@ 2013-03-21 1:40 ` Simon Glass
0 siblings, 0 replies; 14+ messages in thread
From: Simon Glass @ 2013-03-21 1:40 UTC (permalink / raw)
To: Samuel Ortiz
Cc: LKML, Rob Landley, Felipe Balbi, Grant Likely, Wolfram Sang,
Luigi Semenzato, Rob Herring, Che-Liang Chiou, Jonathan Kliegman,
linux-input@vger.kernel.org, Sourav Poddar, Devicetree Discuss,
Alban Bedel, Roland Stigge, Vincent Palatin,
Javier Martinez Canillas, Mark Brown, linux-doc@vger.kernel.org,
Dmitry Torokhov, Tony Lindgren, Bill Pemberton
Hi Samuel,
On Wed, Mar 20, 2013 at 1:52 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Hi Simon,
>
> On Wed, Mar 20, 2013 at 09:14:56AM +0100, Samuel Ortiz wrote:
>> On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote:
>> > Hi Samuel,
>> >
>> > On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
>> > > On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
>> > >> Hi Simon,
>> > >>
>> > >> On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
>> > >> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
>> > >> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
>> > >> > connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
>> > >> > line is used to indicate when the EC needs service.
>> > >> All 6 patches applied to my mfd-next tree, thanks a lot.
>> > > Actually, this one fails to build when CONFIG_OF is not set:
>> > >
>> > > drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
>> > > ‘of_device_is_available’ [-Werror=implicit-function-declaration]
>> > >
>> > > If the check in cros_ec_probe_i2c() is really needed then you'll need to inline
>> > > of_device_is_available() into a NOP in include/linux/of.h.
>> >
>> > Actually I suppose that call is not really needed. Would you like to
>> > remove it, or shall I send a new patch?
>> I will remove it.
> This is fixed and pushed. I also fixed some warnings and another build failure
> for the case when all of your code is modular.
Thank you for that. I don't think I quite understood the different
build tests that I needed to do.
Regards,
Simon
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-03-21 1:40 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-25 22:08 [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
2013-02-25 22:08 ` [PATCH v6 5/6] Input: matrix-keymap: Add function to read the new DT binding Simon Glass
[not found] ` <1361830121-32284-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2013-02-25 22:08 ` [PATCH v6 6/6] Input: Add ChromeOS EC keyboard driver Simon Glass
2013-02-25 22:12 ` Dmitry Torokhov
2013-02-27 5:13 ` [PATCH v6 0/6] Add ChromeOS Embedded Controller support Simon Glass
2013-02-27 8:40 ` Samuel Ortiz
2013-02-28 0:25 ` Simon Glass
2013-03-18 18:41 ` Simon Glass
2013-03-20 0:56 ` Samuel Ortiz
2013-03-20 1:12 ` Samuel Ortiz
2013-03-20 2:01 ` Simon Glass
2013-03-20 8:14 ` Samuel Ortiz
2013-03-20 8:52 ` Samuel Ortiz
2013-03-21 1:40 ` Simon Glass
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).