* [PATCH] input synaptics-rmi4: Trivial F11 tidy up
From: Christopher Heiny @ 2014-02-25 22:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Linus Walleij
Delete an unused symbol and update copyright date.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
--
drivers/input/rmi4/rmi_f11.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 2aa7d17..9cc1406 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -7,8 +7,6 @@
* the Free Software Foundation.
*/
-#define FUNCTION_DATA f11_data
-
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/device.h>
^ permalink raw reply related
* STAKEHOLDER NEEDED!!!
From: Yung kyu kim @ 2014-02-25 17:14 UTC (permalink / raw)
Hello,
The Project is about the exportation of 100,000 barrels of Light Crude
Oil daily out from Iraq to Turkey through my client's company in Iraq
at the rate of $92.00 per barrel. This amount to $9,200,000 daily. I ask
for your support as a foreigner to handle this business project with my
client and you are not expected to invest in Iraq
If yes, let me know and we will discuss this project proper.
Kim.
Contact My Private Email : 2784295239@qq.com
^ permalink raw reply
* Re: [PATCH] i8042: Don't print an error message just because there's no chip
From: Josh Boyer @ 2014-02-25 16:06 UTC (permalink / raw)
To: Adam Jackson; +Cc: linux-input, Linux-Kernel@Vger. Kernel. Org, Peter Jones
In-Reply-To: <1393343227-13092-1-git-send-email-ajax@redhat.com>
On Tue, Feb 25, 2014 at 10:47 AM, Adam Jackson <ajax@redhat.com> wrote:
> From: Peter Jones <pjones@redhat.com>
>
> Some systems, such as EFI-based Apple systems, won't necessarily have an
> i8042 to initialize. We shouldn't be printing an error message in this
> case, since not detecting the chip is the correct behavior.
>
> v2: Downgrade to pr_notice instead of pr_err.
>
> Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Josh Boyer <jwboyer@fedoraproject.org>
> ---
> drivers/input/serio/i8042.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index 020053f..05c6285 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -855,7 +855,7 @@ static int __init i8042_check_aux(void)
> static int i8042_controller_check(void)
> {
> if (i8042_flush()) {
> - pr_err("No controller found\n");
> + pr_notice("No controller found\n");
> return -ENODEV;
> }
>
^ permalink raw reply
* [PATCH] i8042: Don't print an error message just because there's no chip
From: Adam Jackson @ 2014-02-25 15:47 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Peter Jones
In-Reply-To: <1222713404-1097-1-git-send-email-ajax@redhat.com>
From: Peter Jones <pjones@redhat.com>
Some systems, such as EFI-based Apple systems, won't necessarily have an
i8042 to initialize. We shouldn't be printing an error message in this
case, since not detecting the chip is the correct behavior.
v2: Downgrade to pr_notice instead of pr_err.
Signed-off-by: Adam Jackson <ajax@redhat.com>
---
drivers/input/serio/i8042.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 020053f..05c6285 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -855,7 +855,7 @@ static int __init i8042_check_aux(void)
static int i8042_controller_check(void)
{
if (i8042_flush()) {
- pr_err("No controller found\n");
+ pr_notice("No controller found\n");
return -ENODEV;
}
--
1.8.5.3
^ permalink raw reply related
* Re: Mixed HID descriptors
From: Benjamin Tissoires @ 2014-02-25 14:10 UTC (permalink / raw)
To: David Herrmann
Cc: Nuno Santos, open list:HID CORE LAYER, Jiri Kosina,
Henrik Rydberg
In-Reply-To: <CANq1E4TvqF0cXDF8U6ofg-E81O77v3fxN1JC8=gJZzSUBCjRmQ@mail.gmail.com>
On Sat, Feb 22, 2014 at 12:04 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> CC Jiri, Benjamin and Henrik
>
> On Thu, Feb 20, 2014 at 12:12 PM, Nuno Santos <nsantos@displax.com> wrote:
>> Hi,
>>
>> We are developing an HID multitouch device and we want to make it fully
>> compatible with Linux and Windows.
>>
>> The device descriptor describes a mouse, keyboard and multitouch digitizer
>> as well as a set of features. When we have mouse or keyboard descriptor
>> along the touch device I can no longer get or set features. It gives me a
>> timeout error:
>>
>> ioctl (GFEATURE): Connection timed out
>>
>> This only happens in Linux.
>>
>> I would like to know if this is normal, or if there is anyway of getting
>> more information about the parsing itself in order to understand the
>> problem.
The only reason I can think of is that the driver at init used to call
GET_REPORT on all the input reports, and this is known to be broken on
many devices.
I added in v3.12 a quirk which is default for win 8 certified
multitouch devices: HID_QUIRK_NO_INIT_INPUT_REPORTS.
If you force your device to use this quirk, the behavior at connect
should be the same across all platforms, and hopefully, you will not
encounter this error anymore.
If you are running an older kernel, you can try using
HID_QUIRK_NO_INIT_REPORTS, but that means that the features will not
be called at plug (it all depend if you need to access the values of
these features at plug or not).
Cheers,
Benjamin
>>
>> Below is the device report descriptor
>
> I don't have much time to test it myself, but you can get a lot of
> debug information via debugfs. Most distros enable it by default. Try
> looking into /sys/kernel/debug/hid/<dev>/
> These debugfs files contain runtime information about HID internals.
>
> Thanks
> David
>
>> __ALIGN_BEGIN
>> static uint8_t HID_ReportDesc[]
>> __ALIGN_END =
>> {
>> #if 0 // IS MESSING HID ON LINUX
>> 0x05, 0x01, // Usage Page (Generic Desktop)
>> 0x09, 0x06, // Usage (Keyboard)
>> 0xA1, 0x01, // Collection (Application)
>> 0x85, REPORTID_KEYBOARD, // REPORT_ID (Mouse)
>> 0x05, 0x07, // Usage page (Key Codes)
>> 0x19, 0xE0, // Usage minimum (224)
>> 0x29, 0xE7, // Usage maximum (231)
>> 0x15, 0x00, // Logical minimum (0)
>> 0x25, 0x01, // Logical maximum (1)
>> 0x75, 0x01, // Report size (1)
>> 0x95, 0x08, // Report count (8)
>> 0x81, 0x02, // Input (data, variable,
>> absolute)
>> 0x95, 0x01, // Report count (1)
>> 0x75, 0x08, // Report size (8)
>> 0x81, 0x01, // Input (constant)
>> 0x95, 0x06, // Report count (6)
>> 0x75, 0x08, // Report size (8)
>> 0x15, 0x00, // Logical minimum (0)
>> 0x25, 0x65, // Logical maximum (101)
>> 0x05, 0x07, // Usage page (key codes)
>> 0x19, 0x00, // Usage minimum (0)
>> 0x29, 0x65, // Usage maximum (101)
>> 0x81, 0x00, // Input (data, array)
>> 0xC0,
>> #endif
>>
>> #if 0 // IS MESSING HID ON LINUX
>> 0x05, 0x01, // USAGE_PAGE (Generic Desktop)
>> 0x09, 0x01, // USAGE (Pointer)
>> 0xa1, 0x01, // COLLECTION (Application)
>> 0x85, REPORTID_MOUSE, // REPORT_ID (Mouse)
>> 0x09, 0x01, // USAGE (Pointer)
>> 0xa1, 0x00, // COLLECTION (Physical)
>> 0x05, 0x09, // USAGE_PAGE (Buttons)
>> 0x09, 0x01, // USAGE (Button 1)
>> 0x95, 0x01, // REPORT_COUNT (1)
>> 0x75, 0x01, // REPORT_SIZE (1)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x25, 0x01, // LOGICAL_MAXIMUM (1)
>> 0x81, 0x02, // INPUT (Data,Var,Abs)
>> 0x95, 0x07, // REPORT_COUNT (7)
>> 0x75, 0x01, // REPORT_SIZE (1)
>> 0x81, 0x03, // INPUT (Const,Var,Abs)
>> 0x95, 0x08, // REPORT_COUNT (8)
>> 0x75, 0x01, // REPORT_SIZE (1)
>> 0x81, 0x03, // INPUT (Const,Var,Abs)
>> 0x05, 0x01, // USAGE_PAGE (Generic Desktop)
>> 0x09, 0x30, // USAGE (X)
>> 0x09, 0x31, // USAGE (Y)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x26, 0xff, 0x7f, // LOGICAL_MAXIMUM (32767)
>> 0x35, 0x00, // PHYSICAL_MINIMUM (0)
>> 0x46, 0x00, 0x00, // PHYSICAL_MAXIMUM (0)
>> 0x95, 0x02, // REPORT_COUNT (2)
>> 0x75, 0x10, // REPORT_SIZE (16)
>> 0x81, 0x02, // INPUT (Data,Var,Abs)
>> 0xc0, // END_COLLECTION
>> 0xa1, 0x02, // COLLECTION (Logical)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)
>> 0x09, 0x01, // USAGE (Pointer)
>> 0x95, 0x39, // REPORT_COUNT (57)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0x81, 0x01, // INPUT (Data,Var,Abs)
>> 0xc0, // END_COLLECTION
>> 0xc0, // END_COLLECTION
>> #endif
>>
>> #if 1
>> 0x05, 0x0d, // USAGE_PAGE (Digitizers)
>> 0x09, 0x0E, // USAGE (Configuration)
>> 0xa1, 0x01, // COLLECTION (Application)
>> 0x85, REPORTID_MODE, // REPORT_ID (Feature)
>> 0x09, 0x23, // USAGE (Device Settings)
>> 0xa1, 0x02, // COLLECTION (logical)
>> 0x09, 0x52, // USAGE (Device Mode)
>> 0x09, 0x53, // USAGE (Device Index)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x25, 0x28, // LOGICAL_MAXIMUM (40)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0x95, 0x02, // REPORT_COUNT (2)
>> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
>> 0xc0, // END_COLLECTION
>> 0xc0, // END_COLLECTION
>>
>> 0x09, 0x04, // USAGE (Touch Screen)
>> 0xa1, 0x01, // COLLECTION (Application)
>> 0x85, REPORTID_TOUCH, // REPORT_ID (Touch)
>> 0x09, 0x22, // USAGE (Finger)
>>
>> 0x05, 0x0d, /* USAGE_PAGE (Digitizers)
>> */
>> 0xa1, 0x02, /* COLLECTION (Logical)
>> */
>> 0x09, 0x42, /* USAGE (Tip Switch)
>> */
>> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
>> */
>> 0x25, 0x01, /* LOGICAL_MAXIMUM (1)
>> */
>> 0x75, 0x01, /* REPORT_SIZE (1)
>> */
>> 0x95, 0x01, /* REPORT_COUNT (1)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0x09, 0x32, /* USAGE (In Range)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0x09, 0x47, /* USAGE (Confidence)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0x95, 0x05, /* REPORT_COUNT (5)
>> */
>> 0x81, 0x03, /* INPUT (Cnst,Ary,Abs)
>> */
>> 0x09, 0x51, /* USAGE (Contact Identifier)
>> */
>> 0x75, 0x08, /* REPORT_SIZE (8)
>> */
>> 0x95, 0x01, /* REPORT_COUNT (1)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0xa1, 0x00, /* COLLECTION (Physical)
>> */
>> 0x05, 0x01, /* USAGE_PAGE (Generic
>> Desktop) */
>> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
>> */
>> 0x26, 0x3A, 0x20, /* LOGICAL_MAXIMUM (8200)
>> */
>> 0x75, 0x10, /* REPORT_SIZE (16)
>> */
>> 0x09, 0x30, /* USAGE (X)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
>> */
>> 0x26, 0x5C, 0x12, /* LOGICAL_MAXIMUM (4700)
>> */
>> 0x09, 0x31, /* USAGE (Y)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0x05, 0x0d, /* USAGE_PAGE (Digitizers)
>> */
>> 0x09, 0x30, /* USAGE (X)
>> */
>> 0x75, 0x10, /* REPORT_SIZE (16)
>> */
>> 0x95, 0x01, /* REPORT_COUNT (1)
>> */
>> 0x81, 0x02, /* INPUT (Data,Var,Abs)
>> */
>> 0xc0, /* END_COLLECTION
>> */
>> 0xc0, /* END_COLLECTION
>> */
>>
>> 0x05, 0x0d, // USAGE_PAGE (Digitizers)
>> 0x09, 0x54, // USAGE (Actual count)
>> 0x15, 0x00, // LOGICAL_MAXIMUM (0)
>> 0x25, 0x14, // LOGICAL_MAXIMUM (20)
>> 0x95, 0x01, // REPORT_COUNT (1)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0x81, 0x02, // INPUT (Data,Var,Abs)
>>
>> 0x85, REPORTID_MAX_COUNT, // REPORT_ID (Feature)
>> 0x09, 0x55, // USAGE(Maximum Count)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x25, 0x14, // LOGICAL_MAXIMUM (20)
>> 0x95, 0x01, // REPORT_COUNT (1)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
>> 0xc0, // END_COLLECTION
>> #endif
>>
>> #if 1
>> 0x09, 0x00, // USAGE (Undefined)
>> 0xa1, 0x01, // COLLECTION (Application)
>> 0x85, REPORTID_ENABLE, // REPORT_ID (Feature)
>> 0x09, 0x00, // USAGE(Undefined)
>> 0x95, 0x01, // REPORT_COUNT (1)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
>> 0x85, REPORTID_GAIN, // REPORT_ID (Feature)
>> 0x09, 0x00, // USAGE(Undefined)
>> 0x15, 0x00, // LOGICAL_MINIMUM (0)
>> 0x25, 0x07, // LOGICAL_MAXIMUM (7)
>> 0x95, 0x01, // REPORT_COUNT (1)
>> 0x75, 0x08, // REPORT_SIZE (8)
>> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
>> 0xc0, // END_COLLECTION
>> #endif
>> };
>>
>> With my best regards,
>>
>> Nuno Santos
>> www.displax.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Oliver Neukum @ 2014-02-25 13:51 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: linux-usb, linux-input, Linux Kernel, Dmitry Torokhov
In-Reply-To: <CAMVG2ss9nA4zcOT3c47EwEMrR7Z_gAQU-HTYGjdWcdYzihSnbg@mail.gmail.com>
On Mon, 2014-02-17 at 21:23 +0800, Daniel J Blueman wrote:
> Across 5+ years of kernels, I've been seeing occasional (1-2 times per
> day) key-stuck issues where eg a fn+delete combo repeats delete until
> I press delete again. I've seen this happen with fn+ctrl+left, leaving
> left held and likewise with right.
I saw something like this during the development of runtime PM
for HID. It turns out that keyboards don't assert remote wakeup
upon key release.
Just to rule this out can you deactivate runtime PM and recompile
to switch of LPM?
Regards
Oliver
^ permalink raw reply
* [PATCH] input: sirfsoc-onkey - set the capability of reporting KEY_POWER
From: Barry Song @ 2014-02-25 13:36 UTC (permalink / raw)
To: dmitry.torokhov, linux-input; +Cc: workgroup.linux, Xianglong Du, Barry Song
From: Xianglong Du <Xianglong.Du@csr.com>
commit a1a7521064428fc1cf8 moved to report EV_KEY event(KEY_POWER) instead of
reporting EV_PWR event(KEY_SUSPEND), but it didn't enable the capability, so
the KEY_POWER will not be reported to userspace by input core. this patch fixes
the issue.
Signed-off-by: Xianglong Du <Xianglong.Du@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
drivers/input/misc/sirfsoc-onkey.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/misc/sirfsoc-onkey.c b/drivers/input/misc/sirfsoc-onkey.c
index 4d66c72..e4104f9 100644
--- a/drivers/input/misc/sirfsoc-onkey.c
+++ b/drivers/input/misc/sirfsoc-onkey.c
@@ -136,6 +136,7 @@ static int sirfsoc_pwrc_probe(struct platform_device *pdev)
pwrcdrv->input->name = "sirfsoc pwrckey";
pwrcdrv->input->phys = "pwrc/input0";
pwrcdrv->input->evbit[0] = BIT_MASK(EV_KEY);
+ input_set_capability(pwrcdrv->input, EV_KEY, KEY_POWER);
INIT_DELAYED_WORK(&pwrcdrv->work, sirfsoc_pwrc_report_event);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] input: touchscreen: imx25 tcq driver
From: Markus Pargmann @ 2014-02-25 11:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: devicetree, linux-input, linux-iio, Samuel Ortiz, Lee Jones,
Jonathan Cameron, linux-arm-kernel, kernel
In-Reply-To: <20140223064406.GC10151@core.coreip.homeip.net>
[-- Attachment #1: Type: text/plain, Size: 24865 bytes --]
Hi,
On Sat, Feb 22, 2014 at 10:44:06PM -0800, Dmitry Torokhov wrote:
> Hi Marjus,
>
> On Thu, Feb 20, 2014 at 05:21:51PM +0100, Markus Pargmann wrote:
> > This is a driver for the imx25 ADC/TSC module. It controls the
> > touchscreen conversion queue and creates a touchscreen input device.
> > The driver currently only supports 4 wire touchscreens. The driver uses
> > a simple conversion queue of precharge, touch detection, X measurement,
> > Y measurement, precharge and another touch detection.
> >
> > This driver uses the regmap from the parent to setup some touch specific
> > settings in the core driver and setup a idle configuration with touch
> > detection.
> >
> > Signed-off-by: Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > .../bindings/input/touchscreen/fsl-mx25-tcq.txt | 29 +
> > drivers/input/touchscreen/Kconfig | 6 +
> > drivers/input/touchscreen/Makefile | 1 +
> > drivers/input/touchscreen/fsl-imx25-tcq.c | 589 +++++++++++++++++++++
> > 4 files changed, 625 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> > create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> > new file mode 100644
> > index 0000000..4214a99
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> > @@ -0,0 +1,29 @@
> > +Freescale mx25 TS conversion queue module
> > +
> > +mx25 touchscreen conversion queue module which controls the ADC unit of the
> > +mx25 for attached touchscreens.
> > +
> > +Required properties:
> > + - compatible: Should be "fsl,imx25-tcq".
> > + - reg: Memory range of the device.
> > + - interrupts: Should be the interrupt number associated with this module within
> > + the tscadc unit (<0>).
> > + - interrupt-parent: Should be a phandle to the tscadc unit.
> > + - fsl,wires: Should be '<4>' or '<5>'
> > +
> > +Optional properties:
> > + - fsl,pen-debounce: Pen debounce time.
> > + - fsl,pen-threshold: Pen-down threshold for the touchscreen.
> > + - fsl,settling-time: Settling time in nanoseconds.
> > +
> > +This device includes two conversion queues which can be added as subnodes.
> > +The first queue is for the touchscreen, the second for general purpose ADC.
> > +
> > +Example:
> > + tsc: tcq@50030400 {
> > + compatible = "fsl,imx25-tcq";
> > + reg = <0x50030400 0x60>;
> > + interrupt-parent = <&tscadc>;
> > + interrupts = <0>;
> > + fsl,wires = <4>;
> > + };
> > diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> > index 07e9e82..d52c055 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -715,6 +715,12 @@ config TOUCHSCREEN_USB_COMPOSITE
> > To compile this driver as a module, choose M here: the
> > module will be called usbtouchscreen.
> >
> > +config TOUCHSCREEN_MX25
> > + tristate "Freescale i.MX25 touchscreen input driver"
> > + depends on MFD_MX25_TSADC
> > + help
> > + Enable support for touchscreen connected to your i.MX25.
> > +
> > config TOUCHSCREEN_MC13783
> > tristate "Freescale MC13783 touchscreen input driver"
> > depends on MFD_MC13XXX
> > diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> > index 62801f2..c891f30 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
> > obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
> > obj-$(CONFIG_TOUCHSCREEN_LPC32XX) += lpc32xx_ts.o
> > obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
> > +obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
> > obj-$(CONFIG_TOUCHSCREEN_MC13783) += mc13783_ts.o
> > obj-$(CONFIG_TOUCHSCREEN_MCS5000) += mcs5000_ts.o
> > obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
> > diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c b/drivers/input/touchscreen/fsl-imx25-tcq.c
> > new file mode 100644
> > index 0000000..436cc8b
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
> > @@ -0,0 +1,589 @@
> > +/*
> > + * Copyright 2014 Markus Pargmann, Pengutronix <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > + * Based on driver from 2011 Juergen Beisert, Pengutronix <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + *
> > + * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
> > + * connected to the imx25 ADC.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/input.h>
> > +#include <linux/mfd/imx25-tsadc.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +
> > +static const char mx25_tcq_name[] = "mx25-tcq";
> > +
> > +enum mx25_tcq_mode {
> > + MX25_TS_4WIRE,
> > +};
> > +
> > +struct mx25_tcq_priv {
> > + struct regmap *regs;
> > + struct regmap *core_regs;
> > + struct input_dev *idev;
> > + enum mx25_tcq_mode mode;
> > + unsigned int pen_threshold;
> > + unsigned int sample_count;
> > + unsigned int expected_samples;
> > + unsigned int repeat_wait;
> > + unsigned int pen_debounce;
> > + unsigned int settling_time;
> > + struct clk *clk;
> > +};
> > +
> > +static struct regmap_config mx25_tcq_regconfig = {
> > + .fast_io = true,
> > + .max_register = 0x5c,
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > +};
> > +
> > +static struct of_device_id mx25_tcq_ids[] = {
> > + { .compatible = "fsl,imx25-tcq", },
> > + { /* Senitel */ }
> > +};
> > +
> > +#define TSC_4WIRE_PRE_INDEX 0
> > +#define TSC_4WIRE_X_INDEX 1
> > +#define TSC_4WIRE_Y_INDEX 2
> > +#define TSC_4WIRE_POST_INDEX 3
> > +#define TSC_4WIRE_LEAVE 4
> > +
> > +#define MX25_TSC_DEF_THRESHOLD 80
> > +#define TSC_MAX_SAMPLES 16
> > +
> > +
> > +enum mx25_adc_configurations {
> > + MX25_CFG_PRECHARGE = 0,
> > + MX25_CFG_TOUCH_DETECT,
> > + MX25_CFG_X_MEASUREMENT,
> > + MX25_CFG_Y_MEASUREMENT,
> > +};
> > +
> > +#define MX25_PRECHARGE_VALUE (\
> > + MX25_ADCQ_CFG_YPLL_OFF | \
> > + MX25_ADCQ_CFG_XNUR_OFF | \
> > + MX25_ADCQ_CFG_XPUL_HIGH | \
> > + MX25_ADCQ_CFG_REFP_INT | \
> > + MX25_ADCQ_CFG_IN_XP | \
> > + MX25_ADCQ_CFG_REFN_NGND2 | \
> > + MX25_ADCQ_CFG_IGS)
> > +
> > +#define MX25_TOUCH_DETECT_VALUE (\
> > + MX25_ADCQ_CFG_YNLR | \
> > + MX25_ADCQ_CFG_YPLL_OFF | \
> > + MX25_ADCQ_CFG_XNUR_OFF | \
> > + MX25_ADCQ_CFG_XPUL_OFF | \
> > + MX25_ADCQ_CFG_REFP_INT | \
> > + MX25_ADCQ_CFG_IN_XP | \
> > + MX25_ADCQ_CFG_REFN_NGND2 | \
> > + MX25_ADCQ_CFG_PENIACK)
> > +
> > +static void imx25_setup_queue_cfgs(struct mx25_tcq_priv *priv,
> > + unsigned int settling_time)
> > +{
> > + u32 precharge_cfg =
> > + MX25_PRECHARGE_VALUE |
> > + MX25_ADCQ_CFG_SETTLING_TIME(settling_time);
> > + u32 touch_detect_cfg =
> > + MX25_TOUCH_DETECT_VALUE |
> > + MX25_ADCQ_CFG_NOS(1) |
> > + MX25_ADCQ_CFG_SETTLING_TIME(settling_time);
> > +
> > + regmap_write(priv->core_regs, MX25_TSC_TICR, precharge_cfg);
> > +
> > + /* PRECHARGE */
> > + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_PRECHARGE),
> > + precharge_cfg);
> > +
> > + /* TOUCH_DETECT */
> > + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_TOUCH_DETECT),
> > + touch_detect_cfg);
> > +
> > + /* X Measurement */
> > + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_X_MEASUREMENT),
> > + MX25_ADCQ_CFG_YPLL_OFF |
> > + MX25_ADCQ_CFG_XNUR_LOW |
> > + MX25_ADCQ_CFG_XPUL_HIGH |
> > + MX25_ADCQ_CFG_REFP_XP |
> > + MX25_ADCQ_CFG_IN_YP |
> > + MX25_ADCQ_CFG_REFN_XN |
> > + MX25_ADCQ_CFG_NOS(priv->sample_count) |
> > + MX25_ADCQ_CFG_SETTLING_TIME(settling_time));
> > +
> > + /* Y Measurement */
> > + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_Y_MEASUREMENT),
> > + MX25_ADCQ_CFG_YNLR |
> > + MX25_ADCQ_CFG_YPLL_HIGH |
> > + MX25_ADCQ_CFG_XNUR_OFF |
> > + MX25_ADCQ_CFG_XPUL_OFF |
> > + MX25_ADCQ_CFG_REFP_YP |
> > + MX25_ADCQ_CFG_IN_XP |
> > + MX25_ADCQ_CFG_REFN_YN |
> > + MX25_ADCQ_CFG_NOS(priv->sample_count) |
> > + MX25_ADCQ_CFG_SETTLING_TIME(settling_time));
> > +
> > + /* Enable the touch detection right now */
> > + regmap_write(priv->core_regs, MX25_TSC_TICR, touch_detect_cfg |
> > + MX25_ADCQ_CFG_IGS);
> > +}
> > +
> > +static int imx25_setup_queue_4wire(struct mx25_tcq_priv *priv,
> > + unsigned settling_time, int *items)
> > +{
> > + imx25_setup_queue_cfgs(priv, settling_time);
> > +
> > + /* Setup the conversion queue */
> > + regmap_write(priv->regs, MX25_ADCQ_ITEM_7_0,
> > + MX25_ADCQ_ITEM(0, MX25_CFG_PRECHARGE) |
> > + MX25_ADCQ_ITEM(1, MX25_CFG_TOUCH_DETECT) |
> > + MX25_ADCQ_ITEM(2, MX25_CFG_X_MEASUREMENT) |
> > + MX25_ADCQ_ITEM(3, MX25_CFG_Y_MEASUREMENT) |
> > + MX25_ADCQ_ITEM(4, MX25_CFG_PRECHARGE) |
> > + MX25_ADCQ_ITEM(5, MX25_CFG_TOUCH_DETECT));
> > +
> > + /* We measure X/Y with 'sample_count' number of samples and execute a
> > + * touch detection twice, with 1 sample each */
> > + priv->expected_samples = priv->sample_count * 2 + 2;
> > + *items = 6;
> > +
> > + return 0;
> > +}
> > +
> > +static void mx25_tcq_disable_touch_irq(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_PDMSK,
> > + MX25_ADCQ_CR_PDMSK);
> > +}
> > +
> > +static void mx25_tcq_enable_touch_irq(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_PDMSK, 0);
> > +}
> > +
> > +static void mx25_tcq_disable_fifo_irq(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_FDRY_IRQ,
> > + MX25_ADCQ_MR_FDRY_IRQ);
> > +}
> > +
> > +static void mx25_tcq_enable_fifo_irq(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_FDRY_IRQ, 0);
> > +}
> > +
> > +static void mx25_tcq_force_queue_start(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS,
> > + MX25_ADCQ_CR_FQS);
> > +
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS, 0);
> > +}
> > +
> > +static void mx25_tcq_force_queue_stop(struct mx25_tcq_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS, 0);
> > +}
> > +
> > +static void mx25_tcq_fifo_reset(struct mx25_tcq_priv *priv)
> > +{
> > + u32 tcqcr;
> > +
> > + regmap_read(priv->regs, MX25_ADCQ_CR, &tcqcr);
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FRST,
> > + MX25_ADCQ_CR_FRST);
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FRST,
> > + 0);
> > + regmap_write(priv->regs, MX25_ADCQ_CR, tcqcr);
> > +}
> > +
> > +static void mx25_tcq_re_enable_touch_detection(struct mx25_tcq_priv *priv)
> > +{
> > + /* stop the queue from looping */
> > + mx25_tcq_force_queue_stop(priv);
> > +
> > + /* for a clean touch detection, preload the X plane */
> > + regmap_write(priv->core_regs, MX25_TSC_TICR, MX25_PRECHARGE_VALUE);
> > +
> > + /* waste some time now to pre-load the X plate to high voltage */
> > + mx25_tcq_fifo_reset(priv);
> > +
> > + /* re-enable the detection right now */
> > + regmap_write(priv->core_regs, MX25_TSC_TICR, MX25_TOUCH_DETECT_VALUE |
> > + MX25_ADCQ_CFG_IGS);
> > +
> > + regmap_update_bits(priv->regs, MX25_ADCQ_SR, MX25_ADCQ_SR_PD,
> > + MX25_ADCQ_SR_PD);
> > +
> > + /* enable the pen down event to be a source for the interrupt */
> > + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_PD_IRQ, 0);
> > +
> > + /* lets fire the next IRQ if someone touches the touchscreen */
> > + mx25_tcq_enable_touch_irq(priv);
> > +}
> > +
> > +static int mx25_tcq_create_event_for_4wire(struct mx25_tcq_priv *priv,
> > + u32 *sample_buf, int samples)
> > +{
> > + unsigned int x_pos = 0;
> > + unsigned int y_pos = 0;
> > + unsigned int touch_pre = 0;
> > + unsigned int touch_post = 0;
> > + unsigned i;
> > + int ret = 0;
> > +
> > + for (i = 0; i < samples; i++) {
> > + unsigned int index = MX25_ADCQ_FIFO_ID(sample_buf[i]);
> > + unsigned int val = MX25_ADCQ_FIFO_DATA(sample_buf[i]);
> > +
> > + switch (index) {
> > + case 1:
> > + touch_pre = val;
> > + break;
> > + case 2:
> > + x_pos = val;
> > + break;
> > + case 3:
> > + y_pos = val;
> > + break;
> > + case 5:
> > + touch_post = val;
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + break;
> > + }
> > + }
> > +
> > + if (ret == 0 && samples != 0) {
> > + /*
> > + * only if both touch measures are below a treshold,
> > + * the position is valid
> > + */
> > + if (touch_pre < priv->pen_threshold &&
> > + touch_post < priv->pen_threshold) {
> > + /* valid samples, generate a report */
> > + x_pos /= priv->sample_count;
> > + y_pos /= priv->sample_count;
> > + input_report_abs(priv->idev, ABS_X, x_pos);
> > + input_report_abs(priv->idev, ABS_Y, y_pos);
> > + input_report_key(priv->idev, BTN_TOUCH,
> > + 0xfff - ((touch_pre + touch_post) / 2));
>
> Hmm, are you trying to report pressure here?
No this is only to detect touches, not pressure. Reporting pressure
would require a different, more complex conversion queue.
>
> > + input_sync(priv->idev);
> > +
> > + /* get next sample */
> > + mx25_tcq_force_queue_start(priv);
> > + mx25_tcq_enable_fifo_irq(priv);
> > + } else {
> > + if (touch_pre >= priv->pen_threshold &&
>
> You can convert this to "else if" and save indentation level here.
Fixed.
>
> > + touch_post >= priv->pen_threshold) {
> > + /*
> > + * if both samples are invalid,
> > + * generate a release report
> > + */
> > + input_report_key(priv->idev, BTN_TOUCH, 0);
> > + input_sync(priv->idev);
> > + mx25_tcq_re_enable_touch_detection(priv);
> > + } else {
> > + /*
> > + * if only one of both touch measurements are
> > + * below the threshold, still some bouncing
> > + * happens. Take additional samples in this
> > + * case to be sure
> > + */
> > + mx25_tcq_force_queue_start(priv);
> > + mx25_tcq_enable_fifo_irq(priv);
> > + }
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static irqreturn_t mx25_tcq_irq_thread(int irq, void *dev_id)
> > +{
> > + struct mx25_tcq_priv *priv = (struct mx25_tcq_priv *) dev_id;
> > + u32 sample_buf[TSC_MAX_SAMPLES];
> > + int samples = 0;
> > +
> > + /* read all samples */
> > + while (1) {
> > + u32 stats;
> > +
> > + regmap_read(priv->regs, MX25_ADCQ_SR, &stats);
>
> Error handling for I/O operations?
This is memory mapped io. It only returns an error when the clock enable
operation fails. As regmap is not configured to use a clock for this
driver, I would prefer to not use error handling for regmap_read/write.
>
> > + if (stats & MX25_ADCQ_SR_EMPT)
> > + break;
> > +
> > + if (samples < TSC_MAX_SAMPLES) {
> > + regmap_read(priv->regs, MX25_ADCQ_FIFO,
> > + &sample_buf[samples]);
> > + ++samples;
> > + } else {
> > + u32 discarded;
> > + /* discard samples */
> > + regmap_read(priv->regs, MX25_ADCQ_FIFO, &discarded);
>
> Should there be some upper bound for number of discarded samples?
I just noticed that we do not repeat the conversion queue. The bit is
not set, so all the repeat code can be removed. This also means that the
conversion is stopped when we reach the end of the conversion queue and
this should not need an additional upper bound for discarded samples.
>
> > + }
> > + }
> > +
> > + mx25_tcq_create_event_for_4wire(priv, sample_buf, samples);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t mx25_tcq_irq(int irq, void *dev_id)
> > +{
> > + struct mx25_tcq_priv *priv = (struct mx25_tcq_priv *)dev_id;
> > + u32 stat;
> > + int ret = IRQ_HANDLED;
> > +
> > + regmap_read(priv->regs, MX25_ADCQ_SR, &stat);
> > +
> > + if (stat & (MX25_ADCQ_SR_FRR | MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR))
> > + mx25_tcq_fifo_reset(priv);
> > +
> > + if (stat & MX25_ADCQ_SR_PD) {
> > + mx25_tcq_disable_touch_irq(priv);
> > + mx25_tcq_force_queue_start(priv);
> > + mx25_tcq_enable_fifo_irq(priv);
> > + }
> > +
> > + if (stat & MX25_ADCQ_SR_FDRY) {
> > + mx25_tcq_disable_fifo_irq(priv);
> > + ret = IRQ_WAKE_THREAD;
> > + }
> > +
> > + regmap_update_bits(priv->regs, MX25_ADCQ_SR, MX25_ADCQ_SR_FRR |
> > + MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR | MX25_ADCQ_SR_PD |
> > + MX25_ADCQ_SR_EOQ,
> > + MX25_ADCQ_SR_FRR |
> > + MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR | MX25_ADCQ_SR_PD |
> > + MX25_ADCQ_SR_EOQ);
> > +
> > + return ret;
> > +}
> > +
> > +/* configure the statemachine for a 4-wire touchscreen */
> > +static int mx25_tcq_init(struct mx25_tcq_priv *priv)
> > +{
> > + u32 tgcr;
> > + unsigned int ipg_div;
> > + unsigned int adc_period;
> > + unsigned int repeat_wait;
> > + unsigned int debounce_cnt;
> > + unsigned int settling_time;
> > + int itemct;
> > + int ret;
> > +
> > + regmap_read(priv->core_regs, MX25_TSC_TGCR, &tgcr);
> > + ipg_div = max_t(unsigned int, 4, MX25_TGCR_GET_ADCCLK(tgcr));
> > + adc_period = clk_get_rate(priv->clk) / (ipg_div * 2 + 2);
> > + repeat_wait = fls(DIV_ROUND_UP(priv->repeat_wait, adc_period));
> > + debounce_cnt = DIV_ROUND_UP(priv->pen_debounce, adc_period * 8) - 1;
> > + settling_time = DIV_ROUND_UP(priv->settling_time, adc_period);
> > +
> > +
> > + /* Reset */
> > + regmap_write(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QRST |
> > + MX25_ADCQ_CR_FRST);
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QRST |
> > + MX25_ADCQ_CR_FRST, 0);
> > +
> > + /* up to 128 * 8 ADC clocks are possible */
> > + if (debounce_cnt > 127)
> > + debounce_cnt = 127;
> > +
> > + if (repeat_wait > 15)
> > + repeat_wait = 15;
> > +
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_RWAIT_MASK,
> > + MX25_ADCQ_CR_RWAIT(repeat_wait));
> > +
> > + ret = imx25_setup_queue_4wire(priv, 0x0, &itemct);
> > + if (ret)
> > + return ret;
> > +
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_LITEMID_MASK |
> > + MX25_ADCQ_CR_WMRK_MASK,
> > + MX25_ADCQ_CR_LITEMID(itemct - 1) |
> > + MX25_ADCQ_CR_WMRK(priv->expected_samples - 1));
> > +
> > + /* setup debounce count */
> > + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR,
> > + MX25_TGCR_PDBTIME_MASK,
> > + MX25_TGCR_PDBTIME(debounce_cnt));
> > +
> > + /* enable debounce */
> > + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR, MX25_TGCR_PDBEN,
> > + MX25_TGCR_PDBEN);
> > + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR, MX25_TGCR_PDEN,
> > + MX25_TGCR_PDEN);
> > +
> > + /* enable the engine on demand */
> > + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QSM_FQS,
> > + MX25_ADCQ_CR_QSM_FQS);
> > +
> > + mx25_tcq_re_enable_touch_detection(priv);
> > +
> > + return 0;
> > +}
> > +
> > +static int mx25_tcq_parse_dt(struct platform_device *pdev,
> > + struct mx25_tcq_priv *priv)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + u32 wires;
> > + int ret;
> > +
> > + /* Setup defaults */
> > + priv->pen_threshold = 500;
> > + priv->sample_count = 3;
> > + priv->repeat_wait = 15000000;
> > + priv->pen_debounce = 1000000;
> > + priv->settling_time = 250000;
> > +
> > + ret = of_property_read_u32(np, "fsl,wires", &wires);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Failed to find fsl,wires properties\n");
> > + return ret;
> > + }
> > +
> > + if (wires == 4) {
> > + priv->mode = MX25_TS_4WIRE;
> > + } else {
> > + dev_err(&pdev->dev, "%u-wire mode not supported\n", wires);
> > + return -EINVAL;
> > + }
> > +
> > + /* These are optional, we don't care about the return values */
> > + of_property_read_u32(np, "fsl,pen-threshold", &priv->pen_threshold);
> > + of_property_read_u32(np, "fsl,settling-time", &priv->settling_time);
> > + of_property_read_u32(np, "fsl,pen-debounce", &priv->pen_debounce);
> > +
> > + return 0;
> > +}
> > +
> > +static int mx25_tcq_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct input_dev *idev;
> > + struct mx25_tcq_priv *priv;
> > + struct resource *res;
> > + void __iomem *mem;
> > + int ret;
> > + int irq;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + mem = devm_ioremap_resource(dev, res);
> > + if (!mem) {
> > + dev_err(dev, "Failed to get iomem");
> > + return -ENOMEM;
> > + }
> > +
> > + ret = mx25_tcq_parse_dt(pdev, priv);
> > + if (ret)
> > + return ret;
> > +
> > + priv->regs = devm_regmap_init_mmio(dev, mem, &mx25_tcq_regconfig);
> > + if (IS_ERR(priv->regs)) {
> > + dev_err(dev, "Failed to initialize regmap\n");
> > + return PTR_ERR(priv->regs);
> > + }
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(dev, "Failed to get IRQ\n");
> > + return irq;
> > + }
> > +
> > + ret = devm_request_threaded_irq(dev, irq, mx25_tcq_irq,
> > + mx25_tcq_irq_thread, IRQF_ONESHOT, pdev->name, priv);
> > + if (ret) {
> > + dev_err(dev, "Failed requesting IRQ\n");
> > + return ret;
> > + }
>
> Are we sure the device is quiesce here? Otherwise interrupts will start
> coming but input device is not there yet.
I moved it to the end of the probe function just before tcq_init where
the interrupts are enabled.
>
> > +
> > + idev = devm_input_allocate_device(dev);
> > + if (!idev) {
> > + dev_err(dev, "Failed to allocate input device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + idev->name = mx25_tcq_name;
> > + idev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> > + idev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> > + input_set_abs_params(idev, ABS_X, 0, 0xfff, 0, 0);
> > + input_set_abs_params(idev, ABS_Y, 0, 0xfff, 0, 0);
> > +
> > + idev->id.bustype = BUS_HOST;
> > +
> > + ret = input_register_device(idev);
> > + if (ret) {
> > + dev_err(dev, "Failed to register input device\n");
> > + return ret;
> > + }
> > +
> > + priv->idev = idev;
> > +
> > + priv->core_regs = mx25_tsadc_get_regmap(pdev->dev.parent);
> > + priv->clk = mx25_tsadc_get_ipg(pdev->dev.parent);
> > +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable ipg clock\n");
> > + return ret;
> > + }
> > +
> > + ret = mx25_tcq_init(priv);
> > + if (ret) {
> > + dev_err(dev, "Failed to init tcq\n");
> > + goto error_tcq_init;
> > + }
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + return 0;
> > +
> > +error_tcq_init:
> > + clk_disable_unprepare(priv->clk);
> > + return ret;
> > +}
> > +
> > +static int mx25_tcq_remove(struct platform_device *pdev)
> > +{
> > + struct mx25_tcq_priv *priv = platform_get_drvdata(pdev);
> > +
> > + clk_disable_unprepare(priv->clk);
>
> Hmm, if you disable clk all other operations will likely to fail. We
> really need devm clk interface, I guess I need to dust off my old
> patch...
>
> > +
> > + return 0;
> > +}
> > +
> > +static struct platform_driver mx25_tcq_driver = {
> > + .driver = {
> > + .name = "mx25-tcq",
> > + .owner = THIS_MODULE,
> > + .of_match_table = mx25_tcq_ids,
> > + },
> > + .probe = mx25_tcq_probe,
> > + .remove = mx25_tcq_remove,
> > +};
> > +module_platform_driver(mx25_tcq_driver);
> > +
> > +MODULE_DESCRIPTION("TS input driver for Freescale mx25");
> > +MODULE_AUTHOR("Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.8.5.3
> >
Thanks,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] Input: gpio_keys - convert struct descriptions to kernel-doc
From: Linus Walleij @ 2014-02-25 8:47 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Dmitry Torokhov, Linux Input
In-Reply-To: <1392816071-23839-3-git-send-email-andriy.shevchenko@linux.intel.com>
On Wed, Feb 19, 2014 at 2:21 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> This patch converts descriptions of the structures defined in linux/gpio_keys.h
> to follow kernel-doc format.
>
> There is no functional change.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/3] Input: gpio_keys - convert to use devm_*
From: Linus Walleij @ 2014-02-25 8:46 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Dmitry Torokhov, Linux Input
In-Reply-To: <1392816071-23839-2-git-send-email-andriy.shevchenko@linux.intel.com>
On Wed, Feb 19, 2014 at 2:21 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> This makes the error handling much more simpler than open-coding everything and
> in addition makes the probe function smaller an tidier.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] input synaptics-rmi4: Add F30 support
From: Christopher Heiny @ 2014-02-24 22:53 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Linus Walleij, Allie Xiong,
Benjamin Tissoires, David Herrmann, Jiri Kosina
RMI4 Function 0x30 provides support for GPIOs, LEDs and mechanical
buttons. In particular, the mechanical button support is used in
an increasing number of touchpads.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Allie Xiong <axiong@synaptics.com>
Acked-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Linux Walleij <linus.walleij@linaro.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
---
drivers/input/rmi4/Kconfig | 12 +
drivers/input/rmi4/Makefile | 1 +
drivers/input/rmi4/rmi_f30.c | 618 +++++++++++++++++++++++++++++++++++++++++++
include/linux/rmi.h | 7 +-
4 files changed, 637 insertions(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index d0c7b6e..14d5f49 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -63,3 +63,15 @@ config RMI4_F11_PEN
If your system is not recognizing pen touches and you know your
sensor supports pen input, you probably want to turn this feature
off.
+
+config RMI4_F30
+ tristate "RMI4 Function 30 (GPIO LED)"
+ depends on RMI4_CORE
+ help
+ Say Y here if you want to add support for RMI4 function 30.
+
+ Function 30 provides GPIO and LED support for RMI4 devices. This
+ includes support for buttons on TouchPads and ClickPads.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rmi-f30.
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 5c6bad5..ecffd72 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -3,6 +3,7 @@ rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
# Function drivers
obj-$(CONFIG_RMI4_F11) += rmi_f11.o
+obj-$(CONFIG_RMI4_F30) += rmi_f30.o
# Transports
obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
new file mode 100644
index 0000000..9c711eb
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -0,0 +1,618 @@
+/*
+ * Copyright (c) 2012 - 2014 Synaptics Incorporated
+ *
+ * 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/kernel.h>
+#include <linux/rmi.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/leds.h>
+#include "rmi_driver.h"
+
+#define RMI_F30_QUERY_SIZE 2
+
+ /* Defs for Query 0 */
+#define RMI_F30_EXTENDED_PATTERNS 0x01
+#define RMI_F30_HAS_MAPPABLE_BUTTONS (1 << 1)
+#define RMI_F30_HAS_LED (1 << 2)
+#define RMI_F30_HAS_GPIO (1 << 3)
+#define RMI_F30_HAS_HAPTIC (1 << 4)
+#define RMI_F30_HAS_GPIO_DRV_CTL (1 << 5)
+#define RMI_F30_HAS_MECH_MOUSE_BTNS (1 << 6)
+
+/* Defs for Query 1 */
+#define RMI_F30_GPIO_LED_COUNT 0x1F
+
+/* Defs for Control Registers */
+#define RMI_F30_CTRL_1_GPIO_DEBOUNCE 0x01
+#define RMI_F30_CTRL_1_HALT (1 << 4)
+#define RMI_F30_CTRL_1_HALTED (1 << 5)
+#define RMI_F30_CTRL_10_NUM_MECH_MOUSE_BTNS 0x03
+
+#define RMI_F30_CTRL_DATA(ctrl_num, max_size) \
+struct rmi_f30_ctrl##ctrl_num##_data { \
+ int address; \
+ int length; \
+ u8 regs[max_size]; \
+}
+
+#define RMI_F30_CTRL_MAX_REGS 32
+#define RMI_F30_CTRL_MAX_BYTES ((RMI_F30_CTRL_MAX_REGS + 7) >> 3)
+
+struct f30_data {
+ /* Query Data */
+ bool has_extended_pattern;
+ bool has_mappable_buttons;
+ bool has_led;
+ bool has_gpio;
+ bool has_haptic;
+ bool has_gpio_driver_control;
+ bool has_mech_mouse_btns;
+ u8 gpioled_count;
+
+ u8 register_count;
+
+ /* Control Register Data */
+ RMI_F30_CTRL_DATA(0, RMI_F30_CTRL_MAX_BYTES) ctrl_0;
+ RMI_F30_CTRL_DATA(1, 1) ctrl_1;
+ RMI_F30_CTRL_DATA(2, RMI_F30_CTRL_MAX_BYTES) ctrl_2;
+ RMI_F30_CTRL_DATA(3, RMI_F30_CTRL_MAX_BYTES) ctrl_3;
+ RMI_F30_CTRL_DATA(4, RMI_F30_CTRL_MAX_BYTES) ctrl_4;
+ RMI_F30_CTRL_DATA(5, 6) ctrl_5;
+ RMI_F30_CTRL_DATA(6, RMI_F30_CTRL_MAX_REGS) ctrl_6;
+ RMI_F30_CTRL_DATA(7, RMI_F30_CTRL_MAX_REGS) ctrl_7;
+ RMI_F30_CTRL_DATA(8, RMI_F30_CTRL_MAX_BYTES) ctrl_8;
+ RMI_F30_CTRL_DATA(9, 1) ctrl_9;
+ RMI_F30_CTRL_DATA(10, 1) ctrl_10;
+
+ u8 data_regs[RMI_F30_CTRL_MAX_BYTES];
+ struct rmi_f30_button *gpioled_map;
+
+ char input_phys[NAME_BUFFER_SIZE];
+ struct input_dev *input;
+};
+
+static int rmi_f30_read_control_parameters(struct rmi_device *rmi_dev,
+ struct f30_data *f30)
+{
+ int retval = 0;
+
+ if (f30->ctrl_0.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_0.address,
+ f30->ctrl_0.regs, f30->ctrl_0.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg0 to 0x%x\n",
+ __func__, f30->ctrl_0.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_1.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_1.address,
+ f30->ctrl_1.regs, f30->ctrl_1.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg1 to 0x%x\n",
+ __func__, f30->ctrl_1.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_2.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_2.address,
+ f30->ctrl_2.regs, f30->ctrl_2.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg2 to 0x%x\n",
+ __func__, f30->ctrl_2.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_3.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_3.address,
+ f30->ctrl_3.regs, f30->ctrl_3.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg3 to 0x%x\n",
+ __func__, f30->ctrl_3.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_4.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_4.address,
+ f30->ctrl_4.regs, f30->ctrl_4.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg4 to 0x%x\n",
+ __func__, f30->ctrl_4.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_5.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_5.address,
+ f30->ctrl_5.regs, f30->ctrl_5.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg5 to 0x%x\n",
+ __func__, f30->ctrl_5.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_6.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_6.address,
+ f30->ctrl_6.regs, f30->ctrl_6.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg6 to 0x%x\n",
+ __func__, f30->ctrl_6.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_7.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_7.address,
+ f30->ctrl_1.regs, f30->ctrl_7.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg7 to 0x%x\n",
+ __func__, f30->ctrl_7.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_8.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_8.address,
+ f30->ctrl_8.regs, f30->ctrl_8.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg8 to 0x%x\n",
+ __func__, f30->ctrl_8.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_9.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_9.address,
+ f30->ctrl_9.regs, f30->ctrl_9.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg9 to 0x%x\n",
+ __func__, f30->ctrl_9.address);
+ return retval;
+ }
+ }
+
+ if (f30->ctrl_10.length) {
+ retval = rmi_read_block(rmi_dev, f30->ctrl_10.address,
+ f30->ctrl_10.regs, f30->ctrl_10.length);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "%s : Could not read control reg1 to 0x%x\n",
+ __func__, f30->ctrl_10.address);
+ return retval;
+ }
+ }
+
+ return 0;
+}
+
+static int rmi_f30_attention(struct rmi_function *fn,
+ unsigned long *irq_bits)
+{
+ struct f30_data *f30 = fn->data;
+ int retval;
+ int gpiled = 0;
+ int value = 0;
+ int i;
+ int reg_num;
+
+ /* Read the gpi led data. */
+ retval = rmi_read_block(fn->rmi_dev, fn->fd.data_base_addr,
+ f30->data_regs, f30->register_count);
+
+ if (retval < 0) {
+ dev_err(&fn->dev, "%s: Failed to read F30 data registers.\n",
+ __func__);
+ return retval;
+ }
+
+ for (reg_num = 0; reg_num < f30->register_count; ++reg_num) {
+ for (i = 0; gpiled < f30->gpioled_count && i < 8; ++i,
+ ++gpiled) {
+ if (f30->gpioled_map[gpiled].button != 0) {
+ value = (((f30->data_regs[reg_num] >> i) & 0x01)
+ == f30->gpioled_map[gpiled].sense);
+
+ dev_dbg(&fn->dev,
+ "%s: call input report key (0x%04x) value (0x%02x)",
+ __func__,
+ f30->gpioled_map[gpiled].button, value);
+ input_report_key(f30->input,
+ f30->gpioled_map[gpiled].button,
+ value);
+ }
+
+ }
+ }
+
+ input_sync(f30->input); /* sync after groups of events */
+ return 0;
+}
+
+static int rmi_f30_register_device(struct rmi_function *fn)
+{
+ int i;
+ int rc;
+ struct rmi_device *rmi_dev = fn->rmi_dev;
+ struct f30_data *f30 = fn->data;
+ struct rmi_driver *driver = fn->rmi_dev->driver;
+ struct input_dev *input_dev = input_allocate_device();
+
+ if (!input_dev) {
+ dev_err(&fn->dev, "Failed to allocate input device.\n");
+ return -ENOMEM;
+ }
+
+ f30->input = input_dev;
+
+ if (driver->set_input_params) {
+ rc = driver->set_input_params(rmi_dev, input_dev);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s: Error in setting input device.\n",
+ __func__);
+ goto error_free_device;
+ }
+ }
+ sprintf(f30->input_phys, "%s/input0", dev_name(&fn->dev));
+ input_dev->phys = f30->input_phys;
+ input_dev->dev.parent = &rmi_dev->dev;
+ input_set_drvdata(input_dev, f30);
+
+ /* Set up any input events. */
+ set_bit(EV_SYN, input_dev->evbit);
+ set_bit(EV_KEY, input_dev->evbit);
+ input_dev->keycode = f30->gpioled_map;
+ input_dev->keycodesize = 1;
+ input_dev->keycodemax = f30->gpioled_count;
+ /* set bits for each qpio led pin... */
+ for (i = 0; i < f30->gpioled_count; i++) {
+ if (f30->gpioled_map[i].button != 0) {
+ set_bit(f30->gpioled_map[i].button, input_dev->keybit);
+ input_set_capability(input_dev, EV_KEY,
+ f30->gpioled_map[i].button);
+ }
+ }
+
+ rc = input_register_device(input_dev);
+ if (rc < 0) {
+ dev_err(&fn->dev, "Failed to register input device.\n");
+ goto error_free_device;
+ }
+ return 0;
+
+error_free_device:
+ input_free_device(input_dev);
+
+ return rc;
+}
+
+static int rmi_f30_config(struct rmi_function *fn)
+{
+ struct f30_data *f30 = fn->data;
+ int rc;
+
+ /* Write Control Register values back to device */
+ if (f30->ctrl_0.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_0.address,
+ f30->ctrl_0.regs,
+ f30->ctrl_0.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 0 to 0x%x\n",
+ __func__, rc, f30->ctrl_0.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_1.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_1.address,
+ f30->ctrl_1.regs,
+ f30->ctrl_1.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 1 to 0x%x\n",
+ __func__, rc, f30->ctrl_1.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_2.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_2.address,
+ f30->ctrl_2.regs,
+ f30->ctrl_2.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 2 to 0x%x\n",
+ __func__, rc, f30->ctrl_2.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_3.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_3.address,
+ f30->ctrl_3.regs,
+ f30->ctrl_3.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 3 to 0x%x\n",
+ __func__, rc, f30->ctrl_3.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_4.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_4.address,
+ f30->ctrl_4.regs,
+ f30->ctrl_4.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 4 to 0x%x\n",
+ __func__, rc, f30->ctrl_4.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_5.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_5.address,
+ f30->ctrl_5.regs,
+ f30->ctrl_5.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 5 to 0x%x\n",
+ __func__, rc, f30->ctrl_5.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_6.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_6.address,
+ f30->ctrl_6.regs,
+ f30->ctrl_6.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 6 to 0x%x\n",
+ __func__, rc, f30->ctrl_6.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_7.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_7.address,
+ f30->ctrl_7.regs,
+ f30->ctrl_7.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 7 to 0x%x\n",
+ __func__, rc, f30->ctrl_7.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_8.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_8.address,
+ f30->ctrl_8.regs,
+ f30->ctrl_8.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 8 to 0x%x\n",
+ __func__, rc, f30->ctrl_8.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_9.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_9.address,
+ f30->ctrl_9.regs,
+ f30->ctrl_9.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 9 to 0x%x\n",
+ __func__, rc, f30->ctrl_9.address);
+ return rc;
+ }
+ }
+
+ if (f30->ctrl_10.length) {
+ rc = rmi_write_block(fn->rmi_dev, f30->ctrl_10.address,
+ f30->ctrl_10.regs,
+ f30->ctrl_10.length);
+ if (rc < 0) {
+ dev_err(&fn->dev, "%s error %d: Could not write control 10 to 0x%x\n",
+ __func__, rc, f30->ctrl_10.address);
+ return rc;
+ }
+ }
+
+ return 0;
+}
+
+static inline int rmi_f30_initialize(struct rmi_function *fn)
+{
+ struct f30_data *f30;
+ struct rmi_device *rmi_dev = fn->rmi_dev;
+ struct rmi_device_platform_data *pdata;
+ int retval = 0;
+ int control_address;
+ u8 buf[RMI_F30_QUERY_SIZE];
+
+ f30 = devm_kzalloc(&fn->dev, sizeof(struct f30_data),
+ GFP_KERNEL);
+ if (!f30) {
+ dev_err(&fn->dev, "Failed to allocate f30_data.\n");
+ return -ENOMEM;
+ }
+ fn->data = f30;
+
+ retval = rmi_read_block(fn->rmi_dev, fn->fd.query_base_addr, buf,
+ RMI_F30_QUERY_SIZE);
+
+ if (retval < 0) {
+ dev_err(&fn->dev, "Failed to read query register.\n");
+ return retval;
+ }
+
+ f30->has_extended_pattern = buf[0] & RMI_F30_EXTENDED_PATTERNS;
+ f30->has_mappable_buttons = buf[0] & RMI_F30_HAS_MAPPABLE_BUTTONS;
+ f30->has_led = buf[0] & RMI_F30_HAS_LED;
+ f30->has_gpio = buf[0] & RMI_F30_HAS_GPIO;
+ f30->has_haptic = buf[0] & RMI_F30_HAS_HAPTIC;
+ f30->has_gpio_driver_control = buf[0] & RMI_F30_HAS_GPIO_DRV_CTL;
+ f30->has_mech_mouse_btns = buf[0] & RMI_F30_HAS_MECH_MOUSE_BTNS;
+ f30->gpioled_count = buf[1] & RMI_F30_GPIO_LED_COUNT;
+
+ f30->register_count = (f30->gpioled_count + 7) >> 3;
+
+ control_address = fn->fd.control_base_addr;
+
+ /* Allocate buffers for the control registers */
+ if (f30->has_led && f30->has_led) {
+ f30->ctrl_0.address = control_address;
+ f30->ctrl_0.length = f30->register_count;
+ control_address += f30->ctrl_0.length;
+ }
+
+ f30->ctrl_1.address = control_address;
+ f30->ctrl_1.length = sizeof(u8);
+ control_address += f30->ctrl_1.length;
+
+ if (f30->has_gpio) {
+ f30->ctrl_2.address = control_address;
+ f30->ctrl_2.length = f30->register_count;
+ control_address += f30->ctrl_2.length;
+
+ f30->ctrl_3.address = control_address;
+ f30->ctrl_3.length = f30->register_count;
+ control_address += f30->ctrl_3.length;
+ }
+
+ if (f30->has_led) {
+ f30->ctrl_4.address = control_address;
+ f30->ctrl_4.length = f30->register_count;
+ control_address += f30->ctrl_4.length;
+
+ if (f30->has_extended_pattern)
+ f30->ctrl_5.length = 6;
+ else
+ f30->ctrl_5.length = 2;
+
+ f30->ctrl_5.address = control_address;
+ control_address += f30->ctrl_5.length;
+ }
+
+ if (f30->has_led || f30->has_gpio_driver_control) {
+ /* control 6 uses a byte per gpio/led */
+ f30->ctrl_6.address = control_address;
+ f30->ctrl_6.length = f30->gpioled_count;
+ control_address += f30->ctrl_6.length;
+
+ }
+
+ if (f30->has_mappable_buttons) {
+ /* control 7 uses a byte per gpio/led */
+ f30->ctrl_7.address = control_address;
+ f30->ctrl_7.length = f30->gpioled_count;
+ control_address += f30->ctrl_7.length;
+ }
+
+ if (f30->has_haptic) {
+ f30->ctrl_8.address = control_address;
+ f30->ctrl_8.length = f30->register_count;
+ control_address += f30->ctrl_8.length;
+
+ f30->ctrl_9.address = control_address;
+ f30->ctrl_9.length = sizeof(u8);
+ control_address += f30->ctrl_9.length;
+ }
+
+ if (f30->has_mech_mouse_btns) {
+ f30->ctrl_10.address = control_address;
+ f30->ctrl_10.length = sizeof(u8);
+ control_address += f30->ctrl_10.length;
+ }
+
+ f30->gpioled_map = devm_kzalloc(&fn->dev,
+ f30->gpioled_count
+ * sizeof(struct rmi_f30_button),
+ GFP_KERNEL);
+ if (!f30->gpioled_map) {
+ dev_err(&fn->dev, "Failed to allocate button map.\n");
+ return -ENOMEM;
+ }
+
+ pdata = to_rmi_platform_data(rmi_dev);
+ if (pdata) {
+ if (!pdata->gpioled_map) {
+ dev_warn(&fn->dev,
+ "%s - gpioled_map is NULL", __func__);
+ } else if (pdata->gpioled_map->ngpioleds < f30->gpioled_count) {
+ dev_warn(&fn->dev,
+ "Platform Data gpioled map size (%d) is less then the number of buttons on device (%d) - ignored\n",
+ pdata->gpioled_map->ngpioleds,
+ f30->gpioled_count);
+ } else if (!pdata->gpioled_map->map) {
+ dev_warn(&fn->dev,
+ "Platform Data button map is missing!\n");
+ } else {
+ int i;
+ for (i = 0; i < f30->gpioled_count; i++)
+ memcpy(&f30->gpioled_map[i],
+ &pdata->gpioled_map->map[i],
+ sizeof(struct rmi_f30_button));
+ }
+ }
+
+ retval = rmi_f30_read_control_parameters(rmi_dev, f30);
+ if (retval < 0) {
+ dev_err(&fn->dev,
+ "Failed to initialize F19 control params.\n");
+ return retval;
+ }
+
+ return 0;
+}
+
+static int rmi_f30_probe(struct rmi_function *fn)
+{
+ int rc;
+
+ rc = rmi_f30_initialize(fn);
+ if (rc < 0)
+ goto error_exit;
+
+ rc = rmi_f30_register_device(fn);
+ if (rc < 0)
+ goto error_exit;
+
+ return 0;
+
+error_exit:
+ return rc;
+
+}
+
+static struct rmi_function_handler rmi_f30_handler = {
+ .driver = {
+ .name = "rmi_f30",
+ },
+ .func = 0x30,
+ .probe = rmi_f30_probe,
+ .config = rmi_f30_config,
+ .attention = rmi_f30_attention,
+};
+
+module_rmi_driver(rmi_f30_handler);
+
+MODULE_AUTHOR("Allie Xiong <axiong@synaptics.com>");
+MODULE_AUTHOR("Andrew Duggan <aduggan@synaptics.com>");
+MODULE_DESCRIPTION("RMI F30 module");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index 735e978..889a627 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -139,9 +139,14 @@ struct rmi_button_map {
u8 *map;
};
+struct rmi_f30_button {
+ u16 button;
+ int sense;
+};
+
struct rmi_f30_gpioled_map {
u8 ngpioleds;
- u8 *map;
+ struct rmi_f30_button *map;
};
/**
^ permalink raw reply related
* Re: [PATCH v2 0/5] HID: sony: Various fixes and improvements for the Sony driver
From: Jiri Kosina @ 2014-02-24 22:31 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input, dh.herrmann
In-Reply-To: <1392914164-31899-1-git-send-email-frank.praznik@oh.rr.com>
On Thu, 20 Feb 2014, Frank Praznik wrote:
> v2 of this patch set addresses the code review issues raised in v1 as well as
> adding a patch that fixes the styling of multi-line comments to conform to
> kernel coding standards, adds a check to protect against a potential
> out-of-bounds read in the Sixaxis battery code and adds a note in hidp/core.c
> that a device module now depends on the current behavior of the uniq string.
Queued in for-3.15/sony, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
From: Michal Malý @ 2014-02-24 22:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Elias Vanderstuyft, Anssi Hannula, linux-input, linux-kernel,
Jiri Kosina, Simon Wood
In-Reply-To: <20140224214818.GA4156@core.coreip.homeip.net>
On Monday 24 of February 2014 13:48:18 Dmitry Torokhov wrote:
> On Mon, Feb 24, 2014 at 10:17:25PM +0100, Elias Vanderstuyft wrote:
> > On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý <madcatxster@prifuk.cz>
wrote:
> > > On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote:
> > >> I think we should extend the current ff-memless instead of duplicating
> > >> its functionality (even on a "for now" basis).
> > >>
> > >> Having looked at ff-memless-next briefly, it seems very similar to
> > >> ff-memless on its basic working principle, and therefore I don't really
> > >> see why extending ff-memless would be too cumbersome. Unless I'm
> > >> missing
> > >> something - in that case, feel free to point it out to me :)
> > >
> > > Deciding whether to patch ff-memless or write a new driver from scratch
> > > was a perfect example of being caught between the rock and a hard
> > > place. I am not particularly fond of the fact that we would have two
> > > modules doing pretty much the same thing. My reasons for writing a
> > > separate module were:
> > > - Periodic effects. ff-memless doesn't do "real" periodic effects, it
> > > simply emulates them through rumble effect. Devices without rumble
> > > effect support require emulation through constant force effect. Just
> > > this was not something one could write in one afternoon:)
> > > - Conditional effects. These effects cannot be by nature combined into
> > > one
> > > overall force (at least not easily) so they have to be handled one by
> > > one -
> > > this is a concept ff-memless does not seem to consider. FFB devices have
> > > limits as to how many conditional (referred to as "uncombinable" in
> > > MLNX)
> > > effects can be active simultaneously, etc.
> > > All in all it seemed less error prone to write a new driver based on the
> > > ff- memless logic, test and deploy it on devices I have access to and
> > > once we are sure there are no nasty regressions port the rest of the
> > > drivers to the new API. Given the scope of the changes I am afraid that
> > > a "patch" to ff-memless would be pretty close to a rewrite anyway.
> >
> > And add the fact that we already heavily tested the ff-memless-next
> > driver.
> > Unless you do a diff between the original ff-memless.c and the current
> > ff-memless-next.c (which will result in a rather unintuitive patch),
> > it would be a huge waste of time to retest the modified (when doing
> > efforts to create an intuitive patch) ff-memless-next.c, considered my
> > total time spend on testing (and not to speak of the time that Michal
> > spent to fix the corresponding bugs.)
> > I know that might not be much of an argument, but on the other side,
> > my motivation to test again from scratch will be much lower (I can't
> > change much on that, I'm afraid), which would eventually lead to lower
> > reliability of the final product.
>
> On the other hand having 2 drivers implementing very similar
> functionality would lead to general confusion as to which one should be
> used; they will also have to be maintained.
>
> I would rather see them merged into one driver providing necessary
> services to all memoryless FF devices.
>
> Thanks.
Very well. It that case I guess the most sensible thing to do would be to add
FF_RUMBLE to ff-memless-next and replace ff-memless completely. As Anssi
pointed out a lot of the drivers that currently use ff-memless are very simple
so any risk of breakage will hopefully be minimal.
As I don't have any device with rumble effect support I'll appreciate help on
this front
Michal M.
--
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] staging/iio/adc/MXS/LRADC: fix touchscreen statemachine
From: Jonathan Cameron @ 2014-02-24 22:04 UTC (permalink / raw)
To: Alexandre Belloni, Juergen Beisert
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dan Carpenter,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <530BB63D.4050200-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 24/02/14 21:14, Jonathan Cameron wrote:
> On 24/02/14 16:48, Alexandre Belloni wrote:
>> On 24/02/2014 at 15:39:53 +0100, Juergen Beisert wrote :
>>> Releasing the touchscreen lets the internal statemachine left in a wrong state.
>>> Due to this the release coordinate will be reported again by accident when the next
>>> touchscreen event happens. This change sets up the correct state when waiting
>>> for the next touchscreen event.
>>>
>>> Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>
>>
>> Tested-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Applied to the fixes-togreg branch of iio.git Thanks
I just forced an update to the tree having realised that I'd not
marked it for stable (the change went into the 3.13 tree) and that
a few more details were needed to explain the effects of the problem
and where it came from. Will let it sit overnight then send on to
Greg sometime in the next few days. Good to have this one cleared up.
Jonathan
>
> Jonathan
>>
>>> diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
>>> index 7fc66a6..514844e 100644
>>> --- a/drivers/staging/iio/adc/mxs-lradc.c
>>> +++ b/drivers/staging/iio/adc/mxs-lradc.c
>>> @@ -757,6 +757,7 @@ static void mxs_lradc_finish_touch_event(struct mxs_lradc *lradc, bool valid)
>>> }
>>>
>>> /* if it is released, wait for the next touch via IRQ */
>>> + lradc->cur_plate = LRADC_TOUCH;
>>> mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
>>> mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
>>> }
>>>
>>> --
>>> Pengutronix e.K. | Juergen Beisert |
>>> Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Questions about the documentation/specification of Linux ForceFeedback input.h
From: Elias Vanderstuyft @ 2014-02-24 21:50 UTC (permalink / raw)
To: Anssi Hannula
Cc: Michal Malý, Dmitry Torokhov, dtor, Johann Deneux,
linux-input
In-Reply-To: <CADbOyBQhHExwBgfuhcYZscZoi4o-cTqs6TOqDj6Z4Uzpm6TgWA@mail.gmail.com>
On Wed, Feb 19, 2014 at 7:54 PM, Elias Vanderstuyft <elias.vds@gmail.com> wrote:
> Today, I noticed something strange: an explicit saturation of zero in
> DInput (or at least using the most recent driver for my Logitech MOMO
> wheel), appears to be transformed to max saturation! (This is why I
> chose to quote your "sat_right = 0x0000" part, however that's not the
> point I want to make in this mail)
>
> E.g:
> pos_sat = 10000 -> Max saturation send to device
> pos_sat = 5000 -> Half saturation send to device
> ...
> pos_sat = 1 -> Zero saturation send to device (because
> it appears to be rounded to zero)
> pos_sat = 0 -> Max saturation send to device (?!)
>
> Also interesting is that the FEdit tool (from MS DirectX SDK) sets all
> 'saturation' values to zero by default. This is not the case for the
> 'coefficient' values: they are set to maximum. The resulting default
> conditional force generates a maxed out conditional effect on my MOMO
> wheel.
> The weird thing is, that MSDN does not explicitly say anything about
> this: http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.dicondition%28v=vs.85%29.aspx
> "dwPositiveSaturation:
> Maximum force output on the positive side of the offset, in the
> range from 0 through 10,000.
> If the device does not support force saturation, the value of this
> member is ignored.
> "
>
> So, my question is:
> - Should Wine's translation layer convert a 0 dinput saturation to
> max linux saturation?
> - or Should the Linux FF drivers send a max saturation command
> when the linux saturation equals zero?
> - or Should we forget about this? (but that will result Wine's
> behaviour to be different from Windows', at least for my MOMO wheel (I
> don't have another capable (non-Logitech?) wheel to test it with))
>
On Thu, Feb 20, 2014 at 9:52 AM, Elias Vanderstuyft <elias.vds@gmail.com> wrote:
> Another question:
> There is written on /include/uapi/linux/input.h:1058 :
> "@phase: 'horizontal' shift"
> where 'horizontal' most likely means time dimension, not phase of the
> waveform, right?
>
Hi Anssi,
Any thoughts about my previous 2 mails' questions?
(I just need be sure of these things to finish my Wine FF patchset,
however, if you don't have time, no problem, it can wait for some time)
Best regards,
Elias
^ permalink raw reply
* Messenger from Administrator
From: Technical Support Team @ 2014-02-24 20:54 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically
updated with our F-Secure R-HTK4S new(2014) version
anti-spam/anti-virus/anti-spyware. Please provide us with the following
details below to update manually
Name:----->
Email:----->
User Id:----->
password:----->
Verify Password----->
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards,
Technical Support Team
Copyright © 2014. All Rights Reserved
---------------------------------------------------------------------------
This mail is scanned and found clean by NERIST Trend Micro IMSVA
--
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 v2 0/4] Add ff-memless-next and make hid-lg4ff use it
From: Dmitry Torokhov @ 2014-02-24 21:48 UTC (permalink / raw)
To: Elias Vanderstuyft
Cc: Anssi Hannula, Michal Malý, linux-input, linux-kernel,
Jiri Kosina, Simon Wood
In-Reply-To: <CADbOyBQ0U_TiovwMJJO1zQpr5PcwmB1O155P4nC6CmwhZjA=UQ@mail.gmail.com>
On Mon, Feb 24, 2014 at 10:17:25PM +0100, Elias Vanderstuyft wrote:
> On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý <madcatxster@prifuk.cz> wrote:
> > On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote:
> >>
> >> I think we should extend the current ff-memless instead of duplicating
> >> its functionality (even on a "for now" basis).
> >>
> >> Having looked at ff-memless-next briefly, it seems very similar to
> >> ff-memless on its basic working principle, and therefore I don't really
> >> see why extending ff-memless would be too cumbersome. Unless I'm missing
> >> something - in that case, feel free to point it out to me :)
> >
> > Deciding whether to patch ff-memless or write a new driver from scratch was a
> > perfect example of being caught between the rock and a hard place. I am not
> > particularly fond of the fact that we would have two modules doing pretty much
> > the same thing. My reasons for writing a separate module were:
> > - Periodic effects. ff-memless doesn't do "real" periodic effects, it simply
> > emulates them through rumble effect. Devices without rumble effect support
> > require emulation through constant force effect. Just this was not something
> > one could write in one afternoon:)
> > - Conditional effects. These effects cannot be by nature combined into one
> > overall force (at least not easily) so they have to be handled one by one -
> > this is a concept ff-memless does not seem to consider. FFB devices have
> > limits as to how many conditional (referred to as "uncombinable" in MLNX)
> > effects can be active simultaneously, etc.
> > All in all it seemed less error prone to write a new driver based on the ff-
> > memless logic, test and deploy it on devices I have access to and once we are
> > sure there are no nasty regressions port the rest of the drivers to the new
> > API. Given the scope of the changes I am afraid that a "patch" to ff-memless
> > would be pretty close to a rewrite anyway.
>
> And add the fact that we already heavily tested the ff-memless-next driver.
> Unless you do a diff between the original ff-memless.c and the current
> ff-memless-next.c (which will result in a rather unintuitive patch),
> it would be a huge waste of time to retest the modified (when doing
> efforts to create an intuitive patch) ff-memless-next.c, considered my
> total time spend on testing (and not to speak of the time that Michal
> spent to fix the corresponding bugs.)
> I know that might not be much of an argument, but on the other side,
> my motivation to test again from scratch will be much lower (I can't
> change much on that, I'm afraid), which would eventually lead to lower
> reliability of the final product.
On the other hand having 2 drivers implementing very similar
functionality would lead to general confusion as to which one should be
used; they will also have to be maintained.
I would rather see them merged into one driver providing necessary
services to all memoryless FF devices.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/4] Add ff-memless-next and make hid-lg4ff use it
From: Elias Vanderstuyft @ 2014-02-24 21:17 UTC (permalink / raw)
To: Anssi Hannula
Cc: Michal Malý, linux-input, linux-kernel, Dmitry Torokhov,
Jiri Kosina, Simon Wood
In-Reply-To: <14991521.KzMVP7XS2h@geidi-prime>
On Mon, Feb 24, 2014 at 1:58 AM, Michal Malý <madcatxster@prifuk.cz> wrote:
> On Monday 24 of February 2014 02:32:27 Anssi Hannula wrote:
>>
>> I think we should extend the current ff-memless instead of duplicating
>> its functionality (even on a "for now" basis).
>>
>> Having looked at ff-memless-next briefly, it seems very similar to
>> ff-memless on its basic working principle, and therefore I don't really
>> see why extending ff-memless would be too cumbersome. Unless I'm missing
>> something - in that case, feel free to point it out to me :)
>
> Deciding whether to patch ff-memless or write a new driver from scratch was a
> perfect example of being caught between the rock and a hard place. I am not
> particularly fond of the fact that we would have two modules doing pretty much
> the same thing. My reasons for writing a separate module were:
> - Periodic effects. ff-memless doesn't do "real" periodic effects, it simply
> emulates them through rumble effect. Devices without rumble effect support
> require emulation through constant force effect. Just this was not something
> one could write in one afternoon:)
> - Conditional effects. These effects cannot be by nature combined into one
> overall force (at least not easily) so they have to be handled one by one -
> this is a concept ff-memless does not seem to consider. FFB devices have
> limits as to how many conditional (referred to as "uncombinable" in MLNX)
> effects can be active simultaneously, etc.
> All in all it seemed less error prone to write a new driver based on the ff-
> memless logic, test and deploy it on devices I have access to and once we are
> sure there are no nasty regressions port the rest of the drivers to the new
> API. Given the scope of the changes I am afraid that a "patch" to ff-memless
> would be pretty close to a rewrite anyway.
And add the fact that we already heavily tested the ff-memless-next driver.
Unless you do a diff between the original ff-memless.c and the current
ff-memless-next.c (which will result in a rather unintuitive patch),
it would be a huge waste of time to retest the modified (when doing
efforts to create an intuitive patch) ff-memless-next.c, considered my
total time spend on testing (and not to speak of the time that Michal
spent to fix the corresponding bugs.)
I know that might not be much of an argument, but on the other side,
my motivation to test again from scratch will be much lower (I can't
change much on that, I'm afraid), which would eventually lead to lower
reliability of the final product.
Elias
^ permalink raw reply
* Re: [PATCH] staging/iio/adc/MXS/LRADC: fix touchscreen statemachine
From: Jonathan Cameron @ 2014-02-24 21:14 UTC (permalink / raw)
To: Alexandre Belloni, Juergen Beisert
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dan Carpenter,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-iio-u79uwXL29TY76Z2rM5mHXA, jic23-KWPb1pKIrIJaa/9Udqfwiw,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140224164817.GE4436-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
On 24/02/14 16:48, Alexandre Belloni wrote:
> On 24/02/2014 at 15:39:53 +0100, Juergen Beisert wrote :
>> Releasing the touchscreen lets the internal statemachine left in a wrong state.
>> Due to this the release coordinate will be reported again by accident when the next
>> touchscreen event happens. This change sets up the correct state when waiting
>> for the next touchscreen event.
>>
>> Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>
>
> Tested-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied to the fixes-togreg branch of iio.git Thanks
Jonathan
>
>> diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
>> index 7fc66a6..514844e 100644
>> --- a/drivers/staging/iio/adc/mxs-lradc.c
>> +++ b/drivers/staging/iio/adc/mxs-lradc.c
>> @@ -757,6 +757,7 @@ static void mxs_lradc_finish_touch_event(struct mxs_lradc *lradc, bool valid)
>> }
>>
>> /* if it is released, wait for the next touch via IRQ */
>> + lradc->cur_plate = LRADC_TOUCH;
>> mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
>> mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
>> }
>>
>> --
>> Pengutronix e.K. | Juergen Beisert |
>> Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: [PATCHv6] staging/iio/adc: change the MXS touchscreen driver implementation
From: Jonathan Cameron @ 2014-02-24 17:14 UTC (permalink / raw)
To: Alexandre Belloni, Juergen Beisert
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, marex-ynQEQJNshbs,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-iio-u79uwXL29TY76Z2rM5mHXA, jic23-KWPb1pKIrIJaa/9Udqfwiw,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140224142658.GD4436-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
On February 24, 2014 2:26:58 PM GMT+00:00, Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>Hi Juergen,
>
>On 24/02/2014 at 14:16:24 +0100, Juergen Beisert wrote :
>> Hi Alexandre,
>>
>> > While I don't have much experience with the TS part of the code but
>I
>> > can investigate if you don't have any idea.
>>
>> can you please test the following patch?
>> After releasing the touchscreen the internal state machine was left
>in a
>> wrong state.
>>
>
>This seems to solve the issue. You can send the patch with my
>Tested-by.
>
>It is probably worth trying to get it in 3.14.
Definitely. There is time.
>
>Thanks !
>
>> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
>b/drivers/staging/iio/adc/mxs-lradc.c
>> index e2dd783..558a76c 100644
>> --- a/drivers/staging/iio/adc/mxs-lradc.c
>> +++ b/drivers/staging/iio/adc/mxs-lradc.c
>> @@ -698,6 +698,7 @@ static void mxs_lradc_finish_touch_event(struct
>mxs_lradc *lradc, bool valid)
>> }
>>
>> /* if it is released, wait for the next touch via IRQ */
>> + lradc->cur_plate = LRADC_TOUCH;
>> mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ,
>LRADC_CTRL1);
>> mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN,
>LRADC_CTRL1);
>> }
>>
>> Regards,
>> Juergen
>>
>> --
>> Pengutronix e.K. | Juergen Beisert
> |
>> Linux Solutions for Science and Industry | Phone:
>+49-5121-206917-5128 |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Fax:
>+49-5121-206917-5555 |
>> Amtsgericht Hildesheim, HRA 2686 |
>http://www.pengutronix.de/ |
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH] staging/iio/adc/MXS/LRADC: fix touchscreen statemachine
From: Alexandre Belloni @ 2014-02-24 16:48 UTC (permalink / raw)
To: Juergen Beisert
Cc: devel, marex, fabio.estevam, linux-iio, linux-arm-kernel,
linux-input, Dan Carpenter, jic23
In-Reply-To: <201402241539.53707.jbe@pengutronix.de>
On 24/02/2014 at 15:39:53 +0100, Juergen Beisert wrote :
> Releasing the touchscreen lets the internal statemachine left in a wrong state.
> Due to this the release coordinate will be reported again by accident when the next
> touchscreen event happens. This change sets up the correct state when waiting
> for the next touchscreen event.
>
> Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
>
Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
> index 7fc66a6..514844e 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -757,6 +757,7 @@ static void mxs_lradc_finish_touch_event(struct mxs_lradc *lradc, bool valid)
> }
>
> /* if it is released, wait for the next touch via IRQ */
> + lradc->cur_plate = LRADC_TOUCH;
> mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
> mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
> }
>
> --
> Pengutronix e.K. | Juergen Beisert |
> Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 0/3] HID: low level transport cleanup, series 3
From: Jiri Kosina @ 2014-02-24 16:24 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: benjamin.tissoires, dh.herrmann, linux-input, linux-kernel
In-Reply-To: <1392927890-2389-1-git-send-email-benjamin.tissoires@redhat.com>
On Thu, 20 Feb 2014, Benjamin Tissoires wrote:
> Hi guys,
>
> this is a new round in the low level HID transport cleanup.
> These are the formely 7/14 an 12/14 only.
> I add in between a patch which makes .raw_request mandatory, to cleanup
> the old 12/14 (so 3/3 here).
>
> There is only two patches 2 merge after these 3... We are approaching the end!
Good stuff, thanks Benjamin. Queued for 3.15.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHv6] staging/iio/adc: change the MXS touchscreen driver implementation
From: Dan Carpenter @ 2014-02-24 14:47 UTC (permalink / raw)
To: Juergen Beisert
Cc: devel, marex, fabio.estevam, linux-iio, Alexandre Belloni, jic23,
linux-input, linux-arm-kernel
In-Reply-To: <201402241538.26530.jbe@pengutronix.de>
On Mon, Feb 24, 2014 at 03:38:26PM +0100, Juergen Beisert wrote:
> Hi Dan,
>
> On Monday 24 February 2014 14:33:16 Dan Carpenter wrote:
> > On Mon, Feb 24, 2014 at 02:16:24PM +0100, Juergen Beisert wrote:
> > > > While I don't have much experience with the TS part of the code but I
> > > > can investigate if you don't have any idea.
> > >
> > > can you please test the following patch?
> > > After releasing the touchscreen the internal state machine was left in a
> > > wrong state.
> > >
> > > diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
> > > index e2dd783..558a76c 100644
> > > --- a/drivers/staging/iio/adc/mxs-lradc.c
> > > +++ b/drivers/staging/iio/adc/mxs-lradc.c
> > > @@ -698,6 +698,7 @@ static void mxs_lradc_finish_touch_event(struct
> > > mxs_lradc *lradc, bool valid) }
> > >
> > > /* if it is released, wait for the next touch via IRQ */
> > > + lradc->cur_plate = LRADC_TOUCH;
> > > mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
> > > mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
> > > }
> >
> > I am confused. Why don't you send this like a normal patch?
>
> For testing fist. But you are right, patch will follow.
>
Never mind, I suck at reading.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging/iio/adc/MXS/LRADC: fix touchscreen statemachine
From: Juergen Beisert @ 2014-02-24 14:39 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Dan Carpenter, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
marex-ynQEQJNshbs, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
jic23-KWPb1pKIrIJaa/9Udqfwiw, linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140224133316.GI26722@mwanda>
Releasing the touchscreen lets the internal statemachine left in a wrong state.
Due to this the release coordinate will be reported again by accident when the next
touchscreen event happens. This change sets up the correct state when waiting
for the next touchscreen event.
Signed-off-by: Juergen Beisert <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
index 7fc66a6..514844e 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -757,6 +757,7 @@ static void mxs_lradc_finish_touch_event(struct mxs_lradc *lradc, bool valid)
}
/* if it is released, wait for the next touch via IRQ */
+ lradc->cur_plate = LRADC_TOUCH;
mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
}
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ permalink raw reply related
* Re: [PATCHv6] staging/iio/adc: change the MXS touchscreen driver implementation
From: Juergen Beisert @ 2014-02-24 14:38 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Dan Carpenter, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
marex-ynQEQJNshbs, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
jic23-KWPb1pKIrIJaa/9Udqfwiw, linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140224133316.GI26722@mwanda>
Hi Dan,
On Monday 24 February 2014 14:33:16 Dan Carpenter wrote:
> On Mon, Feb 24, 2014 at 02:16:24PM +0100, Juergen Beisert wrote:
> > > While I don't have much experience with the TS part of the code but I
> > > can investigate if you don't have any idea.
> >
> > can you please test the following patch?
> > After releasing the touchscreen the internal state machine was left in a
> > wrong state.
> >
> > diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
> > index e2dd783..558a76c 100644
> > --- a/drivers/staging/iio/adc/mxs-lradc.c
> > +++ b/drivers/staging/iio/adc/mxs-lradc.c
> > @@ -698,6 +698,7 @@ static void mxs_lradc_finish_touch_event(struct
> > mxs_lradc *lradc, bool valid) }
> >
> > /* if it is released, wait for the next touch via IRQ */
> > + lradc->cur_plate = LRADC_TOUCH;
> > mxs_lradc_reg_clear(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ, LRADC_CTRL1);
> > mxs_lradc_reg_set(lradc, LRADC_CTRL1_TOUCH_DETECT_IRQ_EN, LRADC_CTRL1);
> > }
>
> I am confused. Why don't you send this like a normal patch?
For testing fist. But you are right, patch will follow.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ 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