This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
Google Pixel 2 (2015).
While newer version of ACPI standard allow use of device-tree-like
properties in device descriptions, the version of ACPI implemented in
Google BIOS does not support them, and we have to resort to DMI data to
specify exact characteristics of the devices (touchpad vs. touchscreen,
GPIO to button mapping, etc).
Pixel 1 continues to use i2c devices and platform data created by
chromeos-laptop driver, since ACPI does not enumerate them.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 149 +++++++++++++++++++++++++++----
1 file changed, 134 insertions(+), 15 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2875ddf..dfc7309 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -14,6 +14,8 @@
*
*/
+#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/completion.h>
@@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
{
struct input_dev *input = data->input_dev;
const struct mxt_platform_data *pdata = data->pdata;
- bool button;
int i;
- /* Active-low switch */
for (i = 0; i < pdata->t19_num_keys; i++) {
if (pdata->t19_keymap[i] == KEY_RESERVED)
continue;
- button = !(message[1] & (1 << i));
- input_report_key(input, pdata->t19_keymap[i], button);
+
+ /* Active-low switch */
+ input_report_key(input, pdata->t19_keymap[i],
+ !(message[1] & BIT(i)));
}
}
@@ -2371,7 +2373,7 @@ static void mxt_input_close(struct input_dev *dev)
}
#ifdef CONFIG_OF
-static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
+static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
struct mxt_platform_data *pdata;
u32 *keymap;
@@ -2379,7 +2381,7 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
int proplen, i, ret;
if (!client->dev.of_node)
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENOENT);
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -2410,25 +2412,132 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
return pdata;
}
#else
-static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
+static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
- dev_dbg(&client->dev, "No platform data specified\n");
- return ERR_PTR(-EINVAL);
+ return ERR_PTR(-ENOENT);
}
#endif
+#ifdef CONFIG_ACPI
+
+struct mxt_acpi_platform_data {
+ const char *hid;
+ struct mxt_platform_data pdata;
+};
+
+static unsigned int samus_touchpad_buttons[] = {
+ KEY_RESERVED,
+ KEY_RESERVED,
+ KEY_RESERVED,
+ BTN_LEFT
+};
+
+static struct mxt_acpi_platform_data samus_platform_data[] = {
+ {
+ /* Touchpad */
+ .hid = "ATML0000",
+ .pdata = {
+ .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
+ .t19_keymap = samus_touchpad_buttons,
+ },
+ },
+ {
+ /* Touchscreen */
+ .hid = "ATML0001",
+ },
+ { }
+};
+
+static const struct dmi_system_id mxt_dmi_table[] = {
+ {
+ /* 2015 Google Pixel */
+ .ident = "Chromebook Pixel 2",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Samus"),
+ },
+ .driver_data = samus_platform_data,
+ },
+ { }
+};
+
+static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
+{
+ struct acpi_device *adev;
+ const struct dmi_system_id *system_id;
+ const struct mxt_acpi_platform_data *acpi_pdata;
+
+ /*
+ * Ignore ACPI devices representing bootloader mode.
+ *
+ * This is a bit of a hack: Google Chromebook BIOS creates ACPI
+ * devices for both application and bootloader modes, but we are
+ * interested in application mode only (if device is in bootloader
+ * mode we'll end up switching into application anyway). So far
+ * application mode addresses were all above 0x40, so we'll use it
+ * as a threshold.
+ */
+ if (client->addr < 0x40)
+ return ERR_PTR(-ENXIO);
+
+ adev = ACPI_COMPANION(&client->dev);
+ if (!adev)
+ return ERR_PTR(-ENOENT);
+
+ system_id = dmi_first_match(mxt_dmi_table);
+ if (!system_id)
+ return ERR_PTR(-ENOENT);
+
+ acpi_pdata = system_id->driver_data;
+ if (!acpi_pdata)
+ return ERR_PTR(-ENOENT);
+
+ while (acpi_pdata->hid) {
+ if (!strcmp(acpi_device_hid(adev), acpi_pdata->hid))
+ return &acpi_pdata->pdata;
+
+ acpi_pdata++;
+ }
+
+ return ERR_PTR(-ENOENT);
+}
+#else
+static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
+{
+ return ERR_PTR(-ENOENT);
+}
+#endif
+
+static const struct mxt_platform_data *
+mxt_get_platform_data(struct i2c_client *client)
+{
+ const struct mxt_platform_data *pdata;
+
+ pdata = dev_get_platdata(&client->dev);
+ if (pdata)
+ return pdata;
+
+ pdata = mxt_parse_dt(client);
+ if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
+ return pdata;
+
+ pdata = mxt_parse_acpi(client);
+ if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
+ return pdata;
+
+ dev_err(&client->dev, "No platform data specified\n");
+ return ERR_PTR(-EINVAL);
+}
+
static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct mxt_data *data;
const struct mxt_platform_data *pdata;
int error;
- pdata = dev_get_platdata(&client->dev);
- if (!pdata) {
- pdata = mxt_parse_dt(client);
- if (IS_ERR(pdata))
- return PTR_ERR(pdata);
- }
+ pdata = mxt_get_platform_data(client);
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
data = kzalloc(sizeof(struct mxt_data), GFP_KERNEL);
if (!data) {
@@ -2536,6 +2645,15 @@ static const struct of_device_id mxt_of_match[] = {
};
MODULE_DEVICE_TABLE(of, mxt_of_match);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id mxt_acpi_id[] = {
+ { "ATML0000", 0 }, /* Touchpad */
+ { "ATML0001", 0 }, /* Touchscreen */
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, mxt_acpi_id);
+#endif
+
static const struct i2c_device_id mxt_id[] = {
{ "qt602240_ts", 0 },
{ "atmel_mxt_ts", 0 },
@@ -2550,6 +2668,7 @@ static struct i2c_driver mxt_driver = {
.name = "atmel_mxt_ts",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(mxt_of_match),
+ .acpi_match_table = ACPI_PTR(mxt_acpi_id),
.pm = &mxt_pm_ops,
},
.probe = mxt_probe,
--
2.2.0.rc0.207.ga3a616c
Atmel controolers are very flexible and to function optimally require
device-specific configuration to be loaded. While the configuration is
stored in NVRAM and is normally persistent, sometimes it gets corrupted
and needs to be reloaded.
Instead of using the same name, maxtouch.cfg, for all systems and all
devices, let's allow platform data to specify the name of configuration
file that should be loaded. This is especially useful for systems that
use Atmel controllers for both touchscren and touchpad, since their
configurations will surely differ.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
.../devicetree/bindings/input/atmel,maxtouch.txt | 6 ++++++
drivers/input/touchscreen/atmel_mxt_ts.c | 18 +++++++++++++-----
include/linux/i2c/atmel_mxt_ts.h | 1 +
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index 1852906..fd2344d 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -9,6 +9,12 @@ Required properties:
- interrupts: The sink for the touchpad's IRQ output
See ../interrupt-controller/interrupts.txt
+Optional properties:
+
+- linux,config-name: name of configuration file that should be loaded
+ into device for optimal functioning. If not specified "maxtouch.cfg"
+ will be used.
+
Optional properties for main touchpad device:
- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index dfc7309..0dcd455 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2035,7 +2035,8 @@ static int mxt_initialize(struct mxt_data *data)
if (error)
goto err_free_object_table;
- error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
+ error = request_firmware_nowait(THIS_MODULE, true,
+ data->pdata->cfg_name ?: MXT_CFG_NAME,
&client->dev, GFP_KERNEL, data,
mxt_config_cb);
if (error) {
@@ -2375,20 +2376,21 @@ static void mxt_input_close(struct input_dev *dev)
#ifdef CONFIG_OF
static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
{
+ struct device_node *np;
struct mxt_platform_data *pdata;
u32 *keymap;
u32 keycode;
int proplen, i, ret;
- if (!client->dev.of_node)
+ np = client->dev.of_node;
+ if (!np)
return ERR_PTR(-ENOENT);
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return ERR_PTR(-ENOMEM);
- if (of_find_property(client->dev.of_node, "linux,gpio-keymap",
- &proplen)) {
+ if (of_find_property(np, "linux,gpio-keymap", &proplen)) {
pdata->t19_num_keys = proplen / sizeof(u32);
keymap = devm_kzalloc(&client->dev,
@@ -2398,7 +2400,7 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
return ERR_PTR(-ENOMEM);
for (i = 0; i < pdata->t19_num_keys; i++) {
- ret = of_property_read_u32_index(client->dev.of_node,
+ ret = of_property_read_u32_index(np,
"linux,gpio-keymap", i, &keycode);
if (ret)
keycode = KEY_RESERVED;
@@ -2409,6 +2411,8 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
pdata->t19_keymap = keymap;
}
+ of_property_read_string(np, "linux,config-name", &pdata->cfg_name);
+
return pdata;
}
#else
@@ -2439,11 +2443,15 @@ static struct mxt_acpi_platform_data samus_platform_data[] = {
.pdata = {
.t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
.t19_keymap = samus_touchpad_buttons,
+ .cfg_name = "samus-337t.raw",
},
},
{
/* Touchscreen */
.hid = "ATML0001",
+ .pdata = {
+ .cfg_name = "samus-2954t2.raw",
+ },
},
{ }
};
diff --git a/include/linux/i2c/atmel_mxt_ts.h b/include/linux/i2c/atmel_mxt_ts.h
index 02bf6ea..aeb8c9a 100644
--- a/include/linux/i2c/atmel_mxt_ts.h
+++ b/include/linux/i2c/atmel_mxt_ts.h
@@ -20,6 +20,7 @@ struct mxt_platform_data {
unsigned long irqflags;
u8 t19_num_keys;
const unsigned int *t19_keymap;
+ const char *cfg_name;
};
#endif /* __LINUX_ATMEL_MXT_TS_H */
--
2.2.0.rc0.207.ga3a616c
Hi Dmitry-
This is similar to something that I've already got in my tree:
https://github.com/ndyer/linux/commit/449643df3c80
https://github.com/ndyer/linux/commit/a520bbbfbdd1
However, my version is based on the earlier Pixel code and allows updating
the config at any point in time by writing to the sysfs node, not just at
probe time, so it's a little more complex.
Would you like me to test this along with the T100 changes you just merged?
On 08/04/15 01:26, Dmitry Torokhov wrote:
> Atmel controolers are very flexible and to function optimally require
s/trool/troll/ :)
> device-specific configuration to be loaded. While the configuration is
> stored in NVRAM and is normally persistent, sometimes it gets corrupted
> and needs to be reloaded.
>
> Instead of using the same name, maxtouch.cfg, for all systems and all
> devices, let's allow platform data to specify the name of configuration
> file that should be loaded. This is especially useful for systems that
> use Atmel controllers for both touchscren and touchpad, since their
> configurations will surely differ.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
> ---
> .../devicetree/bindings/input/atmel,maxtouch.txt | 6 ++++++
> drivers/input/touchscreen/atmel_mxt_ts.c | 18 +++++++++++++-----
> include/linux/i2c/atmel_mxt_ts.h | 1 +
> 3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> index 1852906..fd2344d 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> @@ -9,6 +9,12 @@ Required properties:
> - interrupts: The sink for the touchpad's IRQ output
> See ../interrupt-controller/interrupts.txt
>
> +Optional properties:
> +
> +- linux,config-name: name of configuration file that should be loaded
> + into device for optimal functioning. If not specified "maxtouch.cfg"
> + will be used.
> +
> Optional properties for main touchpad device:
>
> - linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index dfc7309..0dcd455 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -2035,7 +2035,8 @@ static int mxt_initialize(struct mxt_data *data)
> if (error)
> goto err_free_object_table;
>
> - error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
> + error = request_firmware_nowait(THIS_MODULE, true,
> + data->pdata->cfg_name ?: MXT_CFG_NAME,
> &client->dev, GFP_KERNEL, data,
> mxt_config_cb);
> if (error) {
> @@ -2375,20 +2376,21 @@ static void mxt_input_close(struct input_dev *dev)
> #ifdef CONFIG_OF
> static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> {
> + struct device_node *np;
> struct mxt_platform_data *pdata;
> u32 *keymap;
> u32 keycode;
> int proplen, i, ret;
>
> - if (!client->dev.of_node)
> + np = client->dev.of_node;
> + if (!np)
> return ERR_PTR(-ENOENT);
>
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> return ERR_PTR(-ENOMEM);
>
> - if (of_find_property(client->dev.of_node, "linux,gpio-keymap",
> - &proplen)) {
> + if (of_find_property(np, "linux,gpio-keymap", &proplen)) {
> pdata->t19_num_keys = proplen / sizeof(u32);
>
> keymap = devm_kzalloc(&client->dev,
> @@ -2398,7 +2400,7 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> return ERR_PTR(-ENOMEM);
>
> for (i = 0; i < pdata->t19_num_keys; i++) {
> - ret = of_property_read_u32_index(client->dev.of_node,
> + ret = of_property_read_u32_index(np,
> "linux,gpio-keymap", i, &keycode);
> if (ret)
> keycode = KEY_RESERVED;
> @@ -2409,6 +2411,8 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> pdata->t19_keymap = keymap;
> }
>
> + of_property_read_string(np, "linux,config-name", &pdata->cfg_name);
> +
> return pdata;
> }
> #else
> @@ -2439,11 +2443,15 @@ static struct mxt_acpi_platform_data samus_platform_data[] = {
> .pdata = {
> .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> .t19_keymap = samus_touchpad_buttons,
> + .cfg_name = "samus-337t.raw",
> },
> },
> {
> /* Touchscreen */
> .hid = "ATML0001",
> + .pdata = {
> + .cfg_name = "samus-2954t2.raw",
> + },
> },
> { }
> };
> diff --git a/include/linux/i2c/atmel_mxt_ts.h b/include/linux/i2c/atmel_mxt_ts.h
> index 02bf6ea..aeb8c9a 100644
> --- a/include/linux/i2c/atmel_mxt_ts.h
> +++ b/include/linux/i2c/atmel_mxt_ts.h
> @@ -20,6 +20,7 @@ struct mxt_platform_data {
> unsigned long irqflags;
> u8 t19_num_keys;
> const unsigned int *t19_keymap;
> + const char *cfg_name;
> };
>
> #endif /* __LINUX_ATMEL_MXT_TS_H */
>
On 08/04/15 01:26, Dmitry Torokhov wrote:
> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
> Google Pixel 2 (2015).
Can you point me to any instructions for testing this on the Pixel 2 we
have here?
> While newer version of ACPI standard allow use of device-tree-like
> properties in device descriptions, the version of ACPI implemented in
> Google BIOS does not support them, and we have to resort to DMI data to
> specify exact characteristics of the devices (touchpad vs. touchscreen,
> GPIO to button mapping, etc).
>
> Pixel 1 continues to use i2c devices and platform data created by
> chromeos-laptop driver, since ACPI does not enumerate them.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 149 +++++++++++++++++++++++++++----
> 1 file changed, 134 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 2875ddf..dfc7309 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -14,6 +14,8 @@
> *
> */
>
> +#include <linux/acpi.h>
> +#include <linux/dmi.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/completion.h>
> @@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> {
> struct input_dev *input = data->input_dev;
> const struct mxt_platform_data *pdata = data->pdata;
> - bool button;
> int i;
>
> - /* Active-low switch */
> for (i = 0; i < pdata->t19_num_keys; i++) {
> if (pdata->t19_keymap[i] == KEY_RESERVED)
> continue;
> - button = !(message[1] & (1 << i));
> - input_report_key(input, pdata->t19_keymap[i], button);
> +
> + /* Active-low switch */
> + input_report_key(input, pdata->t19_keymap[i],
> + !(message[1] & BIT(i)));
> }
> }
>
> @@ -2371,7 +2373,7 @@ static void mxt_input_close(struct input_dev *dev)
> }
>
> #ifdef CONFIG_OF
> -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> {
> struct mxt_platform_data *pdata;
> u32 *keymap;
> @@ -2379,7 +2381,7 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> int proplen, i, ret;
>
> if (!client->dev.of_node)
> - return ERR_PTR(-ENODEV);
> + return ERR_PTR(-ENOENT);
>
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> @@ -2410,25 +2412,132 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> return pdata;
> }
> #else
> -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> {
> - dev_dbg(&client->dev, "No platform data specified\n");
> - return ERR_PTR(-EINVAL);
> + return ERR_PTR(-ENOENT);
> }
> #endif
>
> +#ifdef CONFIG_ACPI
> +
> +struct mxt_acpi_platform_data {
> + const char *hid;
> + struct mxt_platform_data pdata;
> +};
> +
> +static unsigned int samus_touchpad_buttons[] = {
> + KEY_RESERVED,
> + KEY_RESERVED,
> + KEY_RESERVED,
> + BTN_LEFT
> +};
> +
> +static struct mxt_acpi_platform_data samus_platform_data[] = {
> + {
> + /* Touchpad */
> + .hid = "ATML0000",
> + .pdata = {
> + .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> + .t19_keymap = samus_touchpad_buttons,
> + },
> + },
> + {
> + /* Touchscreen */
> + .hid = "ATML0001",
> + },
> + { }
> +};
It seems a bit wrong to be putting this Pixel-specific platform data in the
driver file.
> +static const struct dmi_system_id mxt_dmi_table[] = {
> + {
> + /* 2015 Google Pixel */
> + .ident = "Chromebook Pixel 2",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Samus"),
> + },
> + .driver_data = samus_platform_data,
> + },
> + { }
> +};
> +
> +static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +{
> + struct acpi_device *adev;
> + const struct dmi_system_id *system_id;
> + const struct mxt_acpi_platform_data *acpi_pdata;
> +
> + /*
> + * Ignore ACPI devices representing bootloader mode.
> + *
> + * This is a bit of a hack: Google Chromebook BIOS creates ACPI
> + * devices for both application and bootloader modes, but we are
> + * interested in application mode only (if device is in bootloader
> + * mode we'll end up switching into application anyway). So far
> + * application mode addresses were all above 0x40, so we'll use it
> + * as a threshold.
> + */
> + if (client->addr < 0x40)
> + return ERR_PTR(-ENXIO);
> +
> + adev = ACPI_COMPANION(&client->dev);
> + if (!adev)
> + return ERR_PTR(-ENOENT);
> +
> + system_id = dmi_first_match(mxt_dmi_table);
> + if (!system_id)
> + return ERR_PTR(-ENOENT);
> +
> + acpi_pdata = system_id->driver_data;
> + if (!acpi_pdata)
> + return ERR_PTR(-ENOENT);
> +
> + while (acpi_pdata->hid) {
> + if (!strcmp(acpi_device_hid(adev), acpi_pdata->hid))
> + return &acpi_pdata->pdata;
> +
> + acpi_pdata++;
> + }
> +
> + return ERR_PTR(-ENOENT);
> +}
> +#else
> +static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> +#endif
> +
> +static const struct mxt_platform_data *
> +mxt_get_platform_data(struct i2c_client *client)
> +{
> + const struct mxt_platform_data *pdata;
> +
> + pdata = dev_get_platdata(&client->dev);
> + if (pdata)
> + return pdata;
> +
> + pdata = mxt_parse_dt(client);
> + if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> + return pdata;
> +
> + pdata = mxt_parse_acpi(client);
> + if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> + return pdata;
> +
> + dev_err(&client->dev, "No platform data specified\n");
> + return ERR_PTR(-EINVAL);
> +}
> +
> static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> struct mxt_data *data;
> const struct mxt_platform_data *pdata;
> int error;
>
> - pdata = dev_get_platdata(&client->dev);
> - if (!pdata) {
> - pdata = mxt_parse_dt(client);
> - if (IS_ERR(pdata))
> - return PTR_ERR(pdata);
> - }
> + pdata = mxt_get_platform_data(client);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
>
> data = kzalloc(sizeof(struct mxt_data), GFP_KERNEL);
> if (!data) {
> @@ -2536,6 +2645,15 @@ static const struct of_device_id mxt_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, mxt_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id mxt_acpi_id[] = {
> + { "ATML0000", 0 }, /* Touchpad */
> + { "ATML0001", 0 }, /* Touchscreen */
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, mxt_acpi_id);
> +#endif
> +
> static const struct i2c_device_id mxt_id[] = {
> { "qt602240_ts", 0 },
> { "atmel_mxt_ts", 0 },
> @@ -2550,6 +2668,7 @@ static struct i2c_driver mxt_driver = {
> .name = "atmel_mxt_ts",
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(mxt_of_match),
> + .acpi_match_table = ACPI_PTR(mxt_acpi_id),
> .pm = &mxt_pm_ops,
> },
> .probe = mxt_probe,
>
Hi Nick,
On Thu, Apr 09, 2015 at 12:08:44PM +0100, Nick Dyer wrote:
> On 08/04/15 01:26, Dmitry Torokhov wrote:
> > This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
> > Google Pixel 2 (2015).
>
> Can you point me to any instructions for testing this on the Pixel 2 we
> have here?
I just installed Fedora 21, updated fully, and rebuild 4.0+ kernel with
their default config file.
To install Fedora switch the unit into developer mode, then, in Chrome
OS do "sudo crossystem dev_boot_legacy=1"), reboot, and after hitting
"Ctrl-L" early in teh boot sequence it should offer you to boot form USB
stick (that you dd'ed Fedora's Live ISO image - x86_64 - onto) and you
can install from there.
>
> > While newer version of ACPI standard allow use of device-tree-like
> > properties in device descriptions, the version of ACPI implemented in
> > Google BIOS does not support them, and we have to resort to DMI data to
> > specify exact characteristics of the devices (touchpad vs. touchscreen,
> > GPIO to button mapping, etc).
> >
> > Pixel 1 continues to use i2c devices and platform data created by
> > chromeos-laptop driver, since ACPI does not enumerate them.
> >
> > Signed-off-by: Dmitry Torokhov <[email protected]>
> > ---
> > drivers/input/touchscreen/atmel_mxt_ts.c | 149 +++++++++++++++++++++++++++----
> > 1 file changed, 134 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index 2875ddf..dfc7309 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -14,6 +14,8 @@
> > *
> > */
> >
> > +#include <linux/acpi.h>
> > +#include <linux/dmi.h>
> > #include <linux/module.h>
> > #include <linux/init.h>
> > #include <linux/completion.h>
> > @@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> > {
> > struct input_dev *input = data->input_dev;
> > const struct mxt_platform_data *pdata = data->pdata;
> > - bool button;
> > int i;
> >
> > - /* Active-low switch */
> > for (i = 0; i < pdata->t19_num_keys; i++) {
> > if (pdata->t19_keymap[i] == KEY_RESERVED)
> > continue;
> > - button = !(message[1] & (1 << i));
> > - input_report_key(input, pdata->t19_keymap[i], button);
> > +
> > + /* Active-low switch */
> > + input_report_key(input, pdata->t19_keymap[i],
> > + !(message[1] & BIT(i)));
> > }
> > }
> >
> > @@ -2371,7 +2373,7 @@ static void mxt_input_close(struct input_dev *dev)
> > }
> >
> > #ifdef CONFIG_OF
> > -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > {
> > struct mxt_platform_data *pdata;
> > u32 *keymap;
> > @@ -2379,7 +2381,7 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > int proplen, i, ret;
> >
> > if (!client->dev.of_node)
> > - return ERR_PTR(-ENODEV);
> > + return ERR_PTR(-ENOENT);
> >
> > pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > if (!pdata)
> > @@ -2410,25 +2412,132 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > return pdata;
> > }
> > #else
> > -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > {
> > - dev_dbg(&client->dev, "No platform data specified\n");
> > - return ERR_PTR(-EINVAL);
> > + return ERR_PTR(-ENOENT);
> > }
> > #endif
> >
> > +#ifdef CONFIG_ACPI
> > +
> > +struct mxt_acpi_platform_data {
> > + const char *hid;
> > + struct mxt_platform_data pdata;
> > +};
> > +
> > +static unsigned int samus_touchpad_buttons[] = {
> > + KEY_RESERVED,
> > + KEY_RESERVED,
> > + KEY_RESERVED,
> > + BTN_LEFT
> > +};
> > +
> > +static struct mxt_acpi_platform_data samus_platform_data[] = {
> > + {
> > + /* Touchpad */
> > + .hid = "ATML0000",
> > + .pdata = {
> > + .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> > + .t19_keymap = samus_touchpad_buttons,
> > + },
> > + },
> > + {
> > + /* Touchscreen */
> > + .hid = "ATML0001",
> > + },
> > + { }
> > +};
>
> It seems a bit wrong to be putting this Pixel-specific platform data in the
> driver file.
Yes, I would love to avoid it, but it int not that we do not have
precedent. We are forced to use a lot of quirks in atkbd.c, synaptics.c
and host of other drivers to account for system quirks. In this
particular case I considered hacking chromeos-laptop to try to provide
platform data, but it is impossible to do cleanly, without leakig memory
all over :( This is because the devices are described in ACPI and so
i2c-core instantiated them for us; but there are no additional data in
ACPI similar to platform data, and ACPI HIDs are shared between all x86
Chromebooks produced so far. If/when we make new x86 ChromeOS
device with Atmel hardware we will make sure to use newer version of
ACPI allowing specifying arbitrary device properties, similar to DT.
Thanks.
--
Dmitry
Hi Nick,
On Thu, Apr 09, 2015 at 12:03:14PM +0100, Nick Dyer wrote:
> Hi Dmitry-
>
> This is similar to something that I've already got in my tree:
>
> https://github.com/ndyer/linux/commit/449643df3c80
> https://github.com/ndyer/linux/commit/a520bbbfbdd1
>
> However, my version is based on the earlier Pixel code and allows updating
> the config at any point in time by writing to the sysfs node, not just at
> probe time, so it's a little more complex.
Yes, it is indeed a bit more complex and I am not sure we actually want
it. We are trying to move away from userspace-controllable
config/firmware names in ChromeOS - we produce images tailored for
particular device anyways, and we only need to differentiate between
touchpad and touchscreen on a device, so static (but different) config
names will work fine.
So for now I'd prefer merging this version and then possibly enhancing
it in the future.
The only question is: your binding scheme specifies "atmel,cfg_name"
whereas I think it reflects Linux driver behavior, not general hardware
property, so I think "linux," is better prefix for that, although I am
open to discuss this.
>
> Would you like me to test this along with the T100 changes you just merged?
That would be great.
>
> On 08/04/15 01:26, Dmitry Torokhov wrote:
> > Atmel controolers are very flexible and to function optimally require
>
> s/trool/troll/ :)
:) Thanks.
By the way, is is possible to check if device contains valid
configuration? Would config_crc be 0 if config stored in devices memory
was corrupted/damaged somehow? I wonder if we could avoid always
requesting config if device has some configuration (bit not necessarily
latest and greatest) already loaded.
>
> > device-specific configuration to be loaded. While the configuration is
> > stored in NVRAM and is normally persistent, sometimes it gets corrupted
> > and needs to be reloaded.
> >
> > Instead of using the same name, maxtouch.cfg, for all systems and all
> > devices, let's allow platform data to specify the name of configuration
> > file that should be loaded. This is especially useful for systems that
> > use Atmel controllers for both touchscren and touchpad, since their
> > configurations will surely differ.
> >
> > Signed-off-by: Dmitry Torokhov <[email protected]>
> > ---
> > .../devicetree/bindings/input/atmel,maxtouch.txt | 6 ++++++
> > drivers/input/touchscreen/atmel_mxt_ts.c | 18 +++++++++++++-----
> > include/linux/i2c/atmel_mxt_ts.h | 1 +
> > 3 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> > index 1852906..fd2344d 100644
> > --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> > +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> > @@ -9,6 +9,12 @@ Required properties:
> > - interrupts: The sink for the touchpad's IRQ output
> > See ../interrupt-controller/interrupts.txt
> >
> > +Optional properties:
> > +
> > +- linux,config-name: name of configuration file that should be loaded
> > + into device for optimal functioning. If not specified "maxtouch.cfg"
> > + will be used.
> > +
> > Optional properties for main touchpad device:
> >
> > - linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index dfc7309..0dcd455 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -2035,7 +2035,8 @@ static int mxt_initialize(struct mxt_data *data)
> > if (error)
> > goto err_free_object_table;
> >
> > - error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
> > + error = request_firmware_nowait(THIS_MODULE, true,
> > + data->pdata->cfg_name ?: MXT_CFG_NAME,
> > &client->dev, GFP_KERNEL, data,
> > mxt_config_cb);
> > if (error) {
> > @@ -2375,20 +2376,21 @@ static void mxt_input_close(struct input_dev *dev)
> > #ifdef CONFIG_OF
> > static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > {
> > + struct device_node *np;
> > struct mxt_platform_data *pdata;
> > u32 *keymap;
> > u32 keycode;
> > int proplen, i, ret;
> >
> > - if (!client->dev.of_node)
> > + np = client->dev.of_node;
> > + if (!np)
> > return ERR_PTR(-ENOENT);
> >
> > pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > if (!pdata)
> > return ERR_PTR(-ENOMEM);
> >
> > - if (of_find_property(client->dev.of_node, "linux,gpio-keymap",
> > - &proplen)) {
> > + if (of_find_property(np, "linux,gpio-keymap", &proplen)) {
> > pdata->t19_num_keys = proplen / sizeof(u32);
> >
> > keymap = devm_kzalloc(&client->dev,
> > @@ -2398,7 +2400,7 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > return ERR_PTR(-ENOMEM);
> >
> > for (i = 0; i < pdata->t19_num_keys; i++) {
> > - ret = of_property_read_u32_index(client->dev.of_node,
> > + ret = of_property_read_u32_index(np,
> > "linux,gpio-keymap", i, &keycode);
> > if (ret)
> > keycode = KEY_RESERVED;
> > @@ -2409,6 +2411,8 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> > pdata->t19_keymap = keymap;
> > }
> >
> > + of_property_read_string(np, "linux,config-name", &pdata->cfg_name);
> > +
> > return pdata;
> > }
> > #else
> > @@ -2439,11 +2443,15 @@ static struct mxt_acpi_platform_data samus_platform_data[] = {
> > .pdata = {
> > .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> > .t19_keymap = samus_touchpad_buttons,
> > + .cfg_name = "samus-337t.raw",
> > },
> > },
> > {
> > /* Touchscreen */
> > .hid = "ATML0001",
> > + .pdata = {
> > + .cfg_name = "samus-2954t2.raw",
> > + },
> > },
> > { }
> > };
> > diff --git a/include/linux/i2c/atmel_mxt_ts.h b/include/linux/i2c/atmel_mxt_ts.h
> > index 02bf6ea..aeb8c9a 100644
> > --- a/include/linux/i2c/atmel_mxt_ts.h
> > +++ b/include/linux/i2c/atmel_mxt_ts.h
> > @@ -20,6 +20,7 @@ struct mxt_platform_data {
> > unsigned long irqflags;
> > u8 t19_num_keys;
> > const unsigned int *t19_keymap;
> > + const char *cfg_name;
> > };
> >
> > #endif /* __LINUX_ATMEL_MXT_TS_H */
> >
Thanks.
--
Dmitry
Hello Dmitry,
On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
> Google Pixel 2 (2015).
>
> While newer version of ACPI standard allow use of device-tree-like
> properties in device descriptions, the version of ACPI implemented in
> Google BIOS does not support them, and we have to resort to DMI data to
> specify exact characteristics of the devices (touchpad vs. touchscreen,
> GPIO to button mapping, etc).
>
> Pixel 1 continues to use i2c devices and platform data created by
> chromeos-laptop driver, since ACPI does not enumerate them.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 149 +++++++++++++++++++++++++++----
> 1 file changed, 134 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 2875ddf..dfc7309 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -14,6 +14,8 @@
> *
> */
>
> +#include <linux/acpi.h>
> +#include <linux/dmi.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/completion.h>
> @@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> {
> struct input_dev *input = data->input_dev;
> const struct mxt_platform_data *pdata = data->pdata;
> - bool button;
> int i;
>
> - /* Active-low switch */
> for (i = 0; i < pdata->t19_num_keys; i++) {
> if (pdata->t19_keymap[i] == KEY_RESERVED)
> continue;
> - button = !(message[1] & (1 << i));
> - input_report_key(input, pdata->t19_keymap[i], button);
> +
> + /* Active-low switch */
> + input_report_key(input, pdata->t19_keymap[i],
> + !(message[1] & BIT(i)));
This is an unrelated cleanup so probably should had been a separate patch?
> }
> }
>
> @@ -2371,7 +2373,7 @@ static void mxt_input_close(struct input_dev *dev)
> }
>
> #ifdef CONFIG_OF
> -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> {
> struct mxt_platform_data *pdata;
> u32 *keymap;
> @@ -2379,7 +2381,7 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> int proplen, i, ret;
>
> if (!client->dev.of_node)
> - return ERR_PTR(-ENODEV);
> + return ERR_PTR(-ENOENT);
>
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> @@ -2410,25 +2412,132 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> return pdata;
> }
> #else
> -static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> +static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client)
> {
> - dev_dbg(&client->dev, "No platform data specified\n");
> - return ERR_PTR(-EINVAL);
> + return ERR_PTR(-ENOENT);
> }
> #endif
>
> +#ifdef CONFIG_ACPI
> +
> +struct mxt_acpi_platform_data {
> + const char *hid;
> + struct mxt_platform_data pdata;
> +};
> +
> +static unsigned int samus_touchpad_buttons[] = {
> + KEY_RESERVED,
> + KEY_RESERVED,
> + KEY_RESERVED,
> + BTN_LEFT
> +};
> +
> +static struct mxt_acpi_platform_data samus_platform_data[] = {
> + {
> + /* Touchpad */
> + .hid = "ATML0000",
> + .pdata = {
> + .t19_num_keys = ARRAY_SIZE(samus_touchpad_buttons),
> + .t19_keymap = samus_touchpad_buttons,
> + },
> + },
> + {
> + /* Touchscreen */
> + .hid = "ATML0001",
> + },
> + { }
> +};
> +
> +static const struct dmi_system_id mxt_dmi_table[] = {
> + {
> + /* 2015 Google Pixel */
> + .ident = "Chromebook Pixel 2",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Samus"),
> + },
> + .driver_data = samus_platform_data,
> + },
> + { }
> +};
> +
> +static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +{
> + struct acpi_device *adev;
> + const struct dmi_system_id *system_id;
> + const struct mxt_acpi_platform_data *acpi_pdata;
> +
> + /*
> + * Ignore ACPI devices representing bootloader mode.
> + *
> + * This is a bit of a hack: Google Chromebook BIOS creates ACPI
> + * devices for both application and bootloader modes, but we are
> + * interested in application mode only (if device is in bootloader
> + * mode we'll end up switching into application anyway). So far
> + * application mode addresses were all above 0x40, so we'll use it
> + * as a threshold.
> + */
> + if (client->addr < 0x40)
> + return ERR_PTR(-ENXIO);
> +
> + adev = ACPI_COMPANION(&client->dev);
> + if (!adev)
> + return ERR_PTR(-ENOENT);
> +
> + system_id = dmi_first_match(mxt_dmi_table);
> + if (!system_id)
> + return ERR_PTR(-ENOENT);
> +
> + acpi_pdata = system_id->driver_data;
> + if (!acpi_pdata)
> + return ERR_PTR(-ENOENT);
> +
> + while (acpi_pdata->hid) {
> + if (!strcmp(acpi_device_hid(adev), acpi_pdata->hid))
> + return &acpi_pdata->pdata;
> +
> + acpi_pdata++;
> + }
> +
> + return ERR_PTR(-ENOENT);
> +}
> +#else
> +static const struct mxt_platform_data *mxt_parse_acpi(struct i2c_client *client)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> +#endif
> +
> +static const struct mxt_platform_data *
> +mxt_get_platform_data(struct i2c_client *client)
> +{
> + const struct mxt_platform_data *pdata;
> +
> + pdata = dev_get_platdata(&client->dev);
> + if (pdata)
> + return pdata;
> +
> + pdata = mxt_parse_dt(client);
> + if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> + return pdata;
> +
> + pdata = mxt_parse_acpi(client);
> + if (!IS_ERR(pdata) || PTR_ERR(pdata) != -ENOENT)
> + return pdata;
> +
> + dev_err(&client->dev, "No platform data specified\n");
> + return ERR_PTR(-EINVAL);
> +}
> +
> static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> struct mxt_data *data;
> const struct mxt_platform_data *pdata;
> int error;
>
> - pdata = dev_get_platdata(&client->dev);
> - if (!pdata) {
> - pdata = mxt_parse_dt(client);
> - if (IS_ERR(pdata))
> - return PTR_ERR(pdata);
> - }
> + pdata = mxt_get_platform_data(client);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
>
> data = kzalloc(sizeof(struct mxt_data), GFP_KERNEL);
> if (!data) {
> @@ -2536,6 +2645,15 @@ static const struct of_device_id mxt_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, mxt_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id mxt_acpi_id[] = {
> + { "ATML0000", 0 }, /* Touchpad */
> + { "ATML0001", 0 }, /* Touchscreen */
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, mxt_acpi_id);
> +#endif
> +
> static const struct i2c_device_id mxt_id[] = {
> { "qt602240_ts", 0 },
> { "atmel_mxt_ts", 0 },
> @@ -2550,6 +2668,7 @@ static struct i2c_driver mxt_driver = {
> .name = "atmel_mxt_ts",
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(mxt_of_match),
> + .acpi_match_table = ACPI_PTR(mxt_acpi_id),
> .pm = &mxt_pm_ops,
> },
> .probe = mxt_probe,
>
Patch looks good to me and I've tested it in a Pixel2 Chromebook using
evtest:
Reviewed-by: Javier Martinez Canillas <[email protected]>
Tested-by: Javier Martinez Canillas <[email protected]>
Best regards,
Javier
Hello Dmitry,
On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
> Atmel controolers are very flexible and to function optimally require
> device-specific configuration to be loaded. While the configuration is
> stored in NVRAM and is normally persistent, sometimes it gets corrupted
> and needs to be reloaded.
>
> Instead of using the same name, maxtouch.cfg, for all systems and all
> devices, let's allow platform data to specify the name of configuration
> file that should be loaded. This is especially useful for systems that
> use Atmel controllers for both touchscren and touchpad, since their
> configurations will surely differ.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Tested-by: Javier Martinez Canillas <[email protected]>
Best regards,
Javier
On Wed, Apr 15, 2015 at 05:58:04PM +0200, Javier Martinez Canillas wrote:
> On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
> > @@ -724,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> > {
> > struct input_dev *input = data->input_dev;
> > const struct mxt_platform_data *pdata = data->pdata;
> > - bool button;
> > int i;
> >
> > - /* Active-low switch */
> > for (i = 0; i < pdata->t19_num_keys; i++) {
> > if (pdata->t19_keymap[i] == KEY_RESERVED)
> > continue;
> > - button = !(message[1] & (1 << i));
> > - input_report_key(input, pdata->t19_keymap[i], button);
> > +
> > + /* Active-low switch */
> > + input_report_key(input, pdata->t19_keymap[i],
> > + !(message[1] & BIT(i)));
>
> This is an unrelated cleanup so probably should had been a separate patch?
Fair enough.
--
Dmitry
Input: atmel_mxt_ts - use BIT() macro when reporting button state
From: Dmitry Torokhov <[email protected]>
This makes the intent a tad more clear.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 0d87ffc..0dcd455 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -726,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
{
struct input_dev *input = data->input_dev;
const struct mxt_platform_data *pdata = data->pdata;
- bool button;
int i;
- /* Active-low switch */
for (i = 0; i < pdata->t19_num_keys; i++) {
if (pdata->t19_keymap[i] == KEY_RESERVED)
continue;
- button = !(message[1] & (1 << i));
- input_report_key(input, pdata->t19_keymap[i], button);
+
+ /* Active-low switch */
+ input_report_key(input, pdata->t19_keymap[i],
+ !(message[1] & BIT(i)));
}
}
Hi guys,
On Wed, Apr 15, 2015 at 11:58 AM, Javier Martinez Canillas <[email protected]> wrote:
> Hello Dmitry,
>
> On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
>> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
>> Google Pixel 2 (2015).
>>
>> While newer version of ACPI standard allow use of device-tree-like
>> properties in device descriptions, the version of ACPI implemented in
>> Google BIOS does not support them, and we have to resort to DMI data to
>> specify exact characteristics of the devices (touchpad vs. touchscreen,
>> GPIO to button mapping, etc).
>>
>> Pixel 1 continues to use i2c devices and platform data created by
>> chromeos-laptop driver, since ACPI does not enumerate them.
>>
>> Signed-off-by: Dmitry Torokhov <[email protected]>
>> ---
[snipped]
>
> Patch looks good to me and I've tested it in a Pixel2 Chromebook using
> evtest:
>
> Reviewed-by: Javier Martinez Canillas <[email protected]>
> Tested-by: Javier Martinez Canillas <[email protected]>
>
Hmm, this is weird. I tried to apply the 2 patches of this series to a
4.0 fedora kernel[1], and the touch{pad|screen} are desperately muted.
The abs_X/Y max shows up as 0, so there is something wrong with either
my touchpad (which works fine on ChromeOS) or with the driver.
There are no differences between 4.0-rcX and the final 4.0 so I suspect
there must be something else.
I also copied the 2 samus-* config files from the ChromeOS root to
/lib/firmware but this does not change anything.
In [3], I enabled the debug output of atmel_mxt, and it seems that the
table of functions is missing the T9 one, which is the multitouch one... :(
Any help would be greatly appreciated so we can fix [2] and support
those laptops in Fedora directly.
Cheers,
Benjamin
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=9490910
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1209088
[3] dmesg output with debug:
[ 1988.789927] atmel_mxt_ts i2c-ATML0000:01: T37 Start:202 Size:130 Instances:1 Report IDs:0-0
[ 1988.789937] atmel_mxt_ts i2c-ATML0000:01: T44 Start:332 Size:1 Instances:1 Report IDs:0-0
[ 1988.789943] atmel_mxt_ts i2c-ATML0000:01: T5 Start:333 Size:11 Instances:1 Report IDs:0-0
[ 1988.789947] atmel_mxt_ts i2c-ATML0000:01: T6 Start:344 Size:7 Instances:1 Report IDs:1-1
[ 1988.789952] atmel_mxt_ts i2c-ATML0000:01: T38 Start:351 Size:64 Instances:1 Report IDs:0-0
[ 1988.789956] atmel_mxt_ts i2c-ATML0000:01: T71 Start:415 Size:200 Instances:1 Report IDs:0-0
[ 1988.789961] atmel_mxt_ts i2c-ATML0000:01: T110 Start:615 Size:28 Instances:9 Report IDs:0-0
[ 1988.789965] atmel_mxt_ts i2c-ATML0000:01: T7 Start:867 Size:5 Instances:1 Report IDs:0-0
[ 1988.789969] atmel_mxt_ts i2c-ATML0000:01: T8 Start:872 Size:15 Instances:1 Report IDs:0-0
[ 1988.789973] atmel_mxt_ts i2c-ATML0000:01: T15 Start:887 Size:11 Instances:1 Report IDs:2-2
[ 1988.789978] atmel_mxt_ts i2c-ATML0000:01: T18 Start:898 Size:2 Instances:1 Report IDs:0-0
[ 1988.789982] atmel_mxt_ts i2c-ATML0000:01: T19 Start:900 Size:6 Instances:1 Report IDs:3-3
[ 1988.789986] atmel_mxt_ts i2c-ATML0000:01: T25 Start:906 Size:15 Instances:1 Report IDs:4-4
[ 1988.789991] atmel_mxt_ts i2c-ATML0000:01: T42 Start:921 Size:13 Instances:1 Report IDs:0-0
[ 1988.789995] atmel_mxt_ts i2c-ATML0000:01: T46 Start:934 Size:12 Instances:1 Report IDs:5-5
[ 1988.789999] atmel_mxt_ts i2c-ATML0000:01: T47 Start:946 Size:40 Instances:1 Report IDs:0-0
[ 1988.790004] atmel_mxt_ts i2c-ATML0000:01: T56 Start:986 Size:28 Instances:1 Report IDs:6-6
[ 1988.790009] atmel_mxt_ts i2c-ATML0000:01: T61 Start:1014 Size:5 Instances:6 Report IDs:7-12
[ 1988.790013] atmel_mxt_ts i2c-ATML0000:01: T65 Start:1044 Size:23 Instances:3 Report IDs:13-15
[ 1988.790018] atmel_mxt_ts i2c-ATML0000:01: T70 Start:1113 Size:10 Instances:20 Report IDs:16-35
[ 1988.790022] atmel_mxt_ts i2c-ATML0000:01: T72 Start:1313 Size:85 Instances:1 Report IDs:36-36
[ 1988.790027] atmel_mxt_ts i2c-ATML0000:01: T77 Start:1398 Size:2 Instances:1 Report IDs:0-0
[ 1988.790031] atmel_mxt_ts i2c-ATML0000:01: T78 Start:1400 Size:12 Instances:1 Report IDs:0-0
[ 1988.790035] atmel_mxt_ts i2c-ATML0000:01: T80 Start:1412 Size:11 Instances:1 Report IDs:37-37
[ 1988.790040] atmel_mxt_ts i2c-ATML0000:01: T100 Start:1423 Size:60 Instances:1 Report IDs:38-49
[ 1988.790044] atmel_mxt_ts i2c-ATML0000:01: T101 Start:1483 Size:30 Instances:1 Report IDs:0-0
[ 1988.790048] atmel_mxt_ts i2c-ATML0000:01: T104 Start:1513 Size:11 Instances:1 Report IDs:0-0
[ 1988.790053] atmel_mxt_ts i2c-ATML0000:01: T108 Start:1524 Size:75 Instances:1 Report IDs:50-50
[ 1988.790058] atmel_mxt_ts i2c-ATML0000:01: T109 Start:1599 Size:9 Instances:1 Report IDs:51-51
[ 1988.790062] atmel_mxt_ts i2c-ATML0000:01: T111 Start:1608 Size:23 Instances:3 Report IDs:0-0
[ 1988.790066] atmel_mxt_ts i2c-ATML0000:01: T112 Start:1677 Size:5 Instances:2 Report IDs:52-53
[ 1988.790071] atmel_mxt_ts i2c-ATML0000:01: T113 Start:1687 Size:3 Instances:1 Report IDs:0-0
[ 1988.806017] atmel_mxt_ts i2c-ATML0000:01: message: 28 94 97 01 60 01 01 24 04 4b
[ 1988.806021] atmel_mxt_ts i2c-ATML0000:01: message: 29 49 44 02 f0 00 02 00 00 00
[ 1988.806023] atmel_mxt_ts i2c-ATML0000:01: message: 2a 19 b4 01 ae 01 00 2a 03 5e
[ 1988.806024] atmel_mxt_ts i2c-ATML0000:01: message: 2b 49 4b 02 47 01 02 00 00 00
[ 1988.806025] atmel_mxt_ts i2c-ATML0000:01: message: 28 15 e9 01 91 01 00 14 01 29
[ 1988.808689] atmel_mxt_ts i2c-ATML0000:01: T6 Config Checksum: 0x81161B
[ 1988.814052] atmel_mxt_ts i2c-ATML0000:01: message: 03 0e 00 00 00 00 00 00 00 00
[ 1988.814059] atmel_mxt_ts i2c-ATML0000:01: message: 04 00 00 00 00 00 00 00 00 00
[ 1988.814061] atmel_mxt_ts i2c-ATML0000:01: message: 05 00 00 00 00 00 00 00 00 00
[ 1988.814063] atmel_mxt_ts i2c-ATML0000:01: message: 26 00 00 00 00 00 00 00 00 00
[ 1988.814065] atmel_mxt_ts i2c-ATML0000:01: message: 27 00 00 00 00 00 00 00 00 00
[ 1988.814067] atmel_mxt_ts i2c-ATML0000:01: message: 28 15 e9 01 91 01 00 14 01 29
[ 1988.814070] atmel_mxt_ts i2c-ATML0000:01: message: 29 49 44 02 f0 00 02 00 00 00
[ 1988.814072] atmel_mxt_ts i2c-ATML0000:01: message: 2a 19 b4 01 ae 01 00 2a 03 5e
[ 1988.814073] atmel_mxt_ts i2c-ATML0000:01: message: 2b 49 4b 02 47 01 02 00 00 00
[ 1988.814075] atmel_mxt_ts i2c-ATML0000:01: message: 2c 00 00 00 00 00 00 00 00 00
[ 1988.814077] atmel_mxt_ts i2c-ATML0000:01: message: 2d 00 00 00 00 00 00 00 00 00
[ 1988.814079] atmel_mxt_ts i2c-ATML0000:01: message: 2e 00 00 00 00 00 00 00 00 00
[ 1988.814081] atmel_mxt_ts i2c-ATML0000:01: message: 2f 00 00 00 00 00 00 00 00 00
[ 1988.814083] atmel_mxt_ts i2c-ATML0000:01: message: 30 00 00 00 00 00 00 00 00 00
[ 1988.814085] atmel_mxt_ts i2c-ATML0000:01: message: 31 00 00 00 00 00 00 00 00 00
[ 1988.814087] atmel_mxt_ts i2c-ATML0000:01: message: 33 05 00 00 00 00 00 00 00 00
[ 1988.814546] atmel_mxt_ts i2c-ATML0000:01: Interrupt triggered but zero messages
[ 1988.828014] atmel_mxt_ts i2c-ATML0000:01: Warning: Info CRC error - device=0x000000 file=0xFE0A28
[ 1988.828104] atmel_mxt_ts i2c-ATML0000:01: Config CRC error, calculated=8824C9, file=81161B
[ 1988.880438] atmel_mxt_ts i2c-ATML0000:01: T6 Config Checksum: 0x81161B
[ 1988.888101] atmel_mxt_ts i2c-ATML0000:01: Resetting chip
[ 1988.985130] atmel_mxt_ts i2c-ATML0000:01: T6 Status 0x80 RESET
[ 1988.985133] atmel_mxt_ts i2c-ATML0000:01: Config successfully updated
[ 1988.985135] atmel_mxt_ts i2c-ATML0000:01: Invalid object type T9
[ 1988.985137] atmel_mxt_ts i2c-ATML0000:01: Failed to initialize T9 resolution
[ 1988.985209] input: Atmel maXTouch Touchpad as /devices/pci0000:00/INT3432:00/i2c-9/i2c-ATML0000:01/input/input17
[ 1988.986334] atmel_mxt_ts i2c-ATML0000:01: message: 03 0e 00 00 00 00 00 00 00 00
[ 1988.986338] atmel_mxt_ts i2c-ATML0000:01: T6 Status 0x10 CAL
[ 1988.986487] atmel_mxt_ts i2c-ATML0000:01: Family: 164 Variant: 17 Firmware V1.0.AA Objects: 32
[ 1988.987310] atmel_mxt_ts i2c-ATML0000:01: Interrupt triggered but zero messages
[ 1988.988097] atmel_mxt_ts i2c-ATML0000:01: Invalid object type T9
[ 1989.002500] atmel_mxt_ts i2c-ATML0000:01: Invalid object type T9
[ 1989.014274] atmel_mxt_ts i2c-ATML0000:01: Invalid object type T9
[ 1989.075055] atmel_mxt_ts i2c-ATML0000:01: T6 Status 0x00 OK
[ 2378.845942] atmel_mxt_ts i2c-ATML0000:01: message: 28 c4 2f 00 26 00 07 00 00 00
[ 2378.855751] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 07 00 00 00
[ 2378.865445] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 07 00 00 00
[ 2378.875318] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 06 00 00 00
[ 2378.885024] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 06 00 00 00
[ 2378.894862] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 05 00 00 00
[ 2378.904413] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 05 00 00 00
[ 2378.914256] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 04 00 00 00
[ 2378.923926] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 03 00 00 00
[ 2378.933790] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 03 00 00 00
[ 2378.943454] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 03 00 00 00
[ 2378.953318] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 02 00 00 00
[ 2378.962950] atmel_mxt_ts i2c-ATML0000:01: message: 28 c0 2f 00 26 00 02 00 00 00
... lots of interrupt messages when I have my finger hovering or touching the touchpad.
Hello Benjamin,
On 04/15/2015 11:20 PM, Benjamin Tissoires wrote:
> Hi guys,
>
> On Wed, Apr 15, 2015 at 11:58 AM, Javier Martinez Canillas <[email protected]> wrote:
>> Hello Dmitry,
>>
>> On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
>>> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
>>> Google Pixel 2 (2015).
>>>
>>> While newer version of ACPI standard allow use of device-tree-like
>>> properties in device descriptions, the version of ACPI implemented in
>>> Google BIOS does not support them, and we have to resort to DMI data to
>>> specify exact characteristics of the devices (touchpad vs. touchscreen,
>>> GPIO to button mapping, etc).
>>>
>>> Pixel 1 continues to use i2c devices and platform data created by
>>> chromeos-laptop driver, since ACPI does not enumerate them.
>>>
>>> Signed-off-by: Dmitry Torokhov <[email protected]>
>>> ---
> [snipped]
>>
>> Patch looks good to me and I've tested it in a Pixel2 Chromebook using
>> evtest:
>>
>> Reviewed-by: Javier Martinez Canillas <[email protected]>
>> Tested-by: Javier Martinez Canillas <[email protected]>
>>
>
> Hmm, this is weird. I tried to apply the 2 patches of this series to a
> 4.0 fedora kernel[1], and the touch{pad|screen} are desperately muted.
Yes, is not going to work with just 4.0, I tested with today's -next.
> The abs_X/Y max shows up as 0, so there is something wrong with either
> my touchpad (which works fine on ChromeOS) or with the driver.
> There are no differences between 4.0-rcX and the final 4.0 so I suspect
> there must be something else.
> I also copied the 2 samus-* config files from the ChromeOS root to
> /lib/firmware but this does not change anything.
>
> In [3], I enabled the debug output of atmel_mxt, and it seems that the
> table of functions is missing the T9 one, which is the multitouch one... :(
>
The atmel_mxt error message is somehow misleading. The problem is not
that the T9 multitouch object is missing (in fact that's the only one
supported by the driver in 4.0) but that the atmel chip in the pixel2
uses another multitouch object (T100).
So the driver tries to initialize the input device assuming that is a
T9 one and fails showing the "Invalid object type T9" error.
> Any help would be greatly appreciated so we can fix [2] and support
> those laptops in Fedora directly.
>
Patches to add proper T100 support are already in Linus' tree but did
not make it to 4.0. So you need to cherry-pick commits:
b23157dc7427 ("Input: atmel_mxt_ts - implement support for T100 touch object") [0]
b6d2d3289f84 ("Input: atmel_mxt_ts - split out touchpad initialisation logic") [1].
Dmitry mentioned that he used a 4.0+ kernel with Fedora's config so I
guess he also was testing with linux-next or latest Linus' master.
> Cheers,
> Benjamin
>
>
Best regards,
Javier
[0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b23157dc74272ac8ebffd1a566e3e822dbc3e65f
[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b6d2d3289f84e9c7449dff04fb959e29207acd80
Hello Dmitry,
On Wednesday, April 15, 2015 18:35 BST, Dmitry Torokhov <[email protected]> wrote:
> On Wed, Apr 15, 2015 at 05:58:04PM +0200, Javier Martinez Canillas wrote:
> >
> > This is an unrelated cleanup so probably should had been a separate patch?
>
> Fair enough.
>
> --
> Dmitry
>
>
> Input: atmel_mxt_ts - use BIT() macro when reporting button state
>
> From: Dmitry Torokhov <[email protected]>
>
> This makes the intent a tad more clear.
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 0d87ffc..0dcd455 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -726,15 +726,15 @@ static void mxt_input_button(struct mxt_data *data, u8 *message)
> {
> struct input_dev *input = data->input_dev;
> const struct mxt_platform_data *pdata = data->pdata;
> - bool button;
> int i;
>
> - /* Active-low switch */
> for (i = 0; i < pdata->t19_num_keys; i++) {
> if (pdata->t19_keymap[i] == KEY_RESERVED)
> continue;
> - button = !(message[1] & (1 << i));
> - input_report_key(input, pdata->t19_keymap[i], button);
> +
> + /* Active-low switch */
> + input_report_key(input, pdata->t19_keymap[i],
> + !(message[1] & BIT(i)));
> }
> }
>
Patch looks good to me, thanks a lot for splitting the changes
and sorry for the nitpicking.
Reviewed-by: Javier Martinez Canillas <[email protected]>
Best regards,
Javier
On Thu, Apr 16, 2015 at 12:23:03AM +0200, Javier Martinez Canillas wrote:
> Hello Benjamin,
>
> On 04/15/2015 11:20 PM, Benjamin Tissoires wrote:
> > Hi guys,
> >
> > On Wed, Apr 15, 2015 at 11:58 AM, Javier Martinez Canillas <[email protected]> wrote:
> >> Hello Dmitry,
> >>
> >> On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
> >>> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
> >>> Google Pixel 2 (2015).
> >>>
> >>> While newer version of ACPI standard allow use of device-tree-like
> >>> properties in device descriptions, the version of ACPI implemented in
> >>> Google BIOS does not support them, and we have to resort to DMI data to
> >>> specify exact characteristics of the devices (touchpad vs. touchscreen,
> >>> GPIO to button mapping, etc).
> >>>
> >>> Pixel 1 continues to use i2c devices and platform data created by
> >>> chromeos-laptop driver, since ACPI does not enumerate them.
> >>>
> >>> Signed-off-by: Dmitry Torokhov <[email protected]>
> >>> ---
> > [snipped]
> >>
> >> Patch looks good to me and I've tested it in a Pixel2 Chromebook using
> >> evtest:
> >>
> >> Reviewed-by: Javier Martinez Canillas <[email protected]>
> >> Tested-by: Javier Martinez Canillas <[email protected]>
> >>
> >
> > Hmm, this is weird. I tried to apply the 2 patches of this series to a
> > 4.0 fedora kernel[1], and the touch{pad|screen} are desperately muted.
>
> Yes, is not going to work with just 4.0, I tested with today's -next.
>
> > The abs_X/Y max shows up as 0, so there is something wrong with either
> > my touchpad (which works fine on ChromeOS) or with the driver.
> > There are no differences between 4.0-rcX and the final 4.0 so I suspect
> > there must be something else.
> > I also copied the 2 samus-* config files from the ChromeOS root to
> > /lib/firmware but this does not change anything.
> >
> > In [3], I enabled the debug output of atmel_mxt, and it seems that the
> > table of functions is missing the T9 one, which is the multitouch one... :(
> >
>
> The atmel_mxt error message is somehow misleading. The problem is not
> that the T9 multitouch object is missing (in fact that's the only one
> supported by the driver in 4.0) but that the atmel chip in the pixel2
> uses another multitouch object (T100).
>
> So the driver tries to initialize the input device assuming that is a
> T9 one and fails showing the "Invalid object type T9" error.
>
> > Any help would be greatly appreciated so we can fix [2] and support
> > those laptops in Fedora directly.
> >
>
> Patches to add proper T100 support are already in Linus' tree but did
> not make it to 4.0. So you need to cherry-pick commits:
>
> b23157dc7427 ("Input: atmel_mxt_ts - implement support for T100 touch object") [0]
> b6d2d3289f84 ("Input: atmel_mxt_ts - split out touchpad initialisation logic") [1].
>
> Dmitry mentioned that he used a 4.0+ kernel with Fedora's config so I
> guess he also was testing with linux-next or latest Linus' master.
I usually test with my internal tree that consists of mainline (either
at X.0 or at ToT past rc3-rc4 of the current release) + my "for-linus"
branch + my "next" branch + some work in progress that has not made into
for-linus/next but should have no effect on the patches as posted.
Thanks.
--
Dmitry
On Wed, Apr 15, 2015 at 6:43 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Thu, Apr 16, 2015 at 12:23:03AM +0200, Javier Martinez Canillas wrote:
>> Hello Benjamin,
>>
>> On 04/15/2015 11:20 PM, Benjamin Tissoires wrote:
>> > Hi guys,
>> >
>> > On Wed, Apr 15, 2015 at 11:58 AM, Javier Martinez Canillas <[email protected]> wrote:
>> >> Hello Dmitry,
>> >>
>> >> On 04/08/2015 02:26 AM, Dmitry Torokhov wrote:
>> >>> This change allows atmel_mxt_ts to bind to ACPI-enumerated devices in
>> >>> Google Pixel 2 (2015).
>> >>>
>> >>> While newer version of ACPI standard allow use of device-tree-like
>> >>> properties in device descriptions, the version of ACPI implemented in
>> >>> Google BIOS does not support them, and we have to resort to DMI data to
>> >>> specify exact characteristics of the devices (touchpad vs. touchscreen,
>> >>> GPIO to button mapping, etc).
>> >>>
>> >>> Pixel 1 continues to use i2c devices and platform data created by
>> >>> chromeos-laptop driver, since ACPI does not enumerate them.
>> >>>
>> >>> Signed-off-by: Dmitry Torokhov <[email protected]>
>> >>> ---
>> > [snipped]
>> >>
>> >> Patch looks good to me and I've tested it in a Pixel2 Chromebook using
>> >> evtest:
>> >>
>> >> Reviewed-by: Javier Martinez Canillas <[email protected]>
>> >> Tested-by: Javier Martinez Canillas <[email protected]>
>> >>
>> >
>> > Hmm, this is weird. I tried to apply the 2 patches of this series to a
>> > 4.0 fedora kernel[1], and the touch{pad|screen} are desperately muted.
>>
>> Yes, is not going to work with just 4.0, I tested with today's -next.
>>
>> > The abs_X/Y max shows up as 0, so there is something wrong with either
>> > my touchpad (which works fine on ChromeOS) or with the driver.
>> > There are no differences between 4.0-rcX and the final 4.0 so I suspect
>> > there must be something else.
>> > I also copied the 2 samus-* config files from the ChromeOS root to
>> > /lib/firmware but this does not change anything.
>> >
>> > In [3], I enabled the debug output of atmel_mxt, and it seems that the
>> > table of functions is missing the T9 one, which is the multitouch one... :(
>> >
>>
>> The atmel_mxt error message is somehow misleading. The problem is not
>> that the T9 multitouch object is missing (in fact that's the only one
>> supported by the driver in 4.0) but that the atmel chip in the pixel2
>> uses another multitouch object (T100).
>>
>> So the driver tries to initialize the input device assuming that is a
>> T9 one and fails showing the "Invalid object type T9" error.
>>
>> > Any help would be greatly appreciated so we can fix [2] and support
>> > those laptops in Fedora directly.
>> >
>>
>> Patches to add proper T100 support are already in Linus' tree but did
>> not make it to 4.0. So you need to cherry-pick commits:
>>
>> b23157dc7427 ("Input: atmel_mxt_ts - implement support for T100 touch object") [0]
>> b6d2d3289f84 ("Input: atmel_mxt_ts - split out touchpad initialisation logic") [1].
>>
>> Dmitry mentioned that he used a 4.0+ kernel with Fedora's config so I
>> guess he also was testing with linux-next or latest Linus' master.
>
> I usually test with my internal tree that consists of mainline (either
> at X.0 or at ToT past rc3-rc4 of the current release) + my "for-linus"
> branch + my "next" branch + some work in progress that has not made into
> for-linus/next but should have no effect on the patches as posted.
>
Oh... That was it. Thanks to both of you (especially for pointing the
2 patches).
I'll try this and request those to be included in F22.
Cheers,
Benjamin