* Re: [PATCH v2 09/11] docs: Fix some broken references
From: Charles Keepax @ 2018-05-16 9:09 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Catalin Marinas, Linus Walleij, Will Deacon, dri-devel,
Jaroslav Kysela, Eric Paris, linux-clk, James Morris, Alan Stern,
xen-devel, Boqun Feng, Nicholas Piggin, Sean Paul,
Thomas Gleixner, Antoine Jacquet, Greg Kroah-Hartman, linux-usb,
linux-kernel, Li Zefan, linux-crypto, Mark Rutland, alsa-devel,
Linux Doc Mailing List, David Airlie, Gustavo Padovan
In-Reply-To: <e959f23d6f6905ee606fadfda13e2bb37deed017.1525870886.git.mchehab+samsung@kernel.org>
On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> false-positives.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> drivers/input/touchscreen/wm97xx-core.c | 2 +-
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH 0/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-16 12:28 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
Hi,
I have a platform that features an edt-ft5x06 touch panel and that
doesn't want to wake on touch screen activity.
Here's a trivial series of patches that make the edt-ft5x06 driver only
act as wakeup source when requested through device properties or DTS.
The third patch changes the default in two DTS files that use this
driver.
I guess the first two patches should go through the input tree, while
the third can be picked by the IMX people. There are no compile-time
dependencies, so the order doesn't matter.
Thanks,
Daniel
Daniel Mack (3):
input: touchscreen: edt-ft5x06: make wakeup source behavior
configurable
input: touchscreen: edt-ft5x06: assert reset during suspend
ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
.../devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
arch/arm/boot/dts/imx28-tx28.dts | 1 +
arch/arm/boot/dts/imx53-tx53-x03x.dts | 1 +
drivers/input/touchscreen/edt-ft5x06.c | 9 ++++++++-
4 files changed, 13 insertions(+), 1 deletion(-)
--
2.14.3
^ permalink raw reply
* [PATCH 1/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-16 12:28 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180516122829.23694-1-daniel@zonque.org>
Allow configuring the device as wakeup source through device properties, as
not all platforms want to wake up on touch screen activity.
Note that by default, the device will now no longer be a wakeup source.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
drivers/input/touchscreen/edt-ft5x06.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 025cf8c9324a..83f792d4d88c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -52,6 +52,8 @@ Optional properties:
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
+ - wakeup-source: touchscreen acts as wakeup source
+
Example:
polytouch: edt-ft5x06@38 {
compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
@@ -62,4 +64,5 @@ Example:
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 5bf63f76ddda..955f085627fa 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1007,7 +1007,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
goto err_remove_attrs;
edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
- device_init_wakeup(&client->dev, 1);
+ device_init_wakeup(&client->dev,
+ device_property_read_bool(dev, "wakeup-source"));
dev_dbg(&client->dev,
"EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
--
2.14.3
^ permalink raw reply related
* [PATCH 2/3] input: touchscreen: edt-ft5x06: assert reset during suspend
From: Daniel Mack @ 2018-05-16 12:28 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180516122829.23694-1-daniel@zonque.org>
If the device is not configured as wakeup source, it can be put in reset
during suspend to save some power.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 955f085627fa..c34a0b23f90a 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1036,9 +1036,12 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
if (device_may_wakeup(dev))
enable_irq_wake(client->irq);
+ else if (tsdata->reset_gpio)
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 1);
return 0;
}
@@ -1046,9 +1049,12 @@ static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
if (device_may_wakeup(dev))
disable_irq_wake(client->irq);
+ else if (tsdata->reset_gpio)
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
return 0;
}
--
2.14.3
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
From: Daniel Mack @ 2018-05-16 12:28 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180516122829.23694-1-daniel@zonque.org>
The touchscreen driver no longer configures the device as wakeup source by
default. A "wakeup-source" property is needed.
To avoid regressions, this patch changes the DTS files for the only two
users of this driver that didn't have this property yet.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
arch/arm/boot/dts/imx28-tx28.dts | 1 +
arch/arm/boot/dts/imx53-tx53-x03x.dts | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 0ebbc83852d0..094a39a67ec8 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -328,6 +328,7 @@
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
touchscreen: tsc2007@48 {
diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts b/arch/arm/boot/dts/imx53-tx53-x03x.dts
index 0ecb43d88522..dbf0d73dc7b9 100644
--- a/arch/arm/boot/dts/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts
@@ -220,6 +220,7 @@
interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
touchscreen: tsc2007@48 {
--
2.14.3
^ permalink raw reply related
* AW: [PATCH v3] Input: add bu21029 touch driver
From: Jonas Mark (BT-FIR/ENG1) @ 2018-05-16 13:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, linux-input,
devicetree, Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu), Jonas Mark (BT-FIR/ENG1)
In-Reply-To: <CAHp75Vf=eJbJPv5=y3fDKZapAnmABD0=v+WRhrBhMv+RSoBnKg@mail.gmail.com>
Hello Andy,
> > Add Rohm BU21029 resistive touch panel controller support with I2C
> > interface.
>
> > +#include <linux/of.h>
>
> This becomes redundant (see below).
Removed.
> > +#define STOP_DELAY_US 50L
> > +#define START_DELAY_MS 2L
> > +#define BUF_LEN 8L
>
> No need to use L for such small numbers. Integer promotion is a part
> of C standard.
OK.
> > +#define SCALE_12BIT (1 << 12)
> > +#define MAX_12BIT ((1 << 12) - 1)
>
> BIT(12)
> GENMASK(11, 0)
We are not convinced that we should use BIT() and GENMASK() here.
The reason is that SCALE_12BIT is actually not used as a bit but as an
input value for DIV_ROUND_CLOSEST. We think that the BIT() macro will
hide the meaning of the value.
MAX_12BIT is also a value and not a bit mask. Thus, we also think that
using the GENMASK() macro will hide its purpose. Also, the
documentation of GENMASK() says that it is a mask and not a value.
> > +static int bu21029_touch_report(struct bu21029_ts_data *bu21029)
> > +{
> > + struct i2c_client *i2c = bu21029->client;
> > + u8 buf[BUF_LEN];
> > + int error = bu21029_touch_report(bu21029);
>
> > +
>
> Redundant empty line.
Removed.
> > + if (error) {
>
> > + dev_err(&i2c->dev, "failed to report (error: %d)\n", error);
>
> Potential spamming case.
>
> > + return IRQ_NONE;
> > + }
You are right, we will remove the error message.
> > +static void bu21029_stop_chip(struct input_dev *dev)
> > +{
> > + struct bu21029_ts_data *bu21029 = input_get_drvdata(dev);
> > +
> > + disable_irq(bu21029->client->irq);
> > + del_timer_sync(&bu21029->timer);
> > +
> > + /* put chip into reset */
> > + gpiod_set_value_cansleep(bu21029->reset_gpios, 1);
>
> > + udelay(STOP_DELAY_US);
>
> udelay() ?!
>
> > +}
According to the datasheet disabling the chip will take 30 microseconds.
In the defines we added a buffer of 20 microseconds and thus
STOP_DELAY_US is 50. The function guarantees that the chip is stopped
before it returns.
We think that it is ok to use udelay() here because in normal operation
the chip is not stopped. It is only stopped when loading or unloading
the driver, or when the system suspends.
We would like to keep it like it is.
> > +static int bu21029_start_chip(struct input_dev *dev)
> > +{
>
> > + u16 hwid;
> > +
> > + /* take chip out of reset */
> > + gpiod_set_value_cansleep(bu21029->reset_gpios, 0);
>
> > + mdelay(START_DELAY_MS);
>
> mdelay()?!
>
> > +
> > + error = i2c_smbus_read_i2c_block_data(i2c,
> > + BU21029_HWID_REG,
> > + 2,
> > + (u8 *)&hwid);
> > + if (error < 0) {
> > + dev_err(&i2c->dev, "failed to read HW ID\n");
> > + goto out;
> > + }
After de-asserting the reset chip takes 1 millisecond until it is
operational. We added a 1 millisecond buffer to it. Thus,
START_DELAY_MS is 2.
The following I2C read will not succeed without waiting for the chip
being ready.
> > + if (cpu_to_be16(hwid) != SUPPORTED_HWID) {
>
> Hmm... Why cpu_to_be16() is required?
>
> > + dev_err(&i2c->dev, "unsupported HW ID 0x%x\n", hwid);
> > + error = -ENODEV;
> > + goto out;
> > + }
> > +}
You are right, it works but what we meant to do here is to convert the
chip's value (big endian) into the CPU endianness. We will change it to
be16_to_cpu().
> > +static int bu21029_parse_dt(struct bu21029_ts_data *bu21029)
>
> You can get rid of DT requirement by...
>
> > +{
> > + struct device *dev = &bu21029->client->dev;
> > + struct device_node *np = dev->of_node;
> > + u32 val32;
> > + int error;
>
> > + if (!np) {
> > + dev_err(dev, "no device tree data\n");
> > + return -EINVAL;
> > + }
>
> (this becomes redundant)
>
> > +
> > + bu21029->reset_gpios = devm_gpiod_get(dev, "reset",
> GPIOD_OUT_HIGH);
> > + if (IS_ERR(bu21029->reset_gpios)) {
> > + error = PTR_ERR(bu21029->reset_gpios);
> > + if (error != -EPROBE_DEFER)
> > + dev_err(dev, "invalid 'reset-gpios':%d\n", error);
> > + return error;
> > + }
> > +
>
> > + if (of_property_read_u32(np, "rohm,x-plate-ohms", &val32)) {
>
> ...simple calling device_property_read_u32() instead.
>
> > + dev_err(dev, "invalid 'x-plate-ohms' supplied\n");
> > + return -EINVAL;
> > + }
> > + bu21029->x_plate_ohms = val32;
> > +
> > + touchscreen_parse_properties(bu21029->in_dev, false, &bu21029->prop);
> > +
> > + return 0;
> > +}
Thank you, changed.
> > +#ifdef CONFIG_PM_SLEEP
>
> Instead...
>
> > +static int bu21029_suspend(struct device *dev)
>
> ...use __maby_unused annotation.
>
> > +static int bu21029_resume(struct device *dev)
>
> Ditto.
OK, added.
Regards,
Mark
Mark Jonas
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* [PATCH v4] Input: add bu21029 touch driver
From: Mark Jonas @ 2018-05-16 13:25 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland
Cc: linux-input, devicetree, linux-kernel, hs, andy.shevchenko,
Zhu Yi, Mark Jonas
In-Reply-To: <1521651874-15379-1-git-send-email-mark.jonas@de.bosch.com>
From: Zhu Yi <yi.zhu5@cn.bosch.com>
Add Rohm BU21029 resistive touch panel controller support with I2C
interface.
Signed-off-by: Zhu Yi <yi.zhu5@cn.bosch.com>
Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v4:
- remove potential kernel log spamming from irq handler
- fix bug in endianess conversion of the chip's HW ID
- simplify device tree reading
- flag resume and suspend functions as potentially unused
---
Changes in v3:
- reviewed by Rob Herring
---
Changes in v2:
- make ABS_PRESSURE proportionally rising with finger pressure
- fix race between interrupt and timer during shutdown
- use infrastructure from include/linux/input/touchscreen.h
- add SPDX tag for the driver
- improve binding documentation
- fix multi-line comments
---
.../bindings/input/touchscreen/bu21029.txt | 34 ++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/bu21029_ts.c | 475 +++++++++++++++++++++
4 files changed, 522 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/bu21029.txt
create mode 100644 drivers/input/touchscreen/bu21029_ts.c
diff --git a/Documentation/devicetree/bindings/input/touchscreen/bu21029.txt b/Documentation/devicetree/bindings/input/touchscreen/bu21029.txt
new file mode 100644
index 0000000..030a888
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/bu21029.txt
@@ -0,0 +1,34 @@
+* Rohm BU21029 Touch Screen Controller
+
+Required properties:
+ - compatible : must be "rohm,bu21029"
+ - reg : i2c device address of the chip (0x40 or 0x41)
+ - interrupt-parent : the phandle for the gpio controller
+ - interrupts : (gpio) interrupt to which the chip is connected
+ - reset-gpios : gpio pin to reset the chip (active low)
+ - rohm,x-plate-ohms : x-plate resistance in Ohm
+
+Optional properties:
+ - touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
+ - touchscreen-size-y : vertical resolution of touchscreen (in pixels)
+ - touchscreen-max-pressure: maximum pressure value
+
+Example:
+
+ &i2c1 {
+ /* ... */
+
+ bu21029: bu21029@40 {
+ compatible = "rohm,bu21029";
+ reg = <0x40>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio6 16 GPIO_ACTIVE_LOW>;
+ rohm,x-plate-ohms = <600>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-max-pressure = <4095>;
+ };
+
+ /* ... */
+ };
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 4f15496..e09fe8f 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -151,6 +151,18 @@ config TOUCHSCREEN_BU21013
To compile this driver as a module, choose M here: the
module will be called bu21013_ts.
+config TOUCHSCREEN_BU21029
+ tristate "Rohm BU21029 based touch panel controllers"
+ depends on I2C
+ help
+ Say Y here if you have a Rohm BU21029 touchscreen controller
+ connected to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bu21029_ts.
+
config TOUCHSCREEN_CHIPONE_ICN8318
tristate "chipone icn8318 touchscreen controller"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index dddae79..f50624c 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TOUCHSCREEN_AR1021_I2C) += ar1021_i2c.o
obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o
obj-$(CONFIG_TOUCHSCREEN_AUO_PIXCIR) += auo-pixcir-ts.o
obj-$(CONFIG_TOUCHSCREEN_BU21013) += bu21013_ts.o
+obj-$(CONFIG_TOUCHSCREEN_BU21029) += bu21029_ts.o
obj-$(CONFIG_TOUCHSCREEN_CHIPONE_ICN8318) += chipone_icn8318.o
obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
obj-$(CONFIG_TOUCHSCREEN_CYTTSP_CORE) += cyttsp_core.o
diff --git a/drivers/input/touchscreen/bu21029_ts.c b/drivers/input/touchscreen/bu21029_ts.c
new file mode 100644
index 0000000..2bd63d1
--- /dev/null
+++ b/drivers/input/touchscreen/bu21029_ts.c
@@ -0,0 +1,475 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rohm BU21029 touchscreen controller driver
+ *
+ * Copyright (C) 2015-2018 Bosch Sicherheitssysteme GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/touchscreen.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/timer.h>
+
+/*
+ * HW_ID1 Register (PAGE=0, ADDR=0x0E, Reset value=0x02, Read only)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | HW_IDH |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * HW_ID2 Register (PAGE=0, ADDR=0x0F, Reset value=0x29, Read only)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | HW_IDL |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * HW_IDH: high 8bits of IC's ID
+ * HW_IDL: low 8bits of IC's ID
+ */
+#define BU21029_HWID_REG (0x0E << 3)
+#define SUPPORTED_HWID 0x0229
+
+/*
+ * CFR0 Register (PAGE=0, ADDR=0x00, Reset value=0x20)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | 0 | 0 | CALIB | INTRM | 0 | 0 | 0 | 0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * CALIB: 0 = not to use calibration result (*)
+ * 1 = use calibration result
+ * INTRM: 0 = INT output depend on "pen down" (*)
+ * 1 = INT output always "0"
+ */
+#define BU21029_CFR0_REG (0x00 << 3)
+#define CFR0_VALUE 0x00
+
+/*
+ * CFR1 Register (PAGE=0, ADDR=0x01, Reset value=0xA6)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | MAV | AVE[2:0] | 0 | SMPL[2:0] |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * MAV: 0 = median average filter off
+ * 1 = median average filter on (*)
+ * AVE: AVE+1 = number of average samples for MAV,
+ * if AVE>SMPL, then AVE=SMPL (=3)
+ * SMPL: SMPL+1 = number of conversion samples for MAV (=7)
+ */
+#define BU21029_CFR1_REG (0x01 << 3)
+#define CFR1_VALUE 0xA6
+
+/*
+ * CFR2 Register (PAGE=0, ADDR=0x02, Reset value=0x04)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | INTVL_TIME[3:0] | TIME_ST_ADC[3:0] |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * INTVL_TIME: waiting time between completion of conversion
+ * and start of next conversion, only usable in
+ * autoscan mode (=20.480ms)
+ * TIME_ST_ADC: waiting time between application of voltage
+ * to panel and start of A/D conversion (=100us)
+ */
+#define BU21029_CFR2_REG (0x02 << 3)
+#define CFR2_VALUE 0xC9
+
+/*
+ * CFR3 Register (PAGE=0, ADDR=0x0B, Reset value=0x72)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | RM8 | STRETCH| PU90K | DUAL | PIDAC_OFS[3:0] |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * RM8: 0 = coordinate resolution is 12bit (*)
+ * 1 = coordinate resolution is 8bit
+ * STRETCH: 0 = SCL_STRETCH function off
+ * 1 = SCL_STRETCH function on (*)
+ * PU90K: 0 = internal pull-up resistance for touch detection is ~50kohms (*)
+ * 1 = internal pull-up resistance for touch detection is ~90kohms
+ * DUAL: 0 = dual touch detection off (*)
+ * 1 = dual touch detection on
+ * PIDAC_OFS: dual touch detection circuit adjustment, it is not necessary
+ * to change this from initial value
+ */
+#define BU21029_CFR3_REG (0x0B << 3)
+#define CFR3_VALUE 0x42
+
+/*
+ * LDO Register (PAGE=0, ADDR=0x0C, Reset value=0x00)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | 0 | PVDD[2:0] | 0 | AVDD[2:0] |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * PVDD: output voltage of panel output regulator (=2.000V)
+ * AVDD: output voltage of analog circuit regulator (=2.000V)
+ */
+#define BU21029_LDO_REG (0x0C << 3)
+#define LDO_VALUE 0x77
+
+/*
+ * Serial Interface Command Byte 1 (CID=1)
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * | 1 | CF | CMSK | PDM | STP |
+ * +--------+--------+--------+--------+--------+--------+--------+--------+
+ * CF: conversion function, see table 3 in datasheet p6 (=0000, automatic scan)
+ * CMSK: 0 = executes convert function (*)
+ * 1 = reads the convert result
+ * PDM: 0 = power down after convert function stops (*)
+ * 1 = keep power on after convert function stops
+ * STP: 1 = abort current conversion and power down, set to "0" automatically
+ */
+#define BU21029_AUTOSCAN 0x80
+
+/*
+ * The timeout value needs to be larger than INTVL_TIME + tConv4 (sample and
+ * conversion time), where tConv4 is calculated by formula:
+ * tPON + tDLY1 + (tTIME_ST_ADC + (tADC * tSMPL) * 2 + tDLY2) * 3
+ * see figure 8 in datasheet p15 for details of each field.
+ */
+#define PEN_UP_TIMEOUT msecs_to_jiffies(50)
+
+#define STOP_DELAY_US 50
+#define START_DELAY_MS 2
+#define BUF_LEN 8
+#define SCALE_12BIT (1 << 12)
+#define MAX_12BIT ((1 << 12) - 1)
+#define DRIVER_NAME "bu21029"
+
+struct bu21029_ts_data {
+ struct i2c_client *client;
+ struct input_dev *in_dev;
+ struct timer_list timer;
+ struct gpio_desc *reset_gpios;
+ u32 x_plate_ohms;
+ struct touchscreen_properties prop;
+};
+
+static int bu21029_touch_report(struct bu21029_ts_data *bu21029)
+{
+ struct i2c_client *i2c = bu21029->client;
+ u8 buf[BUF_LEN];
+ u16 x, y, z1, z2;
+ u32 rz;
+ s32 max_pressure = bu21029->in_dev->absinfo[ABS_PRESSURE].maximum;
+
+ /* read touch data and deassert INT (by restarting the autoscan mode) */
+ int error = i2c_smbus_read_i2c_block_data(i2c,
+ BU21029_AUTOSCAN,
+ BUF_LEN,
+ buf);
+ if (error < 0)
+ return error;
+
+ /*
+ * compose upper 8 and lower 4 bits into a 12bit value:
+ * +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ * | ByteH | ByteL |
+ * +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ * |b07|b06|b05|b04|b03|b02|b01|b00|b07|b06|b05|b04|b03|b02|b01|b00|
+ * +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ * |v11|v10|v09|v08|v07|v06|v05|v04|v03|v02|v01|v00| 0 | 0 | 0 | 0 |
+ * +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+ */
+ x = (buf[0] << 4) | (buf[1] >> 4);
+ y = (buf[2] << 4) | (buf[3] >> 4);
+ z1 = (buf[4] << 4) | (buf[5] >> 4);
+ z2 = (buf[6] << 4) | (buf[7] >> 4);
+
+ if (z1 == 0 || z2 == 0)
+ return 0;
+
+ /*
+ * calculate Rz (pressure resistance value) by equation:
+ * Rz = Rx * (x/Q) * ((z2/z1) - 1), where
+ * Rx is x-plate resistance,
+ * Q is the touch screen resolution (8bit = 256, 12bit = 4096)
+ * x, z1, z2 are the measured positions.
+ */
+ rz = z2 - z1;
+ rz *= x;
+ rz *= bu21029->x_plate_ohms;
+ rz /= z1;
+ rz = DIV_ROUND_CLOSEST(rz, SCALE_12BIT);
+ if (rz <= max_pressure) {
+ touchscreen_report_pos(bu21029->in_dev, &bu21029->prop,
+ x, y, false);
+ input_report_abs(bu21029->in_dev, ABS_PRESSURE,
+ max_pressure - rz);
+ input_report_key(bu21029->in_dev, BTN_TOUCH, 1);
+ input_sync(bu21029->in_dev);
+ }
+
+ return 0;
+}
+
+static void bu21029_touch_release(struct timer_list *t)
+{
+ struct bu21029_ts_data *bu21029 = from_timer(bu21029, t, timer);
+
+ input_report_abs(bu21029->in_dev, ABS_PRESSURE, 0);
+ input_report_key(bu21029->in_dev, BTN_TOUCH, 0);
+ input_sync(bu21029->in_dev);
+}
+
+static irqreturn_t bu21029_touch_soft_irq(int irq, void *data)
+{
+ struct bu21029_ts_data *bu21029 = data;
+
+ /*
+ * report touch and deassert interrupt (will assert again after
+ * INTVL_TIME + tConv4 for continuous touch)
+ */
+ int error = bu21029_touch_report(bu21029);
+
+ if (error)
+ return IRQ_NONE;
+
+ /* reset timer for pen up detection */
+ mod_timer(&bu21029->timer, jiffies + PEN_UP_TIMEOUT);
+
+ return IRQ_HANDLED;
+}
+
+static void bu21029_stop_chip(struct input_dev *dev)
+{
+ struct bu21029_ts_data *bu21029 = input_get_drvdata(dev);
+
+ disable_irq(bu21029->client->irq);
+ del_timer_sync(&bu21029->timer);
+
+ /* put chip into reset */
+ gpiod_set_value_cansleep(bu21029->reset_gpios, 1);
+ udelay(STOP_DELAY_US);
+}
+
+static int bu21029_start_chip(struct input_dev *dev)
+{
+ struct bu21029_ts_data *bu21029 = input_get_drvdata(dev);
+ struct i2c_client *i2c = bu21029->client;
+ struct {
+ u8 reg;
+ u8 value;
+ } init_table[] = {
+ {BU21029_CFR0_REG, CFR0_VALUE},
+ {BU21029_CFR1_REG, CFR1_VALUE},
+ {BU21029_CFR2_REG, CFR2_VALUE},
+ {BU21029_CFR3_REG, CFR3_VALUE},
+ {BU21029_LDO_REG, LDO_VALUE}
+ };
+ int error, i;
+ u16 hwid;
+
+ /* take chip out of reset */
+ gpiod_set_value_cansleep(bu21029->reset_gpios, 0);
+ mdelay(START_DELAY_MS);
+
+ error = i2c_smbus_read_i2c_block_data(i2c,
+ BU21029_HWID_REG,
+ 2,
+ (u8 *)&hwid);
+ if (error < 0) {
+ dev_err(&i2c->dev, "failed to read HW ID\n");
+ goto out;
+ }
+
+ if (be16_to_cpu(hwid) != SUPPORTED_HWID) {
+ dev_err(&i2c->dev, "unsupported HW ID 0x%x\n", hwid);
+ error = -ENODEV;
+ goto out;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(init_table); ++i) {
+ error = i2c_smbus_write_byte_data(i2c,
+ init_table[i].reg,
+ init_table[i].value);
+ if (error < 0) {
+ dev_err(&i2c->dev,
+ "failed to write 0x%x to register 0x%x\n",
+ init_table[i].value,
+ init_table[i].reg);
+ goto out;
+ }
+ }
+
+ error = i2c_smbus_write_byte(i2c, BU21029_AUTOSCAN);
+ if (error < 0) {
+ dev_err(&i2c->dev, "failed to start autoscan\n");
+ goto out;
+ }
+
+ enable_irq(bu21029->client->irq);
+ return 0;
+
+out:
+ bu21029_stop_chip(dev);
+ return error;
+}
+
+static int bu21029_parse_dt(struct bu21029_ts_data *bu21029)
+{
+ struct device *dev = &bu21029->client->dev;
+ int error;
+
+ bu21029->reset_gpios = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(bu21029->reset_gpios)) {
+ error = PTR_ERR(bu21029->reset_gpios);
+ if (error != -EPROBE_DEFER)
+ dev_err(dev, "invalid 'reset-gpios':%d\n", error);
+ return error;
+ }
+
+ error = device_property_read_u32(dev, "rohm,x-plate-ohms",
+ &bu21029->x_plate_ohms);
+ if (error) {
+ dev_err(dev, "invalid 'x-plate-ohms' supplied:%d\n", error);
+ return error;
+ }
+
+ touchscreen_parse_properties(bu21029->in_dev, false, &bu21029->prop);
+
+ return 0;
+}
+
+static int bu21029_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct bu21029_ts_data *bu21029;
+ struct input_dev *in_dev;
+ int error;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_WRITE_BYTE |
+ I2C_FUNC_SMBUS_WRITE_BYTE_DATA |
+ I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
+ dev_err(&client->dev,
+ "i2c functionality support is not sufficient\n");
+ return -EIO;
+ }
+
+ bu21029 = devm_kzalloc(&client->dev, sizeof(*bu21029), GFP_KERNEL);
+ if (!bu21029)
+ return -ENOMEM;
+
+ in_dev = devm_input_allocate_device(&client->dev);
+ if (!in_dev) {
+ dev_err(&client->dev, "unable to allocate input device\n");
+ return -ENOMEM;
+ }
+
+ bu21029->client = client;
+ bu21029->in_dev = in_dev;
+ timer_setup(&bu21029->timer, bu21029_touch_release, 0);
+
+ in_dev->name = DRIVER_NAME;
+ in_dev->id.bustype = BUS_I2C;
+ in_dev->open = bu21029_start_chip;
+ in_dev->close = bu21029_stop_chip;
+
+ input_set_capability(in_dev, EV_KEY, BTN_TOUCH);
+ input_set_abs_params(in_dev, ABS_X, 0, MAX_12BIT, 0, 0);
+ input_set_abs_params(in_dev, ABS_Y, 0, MAX_12BIT, 0, 0);
+ input_set_abs_params(in_dev, ABS_PRESSURE, 0, MAX_12BIT, 0, 0);
+
+ error = bu21029_parse_dt(bu21029);
+ if (error)
+ return error;
+
+ input_set_drvdata(in_dev, bu21029);
+
+ error = devm_request_threaded_irq(&client->dev,
+ client->irq,
+ NULL,
+ bu21029_touch_soft_irq,
+ IRQF_ONESHOT,
+ DRIVER_NAME,
+ bu21029);
+ if (error) {
+ dev_err(&client->dev, "unable to request touch irq\n");
+ return error;
+ }
+
+ bu21029_stop_chip(in_dev);
+
+ error = input_register_device(in_dev);
+ if (error) {
+ dev_err(&client->dev, "unable to register input device\n");
+ return error;
+ }
+
+ i2c_set_clientdata(client, bu21029);
+
+ return 0;
+}
+
+static int bu21029_remove(struct i2c_client *client)
+{
+ struct bu21029_ts_data *bu21029 = i2c_get_clientdata(client);
+
+ bu21029_stop_chip(bu21029->in_dev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int __maybe_unused bu21029_suspend(struct device *dev)
+{
+ struct i2c_client *i2c = to_i2c_client(dev);
+ struct bu21029_ts_data *bu21029 = i2c_get_clientdata(i2c);
+
+ mutex_lock(&bu21029->in_dev->mutex);
+ if (bu21029->in_dev->users)
+ bu21029_stop_chip(bu21029->in_dev);
+ mutex_unlock(&bu21029->in_dev->mutex);
+
+ return 0;
+}
+
+static int __maybe_unused bu21029_resume(struct device *dev)
+{
+ struct i2c_client *i2c = to_i2c_client(dev);
+ struct bu21029_ts_data *bu21029 = i2c_get_clientdata(i2c);
+
+ mutex_lock(&bu21029->in_dev->mutex);
+ if (bu21029->in_dev->users)
+ bu21029_start_chip(bu21029->in_dev);
+ mutex_unlock(&bu21029->in_dev->mutex);
+
+ return 0;
+}
+#endif
+static SIMPLE_DEV_PM_OPS(bu21029_pm_ops, bu21029_suspend, bu21029_resume);
+
+static const struct i2c_device_id bu21029_ids[] = {
+ {DRIVER_NAME, 0},
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, bu21029_ids);
+
+static struct i2c_driver bu21029_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .pm = &bu21029_pm_ops,
+ },
+ .id_table = bu21029_ids,
+ .probe = bu21029_probe,
+ .remove = bu21029_remove,
+};
+module_i2c_driver(bu21029_driver);
+
+MODULE_AUTHOR("Zhu Yi <yi.zhu5@cn.bosch.com>");
+MODULE_DESCRIPTION("Rohm BU21029 touchscreen controller driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 09/11] docs: Fix some broken references
From: Mathieu Poirier @ 2018-05-16 15:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Catalin Marinas, Linus Walleij, Will Deacon, dri-devel,
Jaroslav Kysela, Eric Paris, linux-clk, James Morris, Alan Stern,
xen-devel, Boqun Feng, Nicholas Piggin, Sean Paul,
Thomas Gleixner, Antoine Jacquet, Greg Kroah-Hartman, linux-usb,
Linux Kernel Mailing List, Li Zefan, linux-crypto, Mark Rutland,
alsa-devel, Linux Doc Mailing List, David Airlie
In-Reply-To: <e959f23d6f6905ee606fadfda13e2bb37deed017.1525870886.git.mchehab+samsung@kernel.org>
On 9 May 2018 at 07:18, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix-rst
>
> Manually checked if the produced result is valid, removing a few
> false-positives.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
> index 1d74ad0202b6..efbc832146e7 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -426,5 +426,5 @@ root@genericarmv8:~#
> Details on how to use the generic STM API can be found here [2].
>
> [1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> -[2]. Documentation/trace/stm.txt
> +[2]. Documentation/trace/stm.rst
> [3]. https://github.com/Linaro/perf-opencsd
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Dmitry Torokhov @ 2018-05-16 17:03 UTC (permalink / raw)
To: Daniel Mack
Cc: mark.rutland, devicetree, robh+dt, kernel, linux-input,
fabio.estevam, shawnguo, linux-arm-kernel
In-Reply-To: <20180516122829.23694-2-daniel@zonque.org>
Hi Daniel,
On Wed, May 16, 2018 at 02:28:27PM +0200, Daniel Mack wrote:
> Allow configuring the device as wakeup source through device properties, as
> not all platforms want to wake up on touch screen activity.
>
> Note that by default, the device will now no longer be a wakeup source.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
> Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
> drivers/input/touchscreen/edt-ft5x06.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> index 025cf8c9324a..83f792d4d88c 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> @@ -52,6 +52,8 @@ Optional properties:
> - touchscreen-inverted-y : See touchscreen.txt
> - touchscreen-swapped-x-y : See touchscreen.txt
>
> + - wakeup-source: touchscreen acts as wakeup source
> +
> Example:
> polytouch: edt-ft5x06@38 {
> compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
> @@ -62,4 +64,5 @@ Example:
> interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
> wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> + wakeup-source;
> };
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 5bf63f76ddda..955f085627fa 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -1007,7 +1007,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
> goto err_remove_attrs;
>
> edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
> - device_init_wakeup(&client->dev, 1);
> + device_init_wakeup(&client->dev,
> + device_property_read_bool(dev, "wakeup-source"));
I think we should actually drop device_init_wakeup() call. I2C core
already handles "wakeup-source" property (for OF). The static board
files can instantiate clients with I2C_CLIENT_WAKE, so that's handled
too, and I think ACPI has its own notion of annotating wakeup sources.
>
> dev_dbg(&client->dev,
> "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
> --
> 2.14.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] input: touchscreen: edt-ft5x06: assert reset during suspend
From: Dmitry Torokhov @ 2018-05-16 17:05 UTC (permalink / raw)
To: Daniel Mack
Cc: mark.rutland, devicetree, robh+dt, kernel, linux-input,
fabio.estevam, shawnguo, linux-arm-kernel
In-Reply-To: <20180516122829.23694-3-daniel@zonque.org>
On Wed, May 16, 2018 at 02:28:28PM +0200, Daniel Mack wrote:
> If the device is not configured as wakeup source, it can be put in reset
> during suspend to save some power.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
> drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 955f085627fa..c34a0b23f90a 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -1036,9 +1036,12 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
> static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
>
> if (device_may_wakeup(dev))
> enable_irq_wake(client->irq);
> + else if (tsdata->reset_gpio)
> + gpiod_set_value_cansleep(tsdata->reset_gpio, 1);
>
> return 0;
> }
> @@ -1046,9 +1049,12 @@ static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
>
> if (device_may_wakeup(dev))
> disable_irq_wake(client->irq);
> + else if (tsdata->reset_gpio)
> + gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
I think you need msleep() here as the chip needs a bit to get out of
reset before it is ready. FWIW we have 300 ms delay in probe().
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Dmitry Torokhov @ 2018-05-16 17:15 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
Oleksandr Andrushchenko
In-Reply-To: <20180514144029.16019-2-andr2000@gmail.com>
Hi Oleksandr,
On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
> @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
> if (!info->page)
> goto error_nomem;
>
> - /* Set input abs params to match backend screen res */
> - abs = xenbus_read_unsigned(dev->otherend,
> - XENKBD_FIELD_FEAT_ABS_POINTER, 0);
> - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
> - XENKBD_FIELD_WIDTH,
> - ptr_size[KPARAM_X]);
> - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
> - XENKBD_FIELD_HEIGHT,
> - ptr_size[KPARAM_Y]);
> - if (abs) {
> - ret = xenbus_write(XBT_NIL, dev->nodename,
> - XENKBD_FIELD_REQ_ABS_POINTER, "1");
> - if (ret) {
> - pr_warn("xenkbd: can't request abs-pointer\n");
> - abs = 0;
> - }
> - }
> + /*
> + * The below are reverse logic, e.g. if the feature is set, then
> + * do not expose the corresponding virtual device.
> + */
> + with_kbd = !xenbus_read_unsigned(dev->nodename,
> + XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
>
> - touch = xenbus_read_unsigned(dev->nodename,
> - XENKBD_FIELD_FEAT_MTOUCH, 0);
> - if (touch) {
> + with_ptr = !xenbus_read_unsigned(dev->nodename,
> + XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
> +
> + /* Direct logic: if set, then create multi-touch device. */
> + with_mtouch = xenbus_read_unsigned(dev->nodename,
> + XENKBD_FIELD_FEAT_MTOUCH, 0);
> + if (with_mtouch) {
> ret = xenbus_write(XBT_NIL, dev->nodename,
> XENKBD_FIELD_REQ_MTOUCH, "1");
> if (ret) {
> pr_warn("xenkbd: can't request multi-touch");
> - touch = 0;
> + with_mtouch = 0;
> }
> }
Does it make sense to still end up calling xenkbd_connect_backend() when
all interfaces (keyboard, pointer, and multitouch) are disabled? Should
we do:
if (!(with_kbd || || with_ptr || with_mtouch))
return -ENXIO;
?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: add bu21029 touch driver
From: Dmitry Torokhov @ 2018-05-16 17:43 UTC (permalink / raw)
To: Jonas Mark (BT-FIR/ENG1)
Cc: Andy Shevchenko, Rob Herring, Mark Rutland, linux-input,
devicetree, Linux Kernel Mailing List, Heiko Schocher,
ZHU Yi (BT-FIR/ENG1-Zhu)
In-Reply-To: <e514418e94bc4e0492512f7ba24170af@de.bosch.com>
On Wed, May 16, 2018 at 01:24:24PM +0000, Jonas Mark (BT-FIR/ENG1) wrote:
> Hello Andy,
>
> > > Add Rohm BU21029 resistive touch panel controller support with I2C
> > > interface.
> >
> > > +#include <linux/of.h>
> >
> > This becomes redundant (see below).
>
> Removed.
>
> > > +#define STOP_DELAY_US 50L
> > > +#define START_DELAY_MS 2L
> > > +#define BUF_LEN 8L
> >
> > No need to use L for such small numbers. Integer promotion is a part
> > of C standard.
>
> OK.
>
> > > +#define SCALE_12BIT (1 << 12)
> > > +#define MAX_12BIT ((1 << 12) - 1)
> >
> > BIT(12)
> > GENMASK(11, 0)
>
> We are not convinced that we should use BIT() and GENMASK() here.
>
> The reason is that SCALE_12BIT is actually not used as a bit but as an
> input value for DIV_ROUND_CLOSEST. We think that the BIT() macro will
> hide the meaning of the value.
>
> MAX_12BIT is also a value and not a bit mask. Thus, we also think that
> using the GENMASK() macro will hide its purpose. Also, the
> documentation of GENMASK() says that it is a mask and not a value.
I agree.
>
> > > +static int bu21029_touch_report(struct bu21029_ts_data *bu21029)
> > > +{
> > > + struct i2c_client *i2c = bu21029->client;
> > > + u8 buf[BUF_LEN];
> > > + int error = bu21029_touch_report(bu21029);
> >
> > > +
> >
> > Redundant empty line.
>
> Removed.
>
> > > + if (error) {
> >
> > > + dev_err(&i2c->dev, "failed to report (error: %d)\n", error);
> >
> > Potential spamming case.
> >
> > > + return IRQ_NONE;
> > > + }
>
> You are right, we will remove the error message.
>
> > > +static void bu21029_stop_chip(struct input_dev *dev)
> > > +{
> > > + struct bu21029_ts_data *bu21029 = input_get_drvdata(dev);
> > > +
> > > + disable_irq(bu21029->client->irq);
> > > + del_timer_sync(&bu21029->timer);
> > > +
> > > + /* put chip into reset */
> > > + gpiod_set_value_cansleep(bu21029->reset_gpios, 1);
> >
> > > + udelay(STOP_DELAY_US);
> >
> > udelay() ?!
> >
> > > +}
>
> According to the datasheet disabling the chip will take 30 microseconds.
> In the defines we added a buffer of 20 microseconds and thus
> STOP_DELAY_US is 50. The function guarantees that the chip is stopped
> before it returns.
>
> We think that it is ok to use udelay() here because in normal operation
> the chip is not stopped. It is only stopped when loading or unloading
> the driver, or when the system suspends.
>
> We would like to keep it like it is.
The issue is not with having delay here, but the kind of delay you are
using: udelay makes CPU spin for given amount of time; you really want
msleep() or usleep_range() here.
>
> > > +static int bu21029_start_chip(struct input_dev *dev)
> > > +{
> >
> > > + u16 hwid;
> > > +
> > > + /* take chip out of reset */
> > > + gpiod_set_value_cansleep(bu21029->reset_gpios, 0);
> >
> > > + mdelay(START_DELAY_MS);
> >
> > mdelay()?!
Same here - replace with msleep().
> >
> > > +
> > > + error = i2c_smbus_read_i2c_block_data(i2c,
> > > + BU21029_HWID_REG,
> > > + 2,
> > > + (u8 *)&hwid);
> > > + if (error < 0) {
> > > + dev_err(&i2c->dev, "failed to read HW ID\n");
> > > + goto out;
> > > + }
>
> After de-asserting the reset chip takes 1 millisecond until it is
> operational. We added a 1 millisecond buffer to it. Thus,
> START_DELAY_MS is 2.
>
> The following I2C read will not succeed without waiting for the chip
> being ready.
>
> > > + if (cpu_to_be16(hwid) != SUPPORTED_HWID) {
> >
> > Hmm... Why cpu_to_be16() is required?
> >
> > > + dev_err(&i2c->dev, "unsupported HW ID 0x%x\n", hwid);
> > > + error = -ENODEV;
> > > + goto out;
> > > + }
> > > +}
>
> You are right, it works but what we meant to do here is to convert the
> chip's value (big endian) into the CPU endianness. We will change it to
> be16_to_cpu().
>
> > > +static int bu21029_parse_dt(struct bu21029_ts_data *bu21029)
> >
> > You can get rid of DT requirement by...
> >
> > > +{
> > > + struct device *dev = &bu21029->client->dev;
> > > + struct device_node *np = dev->of_node;
> > > + u32 val32;
> > > + int error;
> >
> > > + if (!np) {
> > > + dev_err(dev, "no device tree data\n");
> > > + return -EINVAL;
> > > + }
> >
> > (this becomes redundant)
> >
> > > +
> > > + bu21029->reset_gpios = devm_gpiod_get(dev, "reset",
> > GPIOD_OUT_HIGH);
> > > + if (IS_ERR(bu21029->reset_gpios)) {
> > > + error = PTR_ERR(bu21029->reset_gpios);
> > > + if (error != -EPROBE_DEFER)
> > > + dev_err(dev, "invalid 'reset-gpios':%d\n", error);
> > > + return error;
> > > + }
> > > +
> >
> > > + if (of_property_read_u32(np, "rohm,x-plate-ohms", &val32)) {
> >
> > ...simple calling device_property_read_u32() instead.
> >
> > > + dev_err(dev, "invalid 'x-plate-ohms' supplied\n");
> > > + return -EINVAL;
> > > + }
> > > + bu21029->x_plate_ohms = val32;
> > > +
> > > + touchscreen_parse_properties(bu21029->in_dev, false, &bu21029->prop);
> > > +
> > > + return 0;
> > > +}
>
> Thank you, changed.
>
> > > +#ifdef CONFIG_PM_SLEEP
> >
> > Instead...
> >
> > > +static int bu21029_suspend(struct device *dev)
> >
> > ...use __maby_unused annotation.
> >
> > > +static int bu21029_resume(struct device *dev)
> >
> > Ditto.
>
> OK, added.
You also need to drop #ifdef CONFIG_SLEEP. That's the point: we want to
reduce amount of conditionally compiled code and use __maybe_unused to
shut off compiler warning about some functions not used in certain
configurations. We rely on linker to eliminate dead functions from
executable.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-05-16 17:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
Oleksandr Andrushchenko
In-Reply-To: <20180516171528.GD21971@dtor-ws>
On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
> Hi Oleksandr,
>
> On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
>> @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
>> if (!info->page)
>> goto error_nomem;
>>
>> - /* Set input abs params to match backend screen res */
>> - abs = xenbus_read_unsigned(dev->otherend,
>> - XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>> - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>> - XENKBD_FIELD_WIDTH,
>> - ptr_size[KPARAM_X]);
>> - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>> - XENKBD_FIELD_HEIGHT,
>> - ptr_size[KPARAM_Y]);
>> - if (abs) {
>> - ret = xenbus_write(XBT_NIL, dev->nodename,
>> - XENKBD_FIELD_REQ_ABS_POINTER, "1");
>> - if (ret) {
>> - pr_warn("xenkbd: can't request abs-pointer\n");
>> - abs = 0;
>> - }
>> - }
>> + /*
>> + * The below are reverse logic, e.g. if the feature is set, then
>> + * do not expose the corresponding virtual device.
>> + */
>> + with_kbd = !xenbus_read_unsigned(dev->nodename,
>> + XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
>>
>> - touch = xenbus_read_unsigned(dev->nodename,
>> - XENKBD_FIELD_FEAT_MTOUCH, 0);
>> - if (touch) {
>> + with_ptr = !xenbus_read_unsigned(dev->nodename,
>> + XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
>> +
>> + /* Direct logic: if set, then create multi-touch device. */
>> + with_mtouch = xenbus_read_unsigned(dev->nodename,
>> + XENKBD_FIELD_FEAT_MTOUCH, 0);
>> + if (with_mtouch) {
>> ret = xenbus_write(XBT_NIL, dev->nodename,
>> XENKBD_FIELD_REQ_MTOUCH, "1");
>> if (ret) {
>> pr_warn("xenkbd: can't request multi-touch");
>> - touch = 0;
>> + with_mtouch = 0;
>> }
>> }
> Does it make sense to still end up calling xenkbd_connect_backend() when
> all interfaces (keyboard, pointer, and multitouch) are disabled? Should
> we do:
>
> if (!(with_kbd || || with_ptr || with_mtouch))
> return -ENXIO;
>
> ?
It does make sense. Then we probably need to move all xenbus_read_unsigned
calls to the very beginning of the .probe, so no memory allocations are made
which will be useless if we return -ENXIO, e.g. something like
static int xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
int ret, i;
bool with_mtouch, with_kbd, with_ptr;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
<read with_mtouch, with_kbd, with_ptr here>
if (!(with_kbd | with_ptr | with_mtouch))
return -ENXIO;
Does the above looks ok?
> Thanks.
>
Thank you,
Oleksandr
^ permalink raw reply
* Sometimes unusable i2c-hid devices in 4.17-rcX
From: Mario.Limonciello @ 2018-05-16 20:00 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel
Hi All,
I've been running 4.16-rc7 on an XPS 9365 for some time and recently moved up to 4.17-rc5.
Immediately I noticed that i2c-hid devices (both touchscreen and touchpad) were not working.
Also when shutting the system down or rebooting it would just hang. (magic sysrq still worked).
I figured it was an easy to identify regression so I started a bisect but it came up with garbage
that ended in selftests shortly after 4.17-rc2. I realized that's because is still will fail on 4.17-rc2
occasionally, seemingly after trying something newer and warm rebooting.
So it seems like it's "worse" after 4.17-rc2 (doesn't work at all) but semi reproducible on 4.17-rc2.
Not sure if I'm chasing some initialization race, but wanted to see if anyone else was running into this
or has some ideas?
#dmesg | grep 'i2c\|hid' doesn't show any obvious errors when in this state of non functional hid stuff.
[ 2.398649] i2c /dev entries driver
[ 2.881651] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.683583] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: enum_devices_done OK, num_hid_devices=5
[ 3.701259] hid-generic 001F:8086:22D8.0001: hidraw0: <UNKNOWN> HID v2.00 Device [hid-ishtp 8086:22D8] on
[ 3.702204] hid-generic 001F:8086:22D8.0002: hidraw1: <UNKNOWN> HID v2.00 Device [hid-ishtp 8086:22D8] on
[ 3.703063] hid-generic 001F:8086:22D8.0003: hidraw2: <UNKNOWN> HID v2.00 Device [hid-ishtp 8086:22D8] on
[ 3.704276] hid-generic 001F:8086:22D8.0004: hidraw3: <UNKNOWN> HID v2.00 Device [hid-ishtp 8086:22D8] on
[ 3.704557] hid-generic 001F:8086:22D8.0005: hidraw4: <UNKNOWN> HID v2.00 Device [hid-ishtp 8086:22D8] on
[ 3.750710] psmouse serio1: synaptics: Your touchpad (PNP: DLL077a PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
[ 7.030446] acpi INT33D5:00: intel-hid: created platform device
[ 7.199178] i2c_hid i2c-WCOM482F:00: i2c-WCOM482F:00 supply vdd not found, using dummy regulator
[ 7.246638] input: WCOM482F:00 056A:482F as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input11
[ 7.246873] hid-generic 0018:056A:482F.0006: input,hidraw0: I2C HID v1.00 Mouse [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[ 7.275279] i2c_hid i2c-DLL077A:01: i2c-DLL077A:01 supply vdd not found, using dummy regulator
[ 7.304107] input: DLL077A:01 06CB:76AF as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input14
[ 7.304212] hid-generic 0018:06CB:76AF.0007: input,hidraw1: I2C HID v1.00 Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
[ 7.657123] usbcore: registered new interface driver usbhid
[ 7.657124] usbhid: USB HID core driver
[ 7.722876] input: Wacom HID 482F Pen as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input15
[ 7.723148] input: Wacom HID 482F Finger as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input16
[ 7.723611] wacom 0018:056A:482F.0006: hidraw0: I2C HID v1.00 Mouse [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[ 7.768275] input: DLL077A:01 06CB:76AF Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input19
[ 7.864201] hid-multitouch 0018:06CB:76AF.0007: input,hidraw0: I2C HID v1.00 Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
However in this state, I can't rmmod i2c-hid. It just hangs the system with this trace:
[ 243.033779] INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
[ 243.033793] Not tainted 4.17.0-rc1+ #37
[ 243.033798] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.033804] kworker/u8:0 D 0 6 2 0x80000000
[ 243.033826] Workqueue: events_power_efficient power_supply_deferred_register_work
[ 243.033832] Call Trace:
[ 243.033850] __schedule+0x3c2/0x890
[ 243.033861] ? __switch_to_asm+0x40/0x70
[ 243.033868] schedule+0x36/0x80
[ 243.033875] schedule_preempt_disabled+0xe/0x10
[ 243.033882] __mutex_lock.isra.4+0x2ae/0x4e0
[ 243.033890] ? __switch_to_asm+0x34/0x70
[ 243.033899] ? __switch_to_asm+0x40/0x70
[ 243.033906] ? __switch_to_asm+0x40/0x70
[ 243.033914] __mutex_lock_slowpath+0x13/0x20
[ 243.033920] ? __mutex_lock_slowpath+0x13/0x20
[ 243.033927] mutex_lock+0x2f/0x40
[ 243.033933] power_supply_deferred_register_work+0x2b/0x50
[ 243.033944] process_one_work+0x148/0x3d0
[ 243.033952] worker_thread+0x4b/0x460
[ 243.033960] kthread+0x102/0x140
[ 243.033967] ? rescuer_thread+0x380/0x380
[ 243.033973] ? kthread_associate_blkcg+0xa0/0xa0
[ 243.033982] ret_from_fork+0x35/0x40
[ 243.034012] INFO: task systemd-udevd:308 blocked for more than 120 seconds.
[ 243.034018] Not tainted 4.17.0-rc1+ #37
[ 243.034022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.034027] systemd-udevd D 0 308 279 0x80000104
[ 243.034033] Call Trace:
[ 243.034041] __schedule+0x3c2/0x890
[ 243.034049] schedule+0x36/0x80
[ 243.034056] schedule_timeout+0x1e7/0x360
[ 243.034066] ? ttwu_do_activate+0x77/0x80
[ 243.034074] wait_for_completion+0xb4/0x140
[ 243.034082] ? wake_up_q+0x70/0x70
[ 243.034090] flush_work+0x12a/0x1e0
[ 243.034097] ? worker_detach_from_pool+0xb0/0xb0
[ 243.034107] __cancel_work_timer+0x112/0x190
[ 243.034116] cancel_delayed_work_sync+0x13/0x20
[ 243.034122] power_supply_unregister+0x37/0xb0
[ 243.034127] devm_power_supply_release+0x11/0x20
[ 243.034135] release_nodes+0x107/0x1f0
[ 243.034147] devres_release_group+0x7c/0xb0
[ 243.034162] wacom_remove+0xce/0x120 [wacom]
[ 243.034178] hid_device_remove+0x4d/0xa0 [hid]
[ 243.034187] device_release_driver_internal+0x155/0x220
[ 243.034198] ? __hid_bus_driver_added+0x40/0x40 [hid]
[ 243.034208] ? hid_destroy_device+0x60/0x60 [hid]
[ 243.034215] device_release_driver+0x12/0x20
[ 243.034221] device_reprobe+0x30/0x50
[ 243.034231] __hid_bus_reprobe_drivers+0x45/0x50 [hid]
[ 243.034239] bus_for_each_dev+0x64/0xb0
[ 243.034250] __hid_bus_driver_added+0x2c/0x40 [hid]
[ 243.034256] bus_for_each_drv+0x67/0xb0
[ 243.034267] __hid_register_driver+0x6f/0x80 [hid]
[ 243.034275] ? 0xffffffffc07f5000
[ 243.034287] mt_driver_init+0x23/0x1000 [hid_multitouch]
[ 243.034296] do_one_initcall+0x4f/0x1ce
[ 243.034303] ? _cond_resched+0x1a/0x50
[ 243.034315] ? kmem_cache_alloc_trace+0xb8/0x1f0
[ 243.034327] do_init_module+0x5f/0x219
[ 243.034335] load_module+0x24c7/0x2be0
[ 243.034348] __do_sys_finit_module+0xe5/0x120
[ 243.034354] ? __do_sys_finit_module+0xe5/0x120
[ 243.034363] __x64_sys_finit_module+0x1a/0x20
[ 243.034370] do_syscall_64+0x54/0x110
[ 243.034380] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 243.034386] RIP: 0033:0x7f2ec539c839
[ 243.034390] RSP: 002b:00007ffcfc620298 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 243.034396] RAX: ffffffffffffffda RBX: 000055d6a0147ec0 RCX: 00007f2ec539c839
[ 243.034399] RDX: 0000000000000000 RSI: 00007f2ec507b0e5 RDI: 000000000000000f
[ 243.034402] RBP: 00007f2ec507b0e5 R08: 0000000000000000 R09: 00007ffcfc6203b0
[ 243.034405] R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000000
[ 243.034408] R13: 000055d6a017b3a0 R14: 0000000000020000 R15: 000055d6a0147ec0
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Dmitry Torokhov @ 2018-05-16 21:08 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
Oleksandr Andrushchenko
In-Reply-To: <e9882c52-3641-7c32-1f64-dd9c4f35de5f@gmail.com>
On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
> On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
> > Hi Oleksandr,
> >
> > On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
> > > @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
> > > if (!info->page)
> > > goto error_nomem;
> > > - /* Set input abs params to match backend screen res */
> > > - abs = xenbus_read_unsigned(dev->otherend,
> > > - XENKBD_FIELD_FEAT_ABS_POINTER, 0);
> > > - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
> > > - XENKBD_FIELD_WIDTH,
> > > - ptr_size[KPARAM_X]);
> > > - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
> > > - XENKBD_FIELD_HEIGHT,
> > > - ptr_size[KPARAM_Y]);
> > > - if (abs) {
> > > - ret = xenbus_write(XBT_NIL, dev->nodename,
> > > - XENKBD_FIELD_REQ_ABS_POINTER, "1");
> > > - if (ret) {
> > > - pr_warn("xenkbd: can't request abs-pointer\n");
> > > - abs = 0;
> > > - }
> > > - }
> > > + /*
> > > + * The below are reverse logic, e.g. if the feature is set, then
> > > + * do not expose the corresponding virtual device.
> > > + */
> > > + with_kbd = !xenbus_read_unsigned(dev->nodename,
> > > + XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
> > > - touch = xenbus_read_unsigned(dev->nodename,
> > > - XENKBD_FIELD_FEAT_MTOUCH, 0);
> > > - if (touch) {
> > > + with_ptr = !xenbus_read_unsigned(dev->nodename,
> > > + XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
> > > +
> > > + /* Direct logic: if set, then create multi-touch device. */
> > > + with_mtouch = xenbus_read_unsigned(dev->nodename,
> > > + XENKBD_FIELD_FEAT_MTOUCH, 0);
> > > + if (with_mtouch) {
> > > ret = xenbus_write(XBT_NIL, dev->nodename,
> > > XENKBD_FIELD_REQ_MTOUCH, "1");
> > > if (ret) {
> > > pr_warn("xenkbd: can't request multi-touch");
> > > - touch = 0;
> > > + with_mtouch = 0;
> > > }
> > > }
> > Does it make sense to still end up calling xenkbd_connect_backend() when
> > all interfaces (keyboard, pointer, and multitouch) are disabled? Should
> > we do:
> >
> > if (!(with_kbd || || with_ptr || with_mtouch))
> > return -ENXIO;
> >
> > ?
> It does make sense. Then we probably need to move all xenbus_read_unsigned
> calls to the very beginning of the .probe, so no memory allocations are made
> which will be useless if we return -ENXIO, e.g. something like
>
> static int xenkbd_probe(struct xenbus_device *dev,
> const struct xenbus_device_id *id)
> {
> int ret, i;
> bool with_mtouch, with_kbd, with_ptr;
> struct xenkbd_info *info;
> struct input_dev *kbd, *ptr, *mtouch;
>
> <read with_mtouch, with_kbd, with_ptr here>
>
> if (!(with_kbd | with_ptr | with_mtouch))
> return -ENXIO;
>
> Does the above looks ok?
Yes. Another option is to keep the check where I suggested and do
if (...) {
ret = -ENXIO;
goto error;
}
Whichever you prefer is fine with me.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer
From: Juergen Gross @ 2018-05-17 4:28 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Konrad Rzeszutek Wilk
Cc: xen-devel, dmitry.torokhov, jandryuk, Oleksandr Andrushchenko,
linux-input
In-Reply-To: <6cd29db8-e931-fe8a-7857-8d9d8cdace9a@gmail.com>
On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
> On 05/11/2018 06:15 PM, Juergen Gross wrote:
>> On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
>>> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
>>>> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko
>>>> wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> Add missing string constants for {feature|request}-raw-pointer
>>>>> to align with the rest of the interface file.
>>>>>
>>>>> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and
>>>>> "request-raw-pointer")
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>>> <oleksandr_andrushchenko@epam.com>
>>>>
>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Juergen, you OK with an release-ack?
>> Yes:
>>
>> Release-acked-by: Juergen Gross <jgross@suse.com>
> Is this ack for both patches or this one only?
It was meant for patch 1 only.
> I see Konrad has applied this patch, but
> "[Xen-devel][PATCH v4 2/2] xen/kbdif: Add features to disable keyboard
> and pointer"
> is still floating.
In principle I'm fine with taking it for 4.11, but I think at this stage
of the release there should be a formal request to include it.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer
From: Oleksandr Andrushchenko @ 2018-05-17 5:29 UTC (permalink / raw)
To: Juergen Gross, Konrad Rzeszutek Wilk
Cc: xen-devel, dmitry.torokhov, jandryuk, Oleksandr Andrushchenko,
linux-input
In-Reply-To: <2f77fa72-c0bd-7086-1197-23007ce91cb7@suse.com>
On 05/17/2018 07:28 AM, Juergen Gross wrote:
> On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
>> On 05/11/2018 06:15 PM, Juergen Gross wrote:
>>> On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
>>>> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
>>>>> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko
>>>>> wrote:
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>
>>>>>> Add missing string constants for {feature|request}-raw-pointer
>>>>>> to align with the rest of the interface file.
>>>>>>
>>>>>> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and
>>>>>> "request-raw-pointer")
>>>>>>
>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>>>> <oleksandr_andrushchenko@epam.com>
>>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Juergen, you OK with an release-ack?
>>> Yes:
>>>
>>> Release-acked-by: Juergen Gross <jgross@suse.com>
>> Is this ack for both patches or this one only?
> It was meant for patch 1 only.
Clear
>> I see Konrad has applied this patch, but
>> "[Xen-devel][PATCH v4 2/2] xen/kbdif: Add features to disable keyboard
>> and pointer"
>> is still floating.
> In principle I'm fine with taking it for 4.11, but I think at this stage
> of the release there should be a formal request to include it.
...and the request should come from Konrad?
Or who else may request that?
And, as I have r-b's from Konrad for both patches,
will it be ok if we apply the corresponding changes to the
kernel now, so my change to xen-kbdfront is unblocked?
>
> Juergen
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-05-17 5:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
boris.ostrovsky, konrad.wilk, andrii_chepurnyi,
Oleksandr Andrushchenko
In-Reply-To: <20180516210817.GF21971@dtor-ws>
On 05/17/2018 12:08 AM, Dmitry Torokhov wrote:
> On Wed, May 16, 2018 at 08:47:30PM +0300, Oleksandr Andrushchenko wrote:
>> On 05/16/2018 08:15 PM, Dmitry Torokhov wrote:
>>> Hi Oleksandr,
>>>
>>> On Mon, May 14, 2018 at 05:40:29PM +0300, Oleksandr Andrushchenko wrote:
>>>> @@ -211,93 +220,114 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>> if (!info->page)
>>>> goto error_nomem;
>>>> - /* Set input abs params to match backend screen res */
>>>> - abs = xenbus_read_unsigned(dev->otherend,
>>>> - XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>>>> - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>>>> - XENKBD_FIELD_WIDTH,
>>>> - ptr_size[KPARAM_X]);
>>>> - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>>>> - XENKBD_FIELD_HEIGHT,
>>>> - ptr_size[KPARAM_Y]);
>>>> - if (abs) {
>>>> - ret = xenbus_write(XBT_NIL, dev->nodename,
>>>> - XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>>> - if (ret) {
>>>> - pr_warn("xenkbd: can't request abs-pointer\n");
>>>> - abs = 0;
>>>> - }
>>>> - }
>>>> + /*
>>>> + * The below are reverse logic, e.g. if the feature is set, then
>>>> + * do not expose the corresponding virtual device.
>>>> + */
>>>> + with_kbd = !xenbus_read_unsigned(dev->nodename,
>>>> + XENKBD_FIELD_FEAT_DSBL_KEYBRD, 0);
>>>> - touch = xenbus_read_unsigned(dev->nodename,
>>>> - XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>> - if (touch) {
>>>> + with_ptr = !xenbus_read_unsigned(dev->nodename,
>>>> + XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
>>>> +
>>>> + /* Direct logic: if set, then create multi-touch device. */
>>>> + with_mtouch = xenbus_read_unsigned(dev->nodename,
>>>> + XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>> + if (with_mtouch) {
>>>> ret = xenbus_write(XBT_NIL, dev->nodename,
>>>> XENKBD_FIELD_REQ_MTOUCH, "1");
>>>> if (ret) {
>>>> pr_warn("xenkbd: can't request multi-touch");
>>>> - touch = 0;
>>>> + with_mtouch = 0;
>>>> }
>>>> }
>>> Does it make sense to still end up calling xenkbd_connect_backend() when
>>> all interfaces (keyboard, pointer, and multitouch) are disabled? Should
>>> we do:
>>>
>>> if (!(with_kbd || || with_ptr || with_mtouch))
>>> return -ENXIO;
>>>
>>> ?
>> It does make sense. Then we probably need to move all xenbus_read_unsigned
>> calls to the very beginning of the .probe, so no memory allocations are made
>> which will be useless if we return -ENXIO, e.g. something like
>>
>> static int xenkbd_probe(struct xenbus_device *dev,
>> const struct xenbus_device_id *id)
>> {
>> int ret, i;
>> bool with_mtouch, with_kbd, with_ptr;
>> struct xenkbd_info *info;
>> struct input_dev *kbd, *ptr, *mtouch;
>>
>> <read with_mtouch, with_kbd, with_ptr here>
>>
>> if (!(with_kbd | with_ptr | with_mtouch))
>> return -ENXIO;
>>
>> Does the above looks ok?
> Yes. Another option is to keep the check where I suggested and do
>
> if (...) {
> ret = -ENXIO;
> goto error;
> }
>
> Whichever you prefer is fine with me.
I will go with the change you suggested and
I'll send v4 tomorrow then.
> Thanks.
>
Thank you,
Oleksandr
^ permalink raw reply
* Re: [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer
From: Juergen Gross @ 2018-05-17 5:42 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Konrad Rzeszutek Wilk
Cc: xen-devel, dmitry.torokhov, jandryuk, Oleksandr Andrushchenko,
linux-input
In-Reply-To: <66fe661f-8d1a-aefe-de50-02f37f756d94@gmail.com>
On 17/05/18 07:29, Oleksandr Andrushchenko wrote:
> On 05/17/2018 07:28 AM, Juergen Gross wrote:
>> On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
>>> On 05/11/2018 06:15 PM, Juergen Gross wrote:
>>>> On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko
>>>>>> wrote:
>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>
>>>>>>> Add missing string constants for {feature|request}-raw-pointer
>>>>>>> to align with the rest of the interface file.
>>>>>>>
>>>>>>> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and
>>>>>>> "request-raw-pointer")
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>>>>> <oleksandr_andrushchenko@epam.com>
>>>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Juergen, you OK with an release-ack?
>>>> Yes:
>>>>
>>>> Release-acked-by: Juergen Gross <jgross@suse.com>
>>> Is this ack for both patches or this one only?
>> It was meant for patch 1 only.
> Clear
>>> I see Konrad has applied this patch, but
>>> "[Xen-devel][PATCH v4 2/2] xen/kbdif: Add features to disable keyboard
>>> and pointer"
>>> is still floating.
>> In principle I'm fine with taking it for 4.11, but I think at this stage
>> of the release there should be a formal request to include it.
> ...and the request should come from Konrad?
> Or who else may request that?
Normally the sender of the patch would make this request below the ---
of the commit message, e.g.:
---
This patch should go into 4.11 as it is needed for a related Linux
kernel patch and the risk is next to zero for Xen due to only adding
some macros not in use on Xen side.
The request can be made by anyone, of course, e.g. by replying to the
patch mail and including the release manager as a recipient.
> And, as I have r-b's from Konrad for both patches,
> will it be ok if we apply the corresponding changes to the
> kernel now, so my change to xen-kbdfront is unblocked?
No, please don't do that.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer
From: Oleksandr Andrushchenko @ 2018-05-17 5:45 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr_Andrushchenko@epam.com, dmitry.torokhov, jandryuk,
linux-input, xen-devel
In-Reply-To: <20180502144919.16780-2-andr2000@gmail.com>
Hi, Juergen!
This patch should go into 4.11 as it is needed for a related Linux
kernel patch and the risk is next to zero for Xen due to only adding
some macros not in use on Xen side.
Could you please release ack this and apply?
Thank you,
Oleksandr
On 05/02/2018 05:49 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> It is now not fully possible to control if and which virtual devices
> are created by the frontend, e.g. keyboard and pointer devices
> are always created and multi-touch device is created if the
> backend advertises multi-touch support. In some cases this
> behavior is not desirable and better control over the frontend's
> configuration is required.
>
> Add new XenStore feature fields, so it is possible to individually
> control set of exposed virtual devices for each guest OS:
> - set feature-disable-keyboard to 1 if no keyboard device needs
> to be created
> - set feature-disable-pointer to 1 if no pointer device needs
> to be created
>
> Keep old behavior by default.
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> xen/include/public/io/kbdif.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index daf4bc2063c9..23d1f70d5210 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -51,6 +51,18 @@
> * corresponding entries in XenStore and puts 1 as the value of the entry.
> * If a feature is not supported then 0 must be set or feature entry omitted.
> *
> + * feature-disable-keyboard
> + * Values: <uint>
> + *
> + * If there is no need to expose a virtual keyboard device by the
> + * frontend then this must be set to 1.
> + *
> + * feature-disable-pointer
> + * Values: <uint>
> + *
> + * If there is no need to expose a virtual pointer device by the
> + * frontend then this must be set to 1.
> + *
> * feature-abs-pointer
> * Values: <uint>
> *
> @@ -177,6 +189,8 @@
>
> #define XENKBD_DRIVER_NAME "vkbd"
>
> +#define XENKBD_FIELD_FEAT_DSBL_KEYBRD "feature-disable-keyboard"
> +#define XENKBD_FIELD_FEAT_DSBL_POINTER "feature-disable-pointer"
> #define XENKBD_FIELD_FEAT_ABS_POINTER "feature-abs-pointer"
> #define XENKBD_FIELD_FEAT_RAW_POINTER "feature-raw-pointer"
> #define XENKBD_FIELD_FEAT_MTOUCH "feature-multi-touch"
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer
From: Oleksandr Andrushchenko @ 2018-05-17 5:47 UTC (permalink / raw)
To: Juergen Gross, Oleksandr_Andrushchenko@epam.com,
Konrad Rzeszutek Wilk
Cc: xen-devel, dmitry.torokhov, jandryuk, linux-input
In-Reply-To: <58830234-a6a1-fba0-e994-34df03f5cdae@suse.com>
On 05/17/2018 08:42 AM, Juergen Gross wrote:
> On 17/05/18 07:29, Oleksandr Andrushchenko wrote:
>> On 05/17/2018 07:28 AM, Juergen Gross wrote:
>>> On 16/05/18 06:59, Oleksandr Andrushchenko wrote:
>>>> On 05/11/2018 06:15 PM, Juergen Gross wrote:
>>>>> On 11/05/18 15:38, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, May 11, 2018 at 09:37:57AM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>>> On Wed, May 02, 2018 at 05:49:18PM +0300, Oleksandr Andrushchenko
>>>>>>> wrote:
>>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>>
>>>>>>>> Add missing string constants for {feature|request}-raw-pointer
>>>>>>>> to align with the rest of the interface file.
>>>>>>>>
>>>>>>>> Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and
>>>>>>>> "request-raw-pointer")
>>>>>>>>
>>>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>>>>>> <oleksandr_andrushchenko@epam.com>
>>>>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>>> Juergen, you OK with an release-ack?
>>>>> Yes:
>>>>>
>>>>> Release-acked-by: Juergen Gross <jgross@suse.com>
>>>> Is this ack for both patches or this one only?
>>> It was meant for patch 1 only.
>> Clear
>>>> I see Konrad has applied this patch, but
>>>> "[Xen-devel][PATCH v4 2/2] xen/kbdif: Add features to disable keyboard
>>>> and pointer"
>>>> is still floating.
>>> In principle I'm fine with taking it for 4.11, but I think at this stage
>>> of the release there should be a formal request to include it.
>> ...and the request should come from Konrad?
>> Or who else may request that?
> Normally the sender of the patch would make this request below the ---
> of the commit message, e.g.:
> ---
> This patch should go into 4.11 as it is needed for a related Linux
> kernel patch and the risk is next to zero for Xen due to only adding
> some macros not in use on Xen side.
>
> The request can be made by anyone, of course, e.g. by replying to the
> patch mail and including the release manager as a recipient.
Great, thank you
>> And, as I have r-b's from Konrad for both patches,
>> will it be ok if we apply the corresponding changes to the
>> kernel now, so my change to xen-kbdfront is unblocked?
> No, please don't do that.
Sure
>
> Juergen
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer
From: Juergen Gross @ 2018-05-17 5:50 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: Oleksandr_Andrushchenko@epam.com, dmitry.torokhov, jandryuk,
linux-input, xen-devel
In-Reply-To: <ac3b57d0-2df0-561d-36d9-f00cd9273185@gmail.com>
On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
> Hi, Juergen!
>
> This patch should go into 4.11 as it is needed for a related Linux
> kernel patch and the risk is next to zero for Xen due to only adding
> some macros not in use on Xen side.
>
> Could you please release ack this
Release-acked-by: Juergen Gross <jgross@suse.com>
> and apply?
This has to be done by a committer, which I'm not.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer
From: Oleksandr Andrushchenko @ 2018-05-17 5:51 UTC (permalink / raw)
To: Juergen Gross, konrad.wilk
Cc: xen-devel, dmitry.torokhov, jandryuk,
Oleksandr_Andrushchenko@epam.com, linux-input
In-Reply-To: <38c3d8b3-a30b-a82a-341f-18b884b992f7@suse.com>
On 05/17/2018 08:50 AM, Juergen Gross wrote:
> On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
>> Hi, Juergen!
>>
>> This patch should go into 4.11 as it is needed for a related Linux
>> kernel patch and the risk is next to zero for Xen due to only adding
>> some macros not in use on Xen side.
>>
>> Could you please release ack this
> Release-acked-by: Juergen Gross <jgross@suse.com>
Thank you
>> and apply?
> This has to be done by a committer, which I'm not.
Konrad, could you please apply?
>
> Juergen
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Jarkko Nikula @ 2018-05-17 7:48 UTC (permalink / raw)
To: Chris Chiu
Cc: Daniel Drake, Jian-Hong Pan, Jiri Kosina, Benjamin Tissoires,
Jani Nikula, Hans de Goede, Dmitry Torokhov, Adrian Salido,
Jason Gerecke, linux-input, Andy Shevchenko, Mika Westerberg,
Wolfram Sang, linux-i2c, Linux Kernel, Linux Upstreaming Team
In-Reply-To: <7728da79-8a7a-b87d-d09c-b36978b3032e@linux.intel.com>
Hi
On 05/15/2018 01:20 PM, Jarkko Nikula wrote:
> On 05/15/2018 06:22 AM, Chris Chiu wrote:
>> What if I change the 120MHz to 180MHz and then make sure that the I2C
>> operates
>> in target FS mode frequency 400kHz via scope? Would there be any side
>> effect?
>> Maybe some other busses frequency could be also affected and causing
>> some other
>> component malfunction?
>>
> Should be safe. It is only clock rate information when registering a
> fixed clock with known rate in intel-lpss.c and i2c-designware uses that
> info when calculating the timing parameters. I.e. it doesn't change any
> internal clocks.
>
> I'm trying to find a contact who can confirm what is the expected rate
> of I2C input clock and is it common to all Cannon Lake HW.
>
I got confirmation that input clock is actually even higher 216 Mhz.
While checking does it cover all of those CNL CNL-LP and CNL-H PCI IDs
may I add your Jian-Hong, Chris and Daniel email addresses to Repored-by
tags in a fix patch?
--
Jarkko
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-17 8:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: mark.rutland, devicetree, robh+dt, kernel, linux-input,
fabio.estevam, shawnguo, linux-arm-kernel
In-Reply-To: <20180516170333.GA21971@dtor-ws>
Hi Dmitry,
On Wednesday, May 16, 2018 07:03 PM, Dmitry Torokhov wrote:
>> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
>> index 5bf63f76ddda..955f085627fa 100644
>> --- a/drivers/input/touchscreen/edt-ft5x06.c
>> +++ b/drivers/input/touchscreen/edt-ft5x06.c
>> @@ -1007,7 +1007,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>> goto err_remove_attrs;
>>
>> edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
>> - device_init_wakeup(&client->dev, 1);
>> + device_init_wakeup(&client->dev,
>> + device_property_read_bool(dev, "wakeup-source"));
>
> I think we should actually drop device_init_wakeup() call. I2C core
> already handles "wakeup-source" property (for OF). The static board
> files can instantiate clients with I2C_CLIENT_WAKE, so that's handled
> too, and I think ACPI has its own notion of annotating wakeup sources.
Ah, right! Thanks, will respin :)
Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox