* 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
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Chris Chiu @ 2018-05-17 9:05 UTC (permalink / raw)
To: Jarkko Nikula
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: <a3ce1af5-7b99-38db-fc51-4d580db1e87e@linux.intel.com>
On Thu, May 17, 2018 at 3:48 PM, Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
> 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
No problem. Thanks
^ permalink raw reply
* [PATCH v2 0/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-17 9:05 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
v1 → v2:
* simply drop device_init_wakeup() as the I2C core does handles
the wakeup-source property already (1/3)
* add a delay after reset deassertion at resume time (2/3)
* no changes in the DTS patch (3/3)
Daniel Mack (3):
input: touchscreen: edt-ft5x06: don't make device a wakeup source by
default
input: touchscreen: edt-ft5x06: assert reset during suspend
ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
.../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 | 27 +++++++++++++++++-----
4 files changed, 26 insertions(+), 6 deletions(-)
--
2.14.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Daniel Mack @ 2018-05-17 9:05 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: <20180517090552.5704-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.
The I2C core automatically reads the "wakeup-source" DT property to
configure a device's wakeup capability, and board supports files can set
I2C_CLIENT_WAKE in the flags.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
drivers/input/touchscreen/edt-ft5x06.c | 1 -
2 files changed, 3 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..e18a2f215500 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1007,7 +1007,6 @@ 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);
dev_dbg(&client->dev,
"EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
--
2.14.3
^ permalink raw reply related
* [PATCH v2 2/3] input: touchscreen: edt-ft5x06: assert reset during suspend
From: Daniel Mack @ 2018-05-17 9:05 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: <20180517090552.5704-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 | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index e18a2f215500..145499022e1c 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -883,6 +883,20 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata)
}
}
+static void edt_ft5x06_reset(struct edt_ft5x06_ts_data *tsdata, bool reset)
+{
+ if (!tsdata->reset_gpio)
+ return;
+
+ if (reset) {
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 1);
+ } else {
+ usleep_range(5000, 6000);
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
+ msleep(300);
+ }
+}
+
static int edt_ft5x06_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -934,11 +948,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
gpiod_set_value_cansleep(tsdata->wake_gpio, 1);
}
- if (tsdata->reset_gpio) {
- usleep_range(5000, 6000);
- gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
- msleep(300);
- }
+ edt_ft5x06_reset(tsdata, false);
input = devm_input_allocate_device(&client->dev);
if (!input) {
@@ -1034,9 +1044,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
+ edt_ft5x06_reset(tsdata, true);
return 0;
}
@@ -1044,9 +1057,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
+ edt_ft5x06_reset(tsdata, false);
return 0;
}
--
2.14.3
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
From: Daniel Mack @ 2018-05-17 9:05 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: <20180517090552.5704-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>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.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
* Re: [PATCH v4] Input: add bu21029 touch driver
From: kbuild test robot @ 2018-05-17 10:03 UTC (permalink / raw)
Cc: kbuild-all, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-input, devicetree, linux-kernel, hs, andy.shevchenko,
Zhu Yi, Mark Jonas
In-Reply-To: <1526477123-18208-1-git-send-email-mark.jonas@de.bosch.com>
Hi Zhu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17-rc5]
[also build test WARNING on next-20180516]
[cannot apply to input/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Mark-Jonas/Input-add-bu21029-touch-driver/20180517-133332
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/bu21029_ts.c:289:13: sparse: cast to restricted __be16
>> drivers/input/touchscreen/bu21029_ts.c:289:13: sparse: cast to restricted __be16
>> drivers/input/touchscreen/bu21029_ts.c:289:13: sparse: cast to restricted __be16
>> drivers/input/touchscreen/bu21029_ts.c:289:13: sparse: cast to restricted __be16
vim +289 drivers/input/touchscreen/bu21029_ts.c
258
259 static int bu21029_start_chip(struct input_dev *dev)
260 {
261 struct bu21029_ts_data *bu21029 = input_get_drvdata(dev);
262 struct i2c_client *i2c = bu21029->client;
263 struct {
264 u8 reg;
265 u8 value;
266 } init_table[] = {
267 {BU21029_CFR0_REG, CFR0_VALUE},
268 {BU21029_CFR1_REG, CFR1_VALUE},
269 {BU21029_CFR2_REG, CFR2_VALUE},
270 {BU21029_CFR3_REG, CFR3_VALUE},
271 {BU21029_LDO_REG, LDO_VALUE}
272 };
273 int error, i;
274 u16 hwid;
275
276 /* take chip out of reset */
277 gpiod_set_value_cansleep(bu21029->reset_gpios, 0);
278 mdelay(START_DELAY_MS);
279
280 error = i2c_smbus_read_i2c_block_data(i2c,
281 BU21029_HWID_REG,
282 2,
283 (u8 *)&hwid);
284 if (error < 0) {
285 dev_err(&i2c->dev, "failed to read HW ID\n");
286 goto out;
287 }
288
> 289 if (be16_to_cpu(hwid) != SUPPORTED_HWID) {
290 dev_err(&i2c->dev, "unsupported HW ID 0x%x\n", hwid);
291 error = -ENODEV;
292 goto out;
293 }
294
295 for (i = 0; i < ARRAY_SIZE(init_table); ++i) {
296 error = i2c_smbus_write_byte_data(i2c,
297 init_table[i].reg,
298 init_table[i].value);
299 if (error < 0) {
300 dev_err(&i2c->dev,
301 "failed to write 0x%x to register 0x%x\n",
302 init_table[i].value,
303 init_table[i].reg);
304 goto out;
305 }
306 }
307
308 error = i2c_smbus_write_byte(i2c, BU21029_AUTOSCAN);
309 if (error < 0) {
310 dev_err(&i2c->dev, "failed to start autoscan\n");
311 goto out;
312 }
313
314 enable_irq(bu21029->client->irq);
315 return 0;
316
317 out:
318 bu21029_stop_chip(dev);
319 return error;
320 }
321
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Boris Ostrovsky @ 2018-05-17 13:08 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Dmitry Torokhov
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan, konrad.wilk,
andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <7cecb5d1-5cd3-b63d-d6eb-d1e2dfba9ca6@gmail.com>
On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
> I will go with the change you suggested and
> I'll send v4 tomorrow then.
Please make sure your changes to kbdif.h are in Xen first. I believe you
submitted a patch there but I don't see it in the staging tree yet.
-boris
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-05-17 13:09 UTC (permalink / raw)
To: Boris Ostrovsky, Dmitry Torokhov, konrad.wilk
Cc: xen-devel, linux-input, linux-kernel, jgross, lyan,
andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <d35b6720-62e3-e9d4-dbe5-a04d75dde0b7@oracle.com>
On 05/17/2018 04:08 PM, Boris Ostrovsky wrote:
> On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
>> I will go with the change you suggested and
>> I'll send v4 tomorrow then.
>
>
> Please make sure your changes to kbdif.h are in Xen first. I believe you
> submitted a patch there but I don't see it in the staging tree yet.
Sure, I already have Release ack for the one which is not
in Xen tree yet, hope Konrad can apply it today,
so tomorrow Xen and Linux are both ok (or by the time
I send v4).
> -boris
Thank you,
Oleksandr
^ permalink raw reply
* Re: [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer
From: Konrad Rzeszutek Wilk @ 2018-05-17 14:09 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: Juergen Gross, Oleksandr_Andrushchenko@epam.com, jandryuk,
dmitry.torokhov, linux-input, xen-devel
In-Reply-To: <55eeea02-e523-f576-ca1c-dac148387800@gmail.com>
On Thu, May 17, 2018 at 08:51:38AM +0300, Oleksandr Andrushchenko wrote:
> 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?
Yes of course.
> >
> > 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: Sometimes unusable i2c-hid devices in 4.17-rcX
From: Benjamin Tissoires @ 2018-05-17 14:28 UTC (permalink / raw)
To: Mario.Limonciello; +Cc: linux-input, linux-kernel
In-Reply-To: <33968d382800467bb71d1733f2f2fd58@ausx13mpc120.AMER.DELL.COM>
Hi Mario,
On Wed, May 16, 2018 at 10:00 PM, <Mario.Limonciello@dell.com> wrote:
> 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?
I am reliably running a v4.17-rc3 with a merge on Jiri's tree on the 9360.
I doubt it's related to the event processing as I am not encountering
those issues.
It *could* be related to the interrupts not being properly raised.
Could you monitor /proc/interrupts and check if the ones associated
with your i2c-hid devices are increasing when you are using them?
Also, does the device emits raw HID events? (you can use hid-recorder
to check on the hidraw nodes.)
Cheers,
Benjamin
>
> #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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Konrad Rzeszutek Wilk @ 2018-05-17 14:29 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: Boris Ostrovsky, Dmitry Torokhov, xen-devel, linux-input,
linux-kernel, jgross, lyan, andrii_chepurnyi,
Oleksandr Andrushchenko
In-Reply-To: <60ed5392-eff6-be1c-f092-bb93184db060@gmail.com>
On Thu, May 17, 2018 at 04:09:04PM +0300, Oleksandr Andrushchenko wrote:
> On 05/17/2018 04:08 PM, Boris Ostrovsky wrote:
> > On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
> > > I will go with the change you suggested and
> > > I'll send v4 tomorrow then.
> >
> >
> > Please make sure your changes to kbdif.h are in Xen first. I believe you
> > submitted a patch there but I don't see it in the staging tree yet.
> Sure, I already have Release ack for the one which is not
> in Xen tree yet, hope Konrad can apply it today,
> so tomorrow Xen and Linux are both ok (or by the time
It is checked in (on the Xen tree).
> I send v4).
> > -boris
> Thank you,
> Oleksandr
^ permalink raw reply
* RE: Sometimes unusable i2c-hid devices in 4.17-rcX
From: Mario.Limonciello @ 2018-05-17 14:44 UTC (permalink / raw)
To: benjamin.tissoires; +Cc: linux-input, linux-kernel
In-Reply-To: <CAN+gG=HXeNCJJjhTbz-4MoZW_0QgO9DOwBP1NBgZ_2Hycm+4qw@mail.gmail.com>
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> Sent: Thursday, May 17, 2018 9:28 AM
> To: Limonciello, Mario
> Cc: linux-input; linux-kernel@vger.kernel.org
> Subject: Re: Sometimes unusable i2c-hid devices in 4.17-rcX
>
> Hi Mario,
>
> On Wed, May 16, 2018 at 10:00 PM, <Mario.Limonciello@dell.com> wrote:
> > 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?
>
> I am reliably running a v4.17-rc3 with a merge on Jiri's tree on the 9360.
>
> I doubt it's related to the event processing as I am not encountering
> those issues.
>
> It *could* be related to the interrupts not being properly raised.
>
> Could you monitor /proc/interrupts and check if the ones associated
> with your i2c-hid devices are increasing when you are using them?
> Also, does the device emits raw HID events? (you can use hid-recorder
> to check on the hidraw nodes.)
I checked both, /proc/interrupts isn't incrementing at all with the DLL077A:01 device.
Hid-recorder is showing output from the raw HID node.
Same thing for the touchscreen, no incrementing for it on the i2c_designware.0 device.
Something notable however;
When in this bad state hid-recorder didn't show /dev/hidraw1 for the touchscreen (which
Happens to be a Wacom touch screen).
It only showed /dev/hidraw0 for the touchpad.
>
> Cheers,
> Benjamin
>
> >
> > #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
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer
From: Oleksandr Andrushchenko @ 2018-05-17 18:41 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Juergen Gross, Oleksandr_Andrushchenko@epam.com, jandryuk,
dmitry.torokhov, linux-input, xen-devel
In-Reply-To: <20180517140957.GA12679@char.us.oracle.com>
On 05/17/2018 05:09 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, May 17, 2018 at 08:51:38AM +0300, Oleksandr Andrushchenko wrote:
>> 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?
> Yes of course.
Thank you
>>> Juergen
>> Thank you,
>> Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH v5] Input: add bu21029 touch driver
From: Mark Jonas @ 2018-05-17 20:06 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 v5:
- use usleep_range() and msleep() instead of atomic delays
- drop #ifdef CONFIG_PM_SLEEP
- annotate HW ID as big endian (sparse check finding)
---
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 | 474 +++++++++++++++++++++
4 files changed, 521 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..5a72671
--- /dev/null
+++ b/drivers/input/touchscreen/bu21029_ts.c
@@ -0,0 +1,474 @@
+// 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_MIN_US 50
+#define STOP_DELAY_MAX_US 1000
+#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);
+ usleep_range(STOP_DELAY_MIN_US, STOP_DELAY_MAX_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;
+ __be16 hwid;
+
+ /* take chip out of reset */
+ gpiod_set_value_cansleep(bu21029->reset_gpios, 0);
+ msleep(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;
+}
+
+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;
+}
+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
* AW: [PATCH v3] Input: add bu21029 touch driver
From: Jonas Mark (BT-FIR/ENG1) @ 2018-05-17 20:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andy Shevchenko, 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: <20180516174357.GE21971@dtor-ws>
Hello Dmitry,
> > > > +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.
Understood and changed.
> > > > +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().
Replaced.
> > > 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.
Done.
Greetings,
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
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Hans de Goede @ 2018-05-18 7:48 UTC (permalink / raw)
To: Jarkko Nikula, Chris Chiu
Cc: Daniel Drake, Jian-Hong Pan, Jiri Kosina, Benjamin Tissoires,
Jani Nikula, Dmitry Torokhov, Adrian Salido, Jason Gerecke,
linux-input, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
linux-i2c, Linux Kernel, Linux Upstreaming Team
In-Reply-To: <a3ce1af5-7b99-38db-fc51-4d580db1e87e@linux.intel.com>
Hi Jarkko, et.al.,
On 17-05-18 09:48, Jarkko Nikula wrote:
> 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?
Could it be the i2c input clock definition in drivers/mfd/intel-lpss-pci.c
is also wrong for Apollo Lake (N3450) ? There are lots of people having
various issues with i2c attached touchpads on Apollo Lake devices, this bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
Is sort of a collection bug for these. Various models laptops, lots of
reporters. Note not sure thie is an i2c-designware issue, but it would
be good to double check the input clock on Apollo Lake.
I've checked the datasheet and the datasheet mentions 133MHz as
"serial input clk" in the lpio_bxt_regs Registers Summary, which is
also part of the LPSS, no clk is mentioned in the "Summary of
DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
Regards,
Hans
^ permalink raw reply
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Andy Shevchenko @ 2018-05-18 8:37 UTC (permalink / raw)
To: Hans de Goede, Jarkko Nikula, Chris Chiu
Cc: Daniel Drake, Jian-Hong Pan, Jiri Kosina, Benjamin Tissoires,
Jani Nikula, Dmitry Torokhov, Adrian Salido, Jason Gerecke,
linux-input, Mika Westerberg, Wolfram Sang, linux-i2c,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <ba99be8e-8e8b-87c1-8607-24ace8a01c64@redhat.com>
On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
> Could it be the i2c input clock definition in drivers/mfd/intel-lpss-
> pci.c
> is also wrong for Apollo Lake (N3450) ? There are lots of people
> having
> various issues with i2c attached touchpads on Apollo Lake devices,
> this bug:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>
> Is sort of a collection bug for these. Various models laptops, lots of
> reporters. Note not sure thie is an i2c-designware issue, but it would
> be good to double check the input clock on Apollo Lake.
>
> I've checked the datasheet and the datasheet mentions 133MHz as
> "serial input clk" in the lpio_bxt_regs Registers Summary, which is
> also part of the LPSS, no clk is mentioned in the "Summary of
> DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
The internal datasheet we have access to mentioned in this case for
Broxton and Cannonlake together. So, your assumption might be quite
close to the truth and the issue is inherited from Broxton.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH] mfd: intel-lpss: Fix Intel Cannon Lake LPSS I2C input clock
From: Jarkko Nikula @ 2018-05-18 8:38 UTC (permalink / raw)
To: linux-kernel
Cc: Lee Jones, Andy Shevchenko, Mika Westerberg, linux-i2c,
linux-input, Jian-Hong Pan, Chris Chiu, Daniel Drake,
Jarkko Nikula, stable
Intel Cannon Lake PCH has much higher 216 MHz input clock to LPSS I2C
than Sunrisepoint which uses 120 MHz. Preliminary information was that
both share the same clock rate but actual silicon implements elevated
rate for better support for 3.4 MHz high-speed I2C.
This incorrect input clock rate results too high I2C bus clock in case
ACPI doesn't provide tuned I2C timing parameters since I2C host
controller driver calculates them from input clock rate.
Fix this by using the correct rate. We still share the same 230 ns SDA
hold time value than Sunrisepoint.
Cc: stable@vger.kernel.org
Fixes: b418bbff36dd ("mfd: intel-lpss: Add Intel Cannonlake PCI IDs")
Reported-by: Jian-Hong Pan <jian-hong@endlessm.com>
Reported-by: Chris Chiu <chiu@endlessm.com>
Reported-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Hi Jian-Hong, Chris and Daniel. Could you test does this fix your
touchpad issue?
---
drivers/mfd/intel-lpss-pci.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index d1c46de89eb4..d9ae983095c5 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -124,6 +124,11 @@ static const struct intel_lpss_platform_info apl_i2c_info = {
.properties = apl_i2c_properties,
};
+static const struct intel_lpss_platform_info cnl_i2c_info = {
+ .clk_rate = 216000000,
+ .properties = spt_i2c_properties,
+};
+
static const struct pci_device_id intel_lpss_pci_ids[] = {
/* BXT A-Step */
{ PCI_VDEVICE(INTEL, 0x0aac), (kernel_ulong_t)&bxt_i2c_info },
@@ -207,13 +212,13 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x9daa), (kernel_ulong_t)&spt_info },
{ PCI_VDEVICE(INTEL, 0x9dab), (kernel_ulong_t)&spt_info },
{ PCI_VDEVICE(INTEL, 0x9dfb), (kernel_ulong_t)&spt_info },
- { PCI_VDEVICE(INTEL, 0x9dc5), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0x9dc6), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dc5), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dc6), (kernel_ulong_t)&cnl_i2c_info },
{ PCI_VDEVICE(INTEL, 0x9dc7), (kernel_ulong_t)&spt_uart_info },
- { PCI_VDEVICE(INTEL, 0x9de8), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0x9de9), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0x9dea), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0x9deb), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9de8), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9de9), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9dea), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9deb), (kernel_ulong_t)&cnl_i2c_info },
/* SPT-H */
{ PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)&spt_uart_info },
{ PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)&spt_uart_info },
@@ -240,10 +245,10 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0xa32b), (kernel_ulong_t)&spt_info },
{ PCI_VDEVICE(INTEL, 0xa37b), (kernel_ulong_t)&spt_info },
{ PCI_VDEVICE(INTEL, 0xa347), (kernel_ulong_t)&spt_uart_info },
- { PCI_VDEVICE(INTEL, 0xa368), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0xa369), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0xa36a), (kernel_ulong_t)&spt_i2c_info },
- { PCI_VDEVICE(INTEL, 0xa36b), (kernel_ulong_t)&spt_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa368), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa369), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa36a), (kernel_ulong_t)&cnl_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa36b), (kernel_ulong_t)&cnl_i2c_info },
{ }
};
MODULE_DEVICE_TABLE(pci, intel_lpss_pci_ids);
--
2.17.0
^ permalink raw reply related
* [PATCH v4 1/2] xen/kbdif: Sync up with the canonical definition in Xen
From: Oleksandr Andrushchenko @ 2018-05-18 9:59 UTC (permalink / raw)
To: xen-devel, linux-input, linux-kernel, dmitry.torokhov, jgross,
lyan, boris.ostrovsky
Cc: konrad.wilk, andr2000, andrii_chepurnyi, Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
This is the sync up with the canonical definition of the keyboard
protocol in Xen:
1. Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.
2. 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
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
include/xen/interface/io/kbdif.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/include/xen/interface/io/kbdif.h b/include/xen/interface/io/kbdif.h
index 2a9510ade701..808ef7d02a65 100644
--- a/include/xen/interface/io/kbdif.h
+++ b/include/xen/interface/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>
*
@@ -63,6 +75,13 @@
* Backends, which support reporting of multi-touch events
* should set this to 1.
*
+ * feature-raw-pointer
+ * Values: <uint>
+ *
+ * Backends, which support reporting raw (unscaled) absolute coordinates
+ * for pointer devices should set this to 1. Raw (unscaled) values have
+ * a range of [0, 0x7fff].
+ *
*------------------------- Pointer Device Parameters ------------------------
*
* width
@@ -98,6 +117,13 @@
*
* Request backend to report multi-touch events.
*
+ * request-raw-pointer
+ * Values: <uint>
+ *
+ * Request backend to report raw unscaled absolute pointer coordinates.
+ * This option is only valid if request-abs-pointer is also set.
+ * Raw unscaled coordinates have the range [0, 0x7fff]
+ *
*----------------------- Request Transport Parameters -----------------------
*
* event-channel
@@ -163,9 +189,13 @@
#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"
#define XENKBD_FIELD_REQ_ABS_POINTER "request-abs-pointer"
+#define XENKBD_FIELD_REQ_RAW_POINTER "request-raw-pointer"
#define XENKBD_FIELD_REQ_MTOUCH "request-multi-touch"
#define XENKBD_FIELD_RING_GREF "page-gref"
#define XENKBD_FIELD_EVT_CHANNEL "event-channel"
--
2.17.0
^ permalink raw reply related
* [PATCH v4 2/2] Input: xen-kbdfront - allow better run-time configuration
From: Oleksandr Andrushchenko @ 2018-05-18 9:59 UTC (permalink / raw)
To: xen-devel, linux-input, linux-kernel, dmitry.torokhov, jgross,
lyan, boris.ostrovsky
Cc: konrad.wilk, andr2000, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <20180518095935.26740-1-andr2000@gmail.com>
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed to Android then the latter won't
automatically show on-screen keyboard as it expects that a
physical keyboard device can be used for typing.
Utilize keyboard and pointer device XenStore feature fields to
configure which virtual devices are created:
- 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>
Suggested-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
Tested-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
---
Changes since v3:
- do not connect backend if all virtual devices are disabled (Dmitry)
Changes since v2:
- based on XenStore kbdif features to control which devices are
exposed instead of module parameters.
drivers/input/misc/xen-kbdfront.c | 177 ++++++++++++++++++------------
1 file changed, 106 insertions(+), 71 deletions(-)
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index d91f3b1c5375..0e8926c75559 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -63,6 +63,9 @@ static void xenkbd_disconnect_backend(struct xenkbd_info *);
static void xenkbd_handle_motion_event(struct xenkbd_info *info,
struct xenkbd_motion *motion)
{
+ if (unlikely(!info->ptr))
+ return;
+
input_report_rel(info->ptr, REL_X, motion->rel_x);
input_report_rel(info->ptr, REL_Y, motion->rel_y);
if (motion->rel_z)
@@ -73,6 +76,9 @@ static void xenkbd_handle_motion_event(struct xenkbd_info *info,
static void xenkbd_handle_position_event(struct xenkbd_info *info,
struct xenkbd_position *pos)
{
+ if (unlikely(!info->ptr))
+ return;
+
input_report_abs(info->ptr, ABS_X, pos->abs_x);
input_report_abs(info->ptr, ABS_Y, pos->abs_y);
if (pos->rel_z)
@@ -97,6 +103,9 @@ static void xenkbd_handle_key_event(struct xenkbd_info *info,
return;
}
+ if (unlikely(!dev))
+ return;
+
input_event(dev, EV_KEY, key->keycode, value);
input_sync(dev);
}
@@ -192,7 +201,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
int ret, i;
- unsigned int abs, touch;
+ bool with_mtouch, with_kbd, with_ptr;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
@@ -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);
+
+ with_ptr = !xenbus_read_unsigned(dev->nodename,
+ XENKBD_FIELD_FEAT_DSBL_POINTER, 0);
- touch = xenbus_read_unsigned(dev->nodename,
- XENKBD_FIELD_FEAT_MTOUCH, 0);
- if (touch) {
+ /* 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;
}
}
/* keyboard */
- kbd = input_allocate_device();
- if (!kbd)
- goto error_nomem;
- kbd->name = "Xen Virtual Keyboard";
- kbd->phys = info->phys;
- kbd->id.bustype = BUS_PCI;
- kbd->id.vendor = 0x5853;
- kbd->id.product = 0xffff;
-
- __set_bit(EV_KEY, kbd->evbit);
- for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
- __set_bit(i, kbd->keybit);
- for (i = KEY_OK; i < KEY_MAX; i++)
- __set_bit(i, kbd->keybit);
-
- ret = input_register_device(kbd);
- if (ret) {
- input_free_device(kbd);
- xenbus_dev_fatal(dev, ret, "input_register_device(kbd)");
- goto error;
+ if (with_kbd) {
+ kbd = input_allocate_device();
+ if (!kbd)
+ goto error_nomem;
+ kbd->name = "Xen Virtual Keyboard";
+ kbd->phys = info->phys;
+ kbd->id.bustype = BUS_PCI;
+ kbd->id.vendor = 0x5853;
+ kbd->id.product = 0xffff;
+
+ __set_bit(EV_KEY, kbd->evbit);
+ for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
+ __set_bit(i, kbd->keybit);
+ for (i = KEY_OK; i < KEY_MAX; i++)
+ __set_bit(i, kbd->keybit);
+
+ ret = input_register_device(kbd);
+ if (ret) {
+ input_free_device(kbd);
+ xenbus_dev_fatal(dev, ret,
+ "input_register_device(kbd)");
+ goto error;
+ }
+ info->kbd = kbd;
}
- info->kbd = kbd;
/* pointing device */
- ptr = input_allocate_device();
- if (!ptr)
- goto error_nomem;
- ptr->name = "Xen Virtual Pointer";
- ptr->phys = info->phys;
- ptr->id.bustype = BUS_PCI;
- ptr->id.vendor = 0x5853;
- ptr->id.product = 0xfffe;
-
- if (abs) {
- __set_bit(EV_ABS, ptr->evbit);
- input_set_abs_params(ptr, ABS_X, 0, ptr_size[KPARAM_X], 0, 0);
- input_set_abs_params(ptr, ABS_Y, 0, ptr_size[KPARAM_Y], 0, 0);
- } else {
- input_set_capability(ptr, EV_REL, REL_X);
- input_set_capability(ptr, EV_REL, REL_Y);
- }
- input_set_capability(ptr, EV_REL, REL_WHEEL);
+ if (with_ptr) {
+ unsigned int abs;
+
+ /* 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;
+ }
+ }
- __set_bit(EV_KEY, ptr->evbit);
- for (i = BTN_LEFT; i <= BTN_TASK; i++)
- __set_bit(i, ptr->keybit);
+ ptr = input_allocate_device();
+ if (!ptr)
+ goto error_nomem;
+ ptr->name = "Xen Virtual Pointer";
+ ptr->phys = info->phys;
+ ptr->id.bustype = BUS_PCI;
+ ptr->id.vendor = 0x5853;
+ ptr->id.product = 0xfffe;
+
+ if (abs) {
+ __set_bit(EV_ABS, ptr->evbit);
+ input_set_abs_params(ptr, ABS_X, 0,
+ ptr_size[KPARAM_X], 0, 0);
+ input_set_abs_params(ptr, ABS_Y, 0,
+ ptr_size[KPARAM_Y], 0, 0);
+ } else {
+ input_set_capability(ptr, EV_REL, REL_X);
+ input_set_capability(ptr, EV_REL, REL_Y);
+ }
+ input_set_capability(ptr, EV_REL, REL_WHEEL);
- ret = input_register_device(ptr);
- if (ret) {
- input_free_device(ptr);
- xenbus_dev_fatal(dev, ret, "input_register_device(ptr)");
- goto error;
+ __set_bit(EV_KEY, ptr->evbit);
+ for (i = BTN_LEFT; i <= BTN_TASK; i++)
+ __set_bit(i, ptr->keybit);
+
+ ret = input_register_device(ptr);
+ if (ret) {
+ input_free_device(ptr);
+ xenbus_dev_fatal(dev, ret,
+ "input_register_device(ptr)");
+ goto error;
+ }
+ info->ptr = ptr;
}
- info->ptr = ptr;
/* multi-touch device */
- if (touch) {
+ if (with_mtouch) {
int num_cont, width, height;
mtouch = input_allocate_device();
@@ -346,6 +376,11 @@ static int xenkbd_probe(struct xenbus_device *dev,
info->mtouch = mtouch;
}
+ if (!(with_kbd | with_ptr | with_mtouch)) {
+ ret = -ENXIO;
+ goto error;
+ }
+
ret = xenkbd_connect_backend(dev, info);
if (ret < 0)
goto error;
--
2.17.0
^ permalink raw reply related
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Andy Shevchenko @ 2018-05-18 10:20 UTC (permalink / raw)
To: Hans de Goede, Jarkko Nikula, Chris Chiu
Cc: Daniel Drake, Jian-Hong Pan, Jiri Kosina, Benjamin Tissoires,
Jani Nikula, Dmitry Torokhov, Adrian Salido, Jason Gerecke,
linux-input, Mika Westerberg, Wolfram Sang, linux-i2c,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <822d5f47cad46ca308d511f7f24cdbc5f4af38b9.camel@linux.intel.com>
On Fri, 2018-05-18 at 11:37 +0300, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
>
>
> > Could it be the i2c input clock definition in drivers/mfd/intel-
> > lpss-
> > pci.c
> > is also wrong for Apollo Lake (N3450) ? There are lots of people
> > having
> > various issues with i2c attached touchpads on Apollo Lake devices,
> > this bug:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
> >
> > Is sort of a collection bug for these. Various models laptops, lots
> > of
> > reporters. Note not sure thie is an i2c-designware issue, but it
> > would
> > be good to double check the input clock on Apollo Lake.
> >
> > I've checked the datasheet and the datasheet mentions 133MHz as
> > "serial input clk" in the lpio_bxt_regs Registers Summary, which is
> > also part of the LPSS, no clk is mentioned in the "Summary of
> > DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
>
> The internal datasheet we have access to mentioned in this case for
> Broxton and Cannonlake together. So, your assumption might be quite
> close to the truth and the issue is inherited from Broxton.
>
Hans, can your reporters try the following patch? Depending on the
result I may send it out ASAP.
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -120,7 +120,7 @@ static struct property_entry apl_i2c_properties[] =
{
};
static const struct intel_lpss_platform_info apl_i2c_info = {
- .clk_rate = 133000000,
+ .clk_rate = 216000000,
.properties = apl_i2c_properties,
};
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] mfd: intel-lpss: Fix Intel Cannon Lake LPSS I2C input clock
From: Mika Westerberg @ 2018-05-18 10:46 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-kernel, Lee Jones, Andy Shevchenko, linux-i2c, linux-input,
Jian-Hong Pan, Chris Chiu, Daniel Drake, stable
In-Reply-To: <20180518083827.20626-1-jarkko.nikula@linux.intel.com>
On Fri, May 18, 2018 at 11:38:27AM +0300, Jarkko Nikula wrote:
> Intel Cannon Lake PCH has much higher 216 MHz input clock to LPSS I2C
> than Sunrisepoint which uses 120 MHz. Preliminary information was that
> both share the same clock rate but actual silicon implements elevated
> rate for better support for 3.4 MHz high-speed I2C.
>
> This incorrect input clock rate results too high I2C bus clock in case
> ACPI doesn't provide tuned I2C timing parameters since I2C host
> controller driver calculates them from input clock rate.
>
> Fix this by using the correct rate. We still share the same 230 ns SDA
> hold time value than Sunrisepoint.
>
> Cc: stable@vger.kernel.org
> Fixes: b418bbff36dd ("mfd: intel-lpss: Add Intel Cannonlake PCI IDs")
> Reported-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Reported-by: Chris Chiu <chiu@endlessm.com>
> Reported-by: Daniel Drake <drake@endlessm.com>
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD
From: Jarkko Nikula @ 2018-05-18 10:58 UTC (permalink / raw)
To: Andy Shevchenko, Hans de Goede, Chris Chiu
Cc: Daniel Drake, Jian-Hong Pan, Jiri Kosina, Benjamin Tissoires,
Jani Nikula, Dmitry Torokhov, Adrian Salido, Jason Gerecke,
linux-input, Mika Westerberg, Wolfram Sang, linux-i2c,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <cabb42db7aec59f0b795a16809b0ccfaeddb2679.camel@linux.intel.com>
On 05/18/2018 01:20 PM, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 11:37 +0300, Andy Shevchenko wrote:
>> On Fri, 2018-05-18 at 09:48 +0200, Hans de Goede wrote:
>>
>>
>>> Could it be the i2c input clock definition in drivers/mfd/intel-
>>> lpss-
>>> pci.c
>>> is also wrong for Apollo Lake (N3450) ? There are lots of people
>>> having
>>> various issues with i2c attached touchpads on Apollo Lake devices,
>>> this bug:
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244
>>>
>>> Is sort of a collection bug for these. Various models laptops, lots
>>> of
>>> reporters. Note not sure thie is an i2c-designware issue, but it
>>> would
>>> be good to double check the input clock on Apollo Lake.
>>>
>>> I've checked the datasheet and the datasheet mentions 133MHz as
>>> "serial input clk" in the lpio_bxt_regs Registers Summary, which is
>>> also part of the LPSS, no clk is mentioned in the "Summary of
>>> DW_apb_i2c_mem_map_DW_apb_i2c_addr_block1 Registers".
>>
>> The internal datasheet we have access to mentioned in this case for
>> Broxton and Cannonlake together. So, your assumption might be quite
>> close to the truth and the issue is inherited from Broxton.
>>
>
Nope. The specification I have mention the I2C input clock in Broxton is
fixed 133 MHz but in Cannon Lake it is derived through non-SW visible
divider.
> Hans, can your reporters try the following patch? Depending on the
> result I may send it out ASAP.
>
> --- a/drivers/mfd/intel-lpss-pci.c
> +++ b/drivers/mfd/intel-lpss-pci.c
> @@ -120,7 +120,7 @@ static struct property_entry apl_i2c_properties[] =
> {
> };
>
> static const struct intel_lpss_platform_info apl_i2c_info = {
> - .clk_rate = 133000000,
> + .clk_rate = 216000000,
> .properties = apl_i2c_properties,
> };
>
Nack. The Apollo Lake HW here shows expected I2C bus clock on
oscilloscope so it is indeed clocked at 133 MHz.
--
Jarkko
^ permalink raw reply
* Re: [PATCH v4 1/2] xen/kbdif: Sync up with the canonical definition in Xen
From: Juergen Gross @ 2018-05-18 11:17 UTC (permalink / raw)
To: Oleksandr Andrushchenko, xen-devel, linux-input, linux-kernel,
dmitry.torokhov, lyan, boris.ostrovsky
Cc: konrad.wilk, andrii_chepurnyi, Oleksandr Andrushchenko
In-Reply-To: <20180518095935.26740-1-andr2000@gmail.com>
On 18/05/18 11:59, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> This is the sync up with the canonical definition of the keyboard
> protocol in Xen:
> 1. Add missing string constants for {feature|request}-raw-pointer
> to align with the rest of the interface file.
>
> 2. 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
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
^ 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