* RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dexuan Cui @ 2014-08-13 5:27 UTC (permalink / raw)
To: KY Srinivasan, Dmitry Torokhov, Vojtech Pavlik
Cc: Greg KH, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
apw@canonical.com, jasowang@redhat.com, Haiyang Zhang
In-Reply-To: <423148fadd52409a95064eca25e71340@BY2PR0301MB0711.namprd03.prod.outlook.com>
> -----Original Message-----
> From: KY Srinivasan
> > The Arch users can simply select to build i8042 into the kernel as a
> > workaround.
> >
> > The proper solution is to allow loading libps2 module even if i8042 did not
> find
> > its device. I wish I could simply drop this i8042_lock_chip and stuff, but
> > unfortunately i8042 ports are not truly independent. We need to figure a
> > way for libps2 to engage locking in i8042 if the driver is loaded, otherwise
> just
> > ignore it.
>
> When I first wrote this driver, we took the decision not to replicate all the
> code in the at keyboard driver and to
> make this a serio based driver. I like the proposal made by Dmitry here.
>
> K. Y
Thanks for explaining the background, KY!
I like Dmitry's proposal too.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dexuan Cui @ 2014-08-13 5:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: olaf@aepfle.de, Greg KH, jasowang@redhat.com,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
apw@canonical.com, Haiyang Zhang
In-Reply-To: <20140812175435.GA22386@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov
> Sent: Wednesday, August 13, 2014 1:55 AM
> > > > To decouple the dependency between the hyperv-keyboard and i8042
> > > > modules, I suppose we probably have to re-implement hyperv-
> keyboard by
> > > > using input_allocate_device(), input_register_device(), and using
> > > > input_report_key() to pass the key strokes to the high level.
> > >
> > > Yes, that would be the best thing to do,
>
> Why? The backend still delivers AT keyboard data, so why does it make
> sense to write a new driver instead of making sure you can load
> atkbd/libps2 even without i8042 loaded?
Hi Dmitry,
Thanks for pointing this out!
I didn't realize input_report_key() can't accept AT keyboard scan codes.
> > The issue is: the latest Arch Linux release doesn't have a working (virtual)
> > keyboard when it runs as Generation 2 hyper-v guest -- when it runs as
> > a "traditional" Generation 1 hyper-v guest, everything works fine.
> > I hope this patch can temporarily help Arch users if they find the issue
> > and if they can rebuild the kernel.
>
> The Arch users can simply select to build i8042 into the kernel as a
> workaround.
I agree.
> The proper solution is to allow loading libps2 module even if i8042 did
> not find its device. I wish I could simply drop this i8042_lock_chip and
> stuff, but unfortunately i8042 ports are not truly independent. We need
> to figure a way for libps2 to engage locking in i8042 if the driver is
> loaded, otherwise just ignore it.
>
> Dmitry
Yeah, this seems the right solution.
How about this:
in libps2.c let's add and export a function pointer
i8042_lock_chip_if_port_owner: it is used to replace the current
if (i8042_check_port_owner(ps2dev->serio))
i8042_lock_chip();
The function pointer has a default value NULL, and in i8042.c: i8042_init()
we set the function pointer if an i8042 device is found?
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH] hid: Add mapping for special keys on compaq ku 0133 keyboard
From: Dmitry Torokhov @ 2014-08-12 23:35 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-input
In-Reply-To: <1407885290-3067-1-git-send-email-hdegoede@redhat.com>
On Wed, Aug 13, 2014 at 01:14:50AM +0200, Hans de Goede wrote:
> The compaq ku 0133 keyboard has 8 special keys at the top:
> http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg
>
> 3 of these use standard HID usage codes from the consumer page, the 5
> others use part of the reserved 0x07 - 0x1f range.
>
> This commit adds mapping for this keyboard for these reserved codes, making
> the other 5 keys work.
Can't we just load the proper keymap through udev without writing yet another
kernel driver?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] hid: Add mapping for special keys on compaq ku 0133 keyboard
From: Hans de Goede @ 2014-08-12 23:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Hans de Goede
The compaq ku 0133 keyboard has 8 special keys at the top:
http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg
3 of these use standard HID usage codes from the consumer page, the 5
others use part of the reserved 0x07 - 0x1f range.
This commit adds mapping for this keyboard for these reserved codes, making
the other 5 keys work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/hid/Kconfig | 8 ++++++
drivers/hid/Makefile | 1 +
drivers/hid/hid-compaq.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 3 +++
5 files changed, 81 insertions(+)
create mode 100644 drivers/hid/hid-compaq.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 5e79c6a..fafd8d8 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -160,6 +160,14 @@ config HID_CHICONY
---help---
Support for Chicony Tactical pad.
+config HID_COMPAQ
+ tristate "Compaq non-fully HID-compliant devices" if EXPERT
+ depends on HID
+ default !EXPERT
+ ---help---
+ Support for Compaq devices that are not fully compliant with
+ the HID standard.
+
config HID_PRODIKEYS
tristate "Prodikeys PC-MIDI Keyboard support"
depends on HID && SND
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index a6fa6ba..560d2db 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_HID_AUREAL) += hid-aureal.o
obj-$(CONFIG_HID_BELKIN) += hid-belkin.o
obj-$(CONFIG_HID_CHERRY) += hid-cherry.o
obj-$(CONFIG_HID_CHICONY) += hid-chicony.o
+obj-$(CONFIG_HID_COMPAQ) += hid-compaq.o
obj-$(CONFIG_HID_CP2112) += hid-cp2112.o
obj-$(CONFIG_HID_CYPRESS) += hid-cypress.o
obj-$(CONFIG_HID_DRAGONRISE) += hid-dr.o
diff --git a/drivers/hid/hid-compaq.c b/drivers/hid/hid-compaq.c
new file mode 100644
index 0000000..db14ca9
--- /dev/null
+++ b/drivers/hid/hid-compaq.c
@@ -0,0 +1,68 @@
+/*
+ * HID driver for some compaq "special" devices
+ *
+ * Copyright (c) 2014 Hans de Goede <hdegoede@redhat.com>
+ *
+ * Based on hid-microsoft.c which is:
+ *
+ * Copyright (c) 1999 Andreas Gal
+ * Copyright (c) 2000-2005 Vojtech Pavlik <vojtech@suse.cz>
+ * Copyright (c) 2005 Michael Haboustak <mike-@cinci.rr.com> for Concept2, Inc
+ * Copyright (c) 2006-2007 Jiri Kosina
+ * Copyright (c) 2008 Jiri Slaby
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+#define compaq_map_key_clear(c) hid_map_usage_clear(hi, usage, bit, max, \
+ EV_KEY, (c))
+
+static int compaq_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ pr_err("compaq input map called, page %04x usage %04x\n",
+ (usage->hid & HID_USAGE_PAGE), (usage->hid & HID_USAGE));
+
+ if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
+ return 0;
+
+
+ switch (usage->hid & HID_USAGE) {
+ case 0x0011: compaq_map_key_clear(KEY_PRESENTATION); break;
+ case 0x0012: compaq_map_key_clear(KEY_ADDRESSBOOK); break;
+ case 0x0013: compaq_map_key_clear(KEY_INFO); break;
+ case 0x0014: compaq_map_key_clear(KEY_PROG1); break;
+ case 0x0015: compaq_map_key_clear(KEY_MESSENGER); break;
+ default:
+ return 0;
+ }
+ return 1;
+}
+
+static const struct hid_device_id compaq_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_COMPAQ, USB_DEVICE_ID_KU_0133_KBD) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, compaq_devices);
+
+static struct hid_driver compaq_driver = {
+ .name = "compaq",
+ .id_table = compaq_devices,
+ .input_mapping = compaq_input_mapping,
+};
+module_hid_driver(compaq_driver);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8ed66fd..3bbd87c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1754,6 +1754,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_AK1D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_COMPAQ, USB_DEVICE_ID_KU_0133_KBD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS, USB_DEVICE_ID_PRODIKEYS_PCMIDI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_CP2112) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 48b66bb..9bf2c6d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -236,6 +236,9 @@
#define USB_DEVICE_ID_CODEMERCS_IOW_FIRST 0x1500
#define USB_DEVICE_ID_CODEMERCS_IOW_LAST 0x15ff
+#define USB_VENDOR_ID_COMPAQ 0x049f
+#define USB_DEVICE_ID_KU_0133_KBD 0x0051
+
#define USB_VENDOR_ID_CREATIVELABS 0x041e
#define USB_DEVICE_ID_PRODIKEYS_PCMIDI 0x2801
--
2.0.4
^ permalink raw reply related
* Re: [PATCH] Input: atmel_mxt_ts - fix a few issues reported by Coverity
From: Nick Dyer @ 2014-08-12 21:08 UTC (permalink / raw)
To: Stephen Warren
Cc: Dmitry Torokhov, linux-input, Yufeng Shen, Benson Leung,
Stephen Warren, linux-kernel
In-Reply-To: <53EA43A4.2070301@wwwdotorg.org>
On 12/08/14 17:41, Stephen Warren wrote:
>> I've reviewed these changes and they look correct to me. Apologies that
>> they slipped through, most of it is bad merging on my part I think.
>>
>> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
>
> Don't you mean Acked-by or Reviewed-by?
You are right, Acked-by is probably more appropriate in this case.
^ permalink raw reply
* Re: Retire gamecon?
From: Dmitry Torokhov @ 2014-08-12 20:28 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, Vojtech Pavlik
In-Reply-To: <alpine.LNX.2.00.1408122212340.15220@pobox.suse.cz>
On Tue, Aug 12, 2014 at 10:17:42PM +0200, Jiri Kosina wrote:
> On Tue, 12 Aug 2014, Dmitry Torokhov wrote:
>
> > I am wondering it it is time to retire gamecon support from the kernel.
>
> Absolutely no objections from me on this, but I guess Vojtech's opinion is
> much more relevant here, as he has actually *seen* this hardware (I
> guess) :)
>
> > It hasn't been working well ever since cpufreq became mainstream and it
> > becomes increasingly hard to find hardware and software that would run
> > on such old hardware.
>
> Makes me wonder though what makes gamecon so special among other drivers
> of such kind (such as JOYSTICK_DB9, to name one randomly picked example).
Sorry, I actually meant gameport, not gamecon. I obviously did not have enough
coffee when I sent out that message.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Retire gamecon?
From: Jiri Kosina @ 2014-08-12 20:17 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Vojtech Pavlik
In-Reply-To: <20140812170722.GC5563@core.coreip.homeip.net>
On Tue, 12 Aug 2014, Dmitry Torokhov wrote:
> I am wondering it it is time to retire gamecon support from the kernel.
Absolutely no objections from me on this, but I guess Vojtech's opinion is
much more relevant here, as he has actually *seen* this hardware (I
guess) :)
> It hasn't been working well ever since cpufreq became mainstream and it
> becomes increasingly hard to find hardware and software that would run
> on such old hardware.
Makes me wonder though what makes gamecon so special among other drivers
of such kind (such as JOYSTICK_DB9, to name one randomly picked example).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Retire gamecon?
From: Vojtech Pavlik @ 2014-08-12 19:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Jiri Kosina
In-Reply-To: <20140812170722.GC5563@core.coreip.homeip.net>
On Tue, Aug 12, 2014 at 10:07:22AM -0700, Dmitry Torokhov wrote:
> I am wondering it it is time to retire gamecon support from the kernel. It
> hasn't been working well ever since cpufreq became mainstream and it becomes
> increasingly hard to find hardware and software that would run on such old
> hardware.
I assume you mean gameport? Although gamecon is perhape even more arcane.
>
> Please scream if you believe it should stay in.
>
> Thanks.
I won't scream for it.
I'll spend a moment of silence remebmering that piece of code and the twisted hardware it used to support.
--
Vojtech Pavlik
Director SUSE Labs
^ permalink raw reply
* Re: [RESEND: PATCH 1/2] mfd: tc3589x: Add device tree bindings
From: Linus Walleij @ 2014-08-12 18:02 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree@vger.kernel.org, Dmitry Torokhov, Linux Input,
Samuel Ortiz, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <20140617202340.GW29841@lee--X1>
On Tue, Jun 17, 2014 at 10:23 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 09 Apr 2014, Linus Walleij wrote:
>
>> This defines the device tree bindings for the Toshiba TC3589x
>> series of multi-purpose expanders. Only the stuff I can test
>> is defined: GPIO and keypad. Others may implement more
>> subdevices further down the road.
>>
>> This is to complement
>> commit a435ae1d51e2f18414f2a87219fdbe068231e692
>> "mfd: Enable the tc3589x for Device Tree" which left off
>> the definition of the device tree bindings.
>>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v2->v3:
>> - Fix the keys/rows bindings to be u32 rather than
>> /bits/ 8, inconsistency noted by Mark Rutland.
>> ChangeLog v1->v2:
>> - Include a verbose example in the DT bindings.
>> - Explain why this is a stand-alone bindings patch.
>> ---
>> Documentation/devicetree/bindings/mfd/tc3589x.txt | 107 ++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/tc3589x.txt
>
> Looks about right, been on the list for ages and doesn't add any new
> properties. Applied, thanks.
This wasn't in the v3.17 pull request AFAICT :-(
Did it get dropped to the floor accidentally?
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: KY Srinivasan @ 2014-08-12 18:01 UTC (permalink / raw)
To: Dmitry Torokhov, Dexuan Cui, Vojtech Pavlik
Cc: olaf@aepfle.de, Greg KH, jasowang@redhat.com,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
apw@canonical.com, Haiyang Zhang
In-Reply-To: <20140812175435.GA22386@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Tuesday, August 12, 2014 10:55 AM
> To: Dexuan Cui
> Cc: Greg KH; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org;
> driverdev-devel@linuxdriverproject.org; olaf@aepfle.de;
> apw@canonical.com; jasowang@redhat.com; KY Srinivasan; Haiyang Zhang
> Subject: Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on
> SERIO_I8042=y
>
> On Tue, Aug 12, 2014 at 07:15:25AM +0000, Dexuan Cui wrote:
> > > -----Original Message-----
> > > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > > owner@vger.kernel.org] On Behalf Of Greg KH
> > > > > What exactly needs to be done to fix this "correctly" that is
> > > > > going to take too much work at the moment?
> > > >
> > > > To decouple the dependency between the hyperv-keyboard and i8042
> > > > modules, I suppose we probably have to re-implement
> > > > hyperv-keyboard by using input_allocate_device(),
> > > > input_register_device(), and using
> > > > input_report_key() to pass the key strokes to the high level.
> > >
> > > Yes, that would be the best thing to do,
>
> Why? The backend still delivers AT keyboard data, so why does it make sense
> to write a new driver instead of making sure you can load
> atkbd/libps2 even without i8042 loaded?
>
> > > and shouldn't be that hard to
> > > create an input driver, it's pretty simple code, right?
> > Hi Greg,
> > Thanks for the confirmation!
> > I didn't use the APIs before.
> > I think I need a couple of days to code, test and debug it while I
> > have many things at hand at present. :-(
> >
> > > > I'll have to need some time for further investigation and a new
> > > > implementation. Before the new code is completely ready, IMHO the
> > > > patch can help to avoid a bad user experience like Arch Linux
> > > > working as a Generation 2 hyper-v guest.
> > >
> > > You are still preventing Arch from working here, as the driver can't
> > > be built at all, right?
> > The driver can build(compile) fine.
> > The issue is: the latest Arch Linux release doesn't have a working
> > (virtual) keyboard when it runs as Generation 2 hyper-v guest -- when
> > it runs as a "traditional" Generation 1 hyper-v guest, everything works fine.
> > I hope this patch can temporarily help Arch users if they find the
> > issue and if they can rebuild the kernel.
>
> The Arch users can simply select to build i8042 into the kernel as a
> workaround.
>
> The proper solution is to allow loading libps2 module even if i8042 did not find
> its device. I wish I could simply drop this i8042_lock_chip and stuff, but
> unfortunately i8042 ports are not truly independent. We need to figure a
> way for libps2 to engage locking in i8042 if the driver is loaded, otherwise just
> ignore it.
When I first wrote this driver, we took the decision not to replicate all the code in the at keyboard driver and to
make this a serio based driver. I like the proposal made by Dmitry here.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dmitry Torokhov @ 2014-08-12 17:54 UTC (permalink / raw)
To: Dexuan Cui
Cc: olaf@aepfle.de, Greg KH, jasowang@redhat.com,
driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
apw@canonical.com, Haiyang Zhang
In-Reply-To: <EE124450C0AAF944A40DD71E61F878C9920EAF@SINEX14MBXC417.southpacific.corp.microsoft.com>
On Tue, Aug 12, 2014 at 07:15:25AM +0000, Dexuan Cui wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > > > What exactly needs to be done to fix this "correctly" that is going to
> > > > take too much work at the moment?
> > >
> > > To decouple the dependency between the hyperv-keyboard and i8042
> > > modules, I suppose we probably have to re-implement hyperv-keyboard by
> > > using input_allocate_device(), input_register_device(), and using
> > > input_report_key() to pass the key strokes to the high level.
> >
> > Yes, that would be the best thing to do,
Why? The backend still delivers AT keyboard data, so why does it make
sense to write a new driver instead of making sure you can load
atkbd/libps2 even without i8042 loaded?
> > and shouldn't be that hard to
> > create an input driver, it's pretty simple code, right?
> Hi Greg,
> Thanks for the confirmation!
> I didn't use the APIs before.
> I think I need a couple of days to code, test and debug it while I have many
> things at hand at present. :-(
>
> > > I'll have to need some time for further investigation and a new
> > > implementation. Before the new code is completely ready, IMHO the
> > > patch can help to avoid a bad user experience like Arch Linux working
> > > as a Generation 2 hyper-v guest.
> >
> > You are still preventing Arch from working here, as the driver can't be
> > built at all, right?
> The driver can build(compile) fine.
> The issue is: the latest Arch Linux release doesn't have a working (virtual)
> keyboard when it runs as Generation 2 hyper-v guest -- when it runs as
> a "traditional" Generation 1 hyper-v guest, everything works fine.
> I hope this patch can temporarily help Arch users if they find the issue
> and if they can rebuild the kernel.
The Arch users can simply select to build i8042 into the kernel as a
workaround.
The proper solution is to allow loading libps2 module even if i8042 did
not find its device. I wish I could simply drop this i8042_lock_chip and
stuff, but unfortunately i8042 ports are not truly independent. We need
to figure a way for libps2 to engage locking in i8042 if the driver is
loaded, otherwise just ignore it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input/joystick: use get_cycles on ARMv8
From: Mark Brown @ 2014-08-12 17:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linaro-kernel
In-Reply-To: <20140812170149.GB5563@core.coreip.homeip.net>
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
On Tue, Aug 12, 2014 at 10:01:49AM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 11, 2014 at 04:42:10PM +0100, Mark Brown wrote:
> > As with ARM the ARMv8 architecture provides a cycle counter which can be
> > used to provide a high resolution time for the joystick driver and silence
> > the build warning that results from not having a precise timer on ARMv8,
> > making allmodconfig and allyesconfig quieter.
> Applied, although I wonder if it is time to retire whole gamecon subsystem. I
> don't think there are many users left...
OTOH it doesn't really do much harm either, the rate of updates seems
pretty low. I was wondering about converting the warning to a runtime
one - it'll probably be more likely to be seen by anyone who is using it
and makes for less of these porting issues but I couldn't quite find the
motivation.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5] input: drv260x: Add TI drv260x haptics driver
From: Murphy, Dan @ 2014-08-12 17:29 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Rutland
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
madcatxster-ths1gS3I5ePJhNtt2C1UgaxOck334EZe@public.gmane.org,
simon-wM4F9T/ekXmXDw4h08c5KA@public.gmane.org,
elias.vds-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20140807061630.GC651@core.coreip.homeip.net>
On 08/07/2014 01:16 AM, Dmitry Torokhov wrote:
> On Wed, Aug 06, 2014 at 07:47:25PM +0000, Murphy, Dan wrote:
>> Bump
>>
>> On 07/31/2014 02:14 PM, Murphy, Dan wrote:
>>> Add the TI drv260x haptics/vibrator driver.
>>> This device uses the input force feedback
>>> to produce a wave form to driver an
>>> ERM or LRA actuator device.
>>>
>>> The initial driver supports the devices
>>> real time playback mode. But the device
>>> has additional wave patterns in ROM.
>>>
>>> This functionality will be added in
>>> future patchsets.
>>>
>>> Product data sheet is located here:
>>> http://www.ti.com/product/drv2605
>>>
>>> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>>> ---
>>>
>>> v5 - Move register defines to c file and rm header file, error check
>>> init in probe, fixed identation, remove empty labels in probe
>>> and just return on fail and removed the remove callback and function.
>>> Did not factor out the suspend into a stop function. - https://patchwork.kernel.org/patch/4649631/
>>> v4 - Convert regulator to devm, added error checking where required,
>>> updated bindings doc, moved dt parsing to separate call and made platform
>
> Mark, are you OK with this new updated binding?
>
Mark?
>>> data the first data point, moved vibrator enable and mode programming from
>>> play entry to worker thread, added user check and input mutex in suspend/resume
>>> calls, moved platform data to individual file and into include platform-data directory,
>>> removed file names from file headers - https://patchwork.kernel.org/patch/4642221/
>>> v3 - Updated binding doc, changed to memless device, updated input alloc to
>>> devm, removed mutex locking, add sanity checks for mode and library - https://patchwork.kernel.org/patch/4635421/
>>> v2 - Fixed binding doc and patch headline - https://patchwork.kernel.org/patch/4619641/
>>>
>>>
>>> .../devicetree/bindings/input/ti,drv260x.txt | 50 ++
>>> drivers/input/misc/Kconfig | 9 +
>>> drivers/input/misc/Makefile | 1 +
>>> drivers/input/misc/drv260x.c | 697 ++++++++++++++++++++
>>> include/dt-bindings/input/ti-drv260x.h | 35 +
>>> include/linux/platform_data/drv260x-pdata.h | 29 +
>>> 6 files changed, 821 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
>>> create mode 100644 drivers/input/misc/drv260x.c
>>> create mode 100644 include/dt-bindings/input/ti-drv260x.h
>>> create mode 100644 include/linux/platform_data/drv260x-pdata.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt
>>> new file mode 100644
>>> index 0000000..8e6970d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
>>> @@ -0,0 +1,50 @@
>>> +Texas Instruments - drv260x Haptics driver family
>>> +
>>> +The drv260x family serial control bus communicates through I2C protocols
>>> +
>>> +Required properties:
>>> + - compatible - One of:
>>> + "ti,drv2604" - DRV2604
>>> + "ti,drv2605" - DRV2605
>>> + "ti,drv2605l" - DRV2605L
>>> + - reg - I2C slave address
>>> + - supply- Required supply regulators are:
>>> + "vbat" - battery voltage
>>> + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h)
>>> + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric)
>>> + DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration
>>> + sequence during init. And the device is configured for real
>>> + time playback mode (RTP mode).
>>> + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator)
>>> + - library-sel - These are ROM based waveforms pre-programmed into the IC.
>>> + This should be set to set the library to use at power up.
>>> + (defined in include/dt-bindings/input/ti-drv260x.h)
>>> + DRV260X_LIB_A - Pre-programmed Library
>>> + DRV260X_LIB_B - Pre-programmed Library
>>> + DRV260X_LIB_C - Pre-programmed Library
>>> + DRV260X_LIB_D - Pre-programmed Library
>>> + DRV260X_LIB_E - Pre-programmed Library
>>> + DRV260X_LIB_F - Pre-programmed Library
>>> +
>>> +Optional properties:
>>> + - enable-gpio - gpio pin to enable/disable the device.
>>> + - vib_rated_voltage - The rated voltage of the actuator in millivolts.
>>> + If this is not set then the value will be defaulted to
>>> + 3.2 v.
>>> + - vib_overdrive_voltage - The overdrive voltage of the actuator in millivolts.
>>> + If this is not set then the value will be defaulted to
>>> + 3.2 v.
>>> +Example:
>>> +
>>> +drv2605l: drv2605l@5a {
>>> + compatible = "ti,drv2605l";
>>> + reg = <0x5a>;
>>> + enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
>>> + mode = <DRV260X_LRA_MODE>;
>>> + library-sel = <DRV260X_LIB_SEL_DEFAULT>;
>>> + vib-rated-voltage = <3200>;
>>> + vib-overdriver-voltage = <3200>;
>>> +};
>>> +
>>> +For more product information please see the link below:
>>> +http://www.ti.com/product/drv2605
>>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>>> index 2ff4425..99f6762 100644
>>> --- a/drivers/input/misc/Kconfig
>>> +++ b/drivers/input/misc/Kconfig
>>> @@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
>>> To compile this driver as a module, choose M here: the
>>> module will be called soc_button_array.
>>>
>>> +config INPUT_DRV260X_HAPTICS
>>> + tristate "TI DRV260X haptics support"
>>> + depends on INPUT && I2C
>>> + help
>>> + Say Y to enable support for the TI DRV260X haptics driver.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> + module will be called drv260x-haptics.
>>> +
>>> endif
>>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>>> index 4955ad3..d8ef3c7 100644
>>> --- a/drivers/input/misc/Makefile
>>> +++ b/drivers/input/misc/Makefile
>>> @@ -64,3 +64,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
>>> obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
>>> obj-$(CONFIG_INPUT_YEALINK) += yealink.o
>>> obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
>>> +obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
>>> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
>>> new file mode 100644
>>> index 0000000..6ccdeff
>>> --- /dev/null
>>> +++ b/drivers/input/misc/drv260x.c
>>> @@ -0,0 +1,697 @@
>>> +/*
>>> + * DRV260X haptics driver family
>>> + *
>>> + * Author: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>>> + *
>>> + * Copyright: (C) 2014 Texas Instruments, Inc.
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/input.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_gpio.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/regulator/consumer.h>
>>> +
>>> +#include <dt-bindings/input/ti-drv260x.h>
>>> +#include <linux/platform_data/drv260x-pdata.h>
>>> +
>>> +#define DRV260X_STATUS 0x0
>>> +#define DRV260X_MODE 0x1
>>> +#define DRV260X_RT_PB_IN 0x2
>>> +#define DRV260X_LIB_SEL 0x3
>>> +#define DRV260X_WV_SEQ_1 0x4
>>> +#define DRV260X_WV_SEQ_2 0x5
>>> +#define DRV260X_WV_SEQ_3 0x6
>>> +#define DRV260X_WV_SEQ_4 0x7
>>> +#define DRV260X_WV_SEQ_5 0x8
>>> +#define DRV260X_WV_SEQ_6 0x9
>>> +#define DRV260X_WV_SEQ_7 0xa
>>> +#define DRV260X_WV_SEQ_8 0xb
>>> +#define DRV260X_GO 0xc
>>> +#define DRV260X_OVERDRIVE_OFF 0xd
>>> +#define DRV260X_SUSTAIN_P_OFF 0xe
>>> +#define DRV260X_SUSTAIN_N_OFF 0xf
>>> +#define DRV260X_BRAKE_OFF 0x10
>>> +#define DRV260X_A_TO_V_CTRL 0x11
>>> +#define DRV260X_A_TO_V_MIN_INPUT 0x12
>>> +#define DRV260X_A_TO_V_MAX_INPUT 0x13
>>> +#define DRV260X_A_TO_V_MIN_OUT 0x14
>>> +#define DRV260X_A_TO_V_MAX_OUT 0x15
>>> +#define DRV260X_RATED_VOLT 0x16
>>> +#define DRV260X_OD_CLAMP_VOLT 0x17
>>> +#define DRV260X_CAL_COMP 0x18
>>> +#define DRV260X_CAL_BACK_EMF 0x19
>>> +#define DRV260X_FEEDBACK_CTRL 0x1a
>>> +#define DRV260X_CTRL1 0x1b
>>> +#define DRV260X_CTRL2 0x1c
>>> +#define DRV260X_CTRL3 0x1d
>>> +#define DRV260X_CTRL4 0x1e
>>> +#define DRV260X_CTRL5 0x1f
>>> +#define DRV260X_LRA_LOOP_PERIOD 0x20
>>> +#define DRV260X_VBAT_MON 0x21
>>> +#define DRV260X_LRA_RES_PERIOD 0x22
>>> +#define DRV260X_MAX_REG 0x23
>>> +
>>> +#define DRV260X_ALLOWED_R_BYTES 25
>>> +#define DRV260X_ALLOWED_W_BYTES 2
>>> +#define DRV260X_MAX_RW_RETRIES 5
>>> +#define DRV260X_I2C_RETRY_DELAY 10
>>> +
>>> +#define DRV260X_GO_BIT 0x01
>>> +
>>> +/* Library Selection */
>>> +#define DRV260X_LIB_SEL_MASK 0x07
>>> +#define DRV260X_LIB_SEL_RAM 0x0
>>> +#define DRV260X_LIB_SEL_OD 0x1
>>> +#define DRV260X_LIB_SEL_40_60 0x2
>>> +#define DRV260X_LIB_SEL_60_80 0x3
>>> +#define DRV260X_LIB_SEL_100_140 0x4
>>> +#define DRV260X_LIB_SEL_140_PLUS 0x5
>>> +
>>> +#define DRV260X_LIB_SEL_HIZ_MASK 0x10
>>> +#define DRV260X_LIB_SEL_HIZ_EN 0x01
>>> +#define DRV260X_LIB_SEL_HIZ_DIS 0
>>> +
>>> +/* Mode register */
>>> +#define DRV260X_STANDBY (1 << 6)
>>> +#define DRV260X_STANDBY_MASK 0x40
>>> +#define DRV260X_INTERNAL_TRIGGER 0x00
>>> +#define DRV260X_EXT_TRIGGER_EDGE 0x01
>>> +#define DRV260X_EXT_TRIGGER_LEVEL 0x02
>>> +#define DRV260X_PWM_ANALOG_IN 0x03
>>> +#define DRV260X_AUDIOHAPTIC 0x04
>>> +#define DRV260X_RT_PLAYBACK 0x05
>>> +#define DRV260X_DIAGNOSTICS 0x06
>>> +#define DRV260X_AUTO_CAL 0x07
>>> +
>>> +/* Audio to Haptics Control */
>>> +#define DRV260X_AUDIO_HAPTICS_PEAK_10MS (0 << 2)
>>> +#define DRV260X_AUDIO_HAPTICS_PEAK_20MS (1 << 2)
>>> +#define DRV260X_AUDIO_HAPTICS_PEAK_30MS (2 << 2)
>>> +#define DRV260X_AUDIO_HAPTICS_PEAK_40MS (3 << 2)
>>> +
>>> +#define DRV260X_AUDIO_HAPTICS_FILTER_100HZ 0x00
>>> +#define DRV260X_AUDIO_HAPTICS_FILTER_125HZ 0x01
>>> +#define DRV260X_AUDIO_HAPTICS_FILTER_150HZ 0x02
>>> +#define DRV260X_AUDIO_HAPTICS_FILTER_200HZ 0x03
>>> +
>>> +/* Min/Max Input/Output Voltages */
>>> +#define DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT 0x19
>>> +#define DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT 0x64
>>> +#define DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT 0x19
>>> +#define DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT 0xFF
>>> +
>>> +/* Feedback register */
>>> +#define DRV260X_FB_REG_ERM_MODE 0x7f
>>> +#define DRV260X_FB_REG_LRA_MODE (1 << 7)
>>> +
>>> +#define DRV260X_BRAKE_FACTOR_MASK 0x1f
>>> +#define DRV260X_BRAKE_FACTOR_2X (1 << 0)
>>> +#define DRV260X_BRAKE_FACTOR_3X (2 << 4)
>>> +#define DRV260X_BRAKE_FACTOR_4X (3 << 4)
>>> +#define DRV260X_BRAKE_FACTOR_6X (4 << 4)
>>> +#define DRV260X_BRAKE_FACTOR_8X (5 << 4)
>>> +#define DRV260X_BRAKE_FACTOR_16 (6 << 4)
>>> +#define DRV260X_BRAKE_FACTOR_DIS (7 << 4)
>>> +
>>> +#define DRV260X_LOOP_GAIN_LOW 0xf3
>>> +#define DRV260X_LOOP_GAIN_MED (1 << 2)
>>> +#define DRV260X_LOOP_GAIN_HIGH (2 << 2)
>>> +#define DRV260X_LOOP_GAIN_VERY_HIGH (3 << 2)
>>> +
>>> +#define DRV260X_BEMF_GAIN_0 0xfc
>>> +#define DRV260X_BEMF_GAIN_1 (1 << 0)
>>> +#define DRV260X_BEMF_GAIN_2 (2 << 0)
>>> +#define DRV260X_BEMF_GAIN_3 (3 << 0)
>>> +
>>> +/* Control 1 register */
>>> +#define DRV260X_AC_CPLE_EN (1 << 5)
>>> +#define DRV260X_STARTUP_BOOST (1 << 7)
>>> +
>>> +/* Control 2 register */
>>> +
>>> +#define DRV260X_IDISS_TIME_45 0
>>> +#define DRV260X_IDISS_TIME_75 (1 << 0)
>>> +#define DRV260X_IDISS_TIME_150 (1 << 1)
>>> +#define DRV260X_IDISS_TIME_225 0x03
>>> +
>>> +#define DRV260X_BLANK_TIME_45 (0 << 2)
>>> +#define DRV260X_BLANK_TIME_75 (1 << 2)
>>> +#define DRV260X_BLANK_TIME_150 (2 << 2)
>>> +#define DRV260X_BLANK_TIME_225 (3 << 2)
>>> +
>>> +#define DRV260X_SAMP_TIME_150 (0 << 4)
>>> +#define DRV260X_SAMP_TIME_200 (1 << 4)
>>> +#define DRV260X_SAMP_TIME_250 (2 << 4)
>>> +#define DRV260X_SAMP_TIME_300 (3 << 4)
>>> +
>>> +#define DRV260X_BRAKE_STABILIZER (1 << 6)
>>> +#define DRV260X_UNIDIR_IN (0 << 7)
>>> +#define DRV260X_BIDIR_IN (1 << 7)
>>> +
>>> +/* Control 3 Register */
>>> +#define DRV260X_LRA_OPEN_LOOP (1 << 0)
>>> +#define DRV260X_ANANLOG_IN (1 << 1)
>>> +#define DRV260X_LRA_DRV_MODE (1 << 2)
>>> +#define DRV260X_RTP_UNSIGNED_DATA (1 << 3)
>>> +#define DRV260X_SUPPLY_COMP_DIS (1 << 4)
>>> +#define DRV260X_ERM_OPEN_LOOP (1 << 5)
>>> +#define DRV260X_NG_THRESH_0 (0 << 6)
>>> +#define DRV260X_NG_THRESH_2 (1 << 6)
>>> +#define DRV260X_NG_THRESH_4 (2 << 6)
>>> +#define DRV260X_NG_THRESH_8 (3 << 6)
>>> +
>>> +/* Control 4 Register */
>>> +#define DRV260X_AUTOCAL_TIME_150MS (0 << 4)
>>> +#define DRV260X_AUTOCAL_TIME_250MS (1 << 4)
>>> +#define DRV260X_AUTOCAL_TIME_500MS (2 << 4)
>>> +#define DRV260X_AUTOCAL_TIME_1000MS (3 << 4)
>>> +
>>> +/**
>>> + * struct drv260x_data -
>>> + * @input_dev - Pointer to the input device
>>> + * @client - Pointer to the I2C client
>>> + * @regmap - Register map of the device
>>> + * @work - Work item used to off load the enable/disable of the vibration
>>> + * @enable_gpio - Pointer to the gpio used for enable/disabling
>>> + * @regulator - Pointer to the regulator for the IC
>>> + * @magnitude - Magnitude of the vibration event
>>> + * @mode - The operating mode of the IC (LRA_NO_CAL, ERM or LRA)
>>> + * @library - The vibration library to be used
>>> + * @rated_voltage - The rated_voltage of the actuator
>>> + * @overdriver_voltage - The over drive voltage of the actuator
>>> +**/
>>> +struct drv260x_data {
>>> + struct input_dev *input_dev;
>>> + struct i2c_client *client;
>>> + struct regmap *regmap;
>>> + struct work_struct work;
>>> + struct gpio_desc *enable_gpio;
>>> + struct regulator *regulator;
>>> + u32 magnitude;
>>> + u32 mode;
>>> + u32 library;
>>> + int rated_voltage;
>>> + int overdrive_voltage;
>>> +};
>>> +
>>> +static struct reg_default drv260x_reg_defs[] = {
>>> + { DRV260X_STATUS, 0xe0 },
>>> + { DRV260X_MODE, 0x40 },
>>> + { DRV260X_RT_PB_IN, 0x00},
>>> + { DRV260X_LIB_SEL, 0x00},
>>> + { DRV260X_WV_SEQ_1, 0x01},
>>> + { DRV260X_WV_SEQ_2, 0x00},
>>> + { DRV260X_WV_SEQ_3, 0x00},
>>> + { DRV260X_WV_SEQ_4, 0x00},
>>> + { DRV260X_WV_SEQ_5, 0x00},
>>> + { DRV260X_WV_SEQ_6, 0x00},
>>> + { DRV260X_WV_SEQ_7, 0x00},
>>> + { DRV260X_WV_SEQ_8, 0x00},
>>> + { DRV260X_GO, 0x00},
>>> + { DRV260X_OVERDRIVE_OFF, 0x00},
>>> + { DRV260X_SUSTAIN_P_OFF, 0x00},
>>> + { DRV260X_SUSTAIN_N_OFF, 0x00},
>>> + { DRV260X_BRAKE_OFF , 0x00},
>>> + { DRV260X_A_TO_V_CTRL , 0x05},
>>> + { DRV260X_A_TO_V_MIN_INPUT, 0x19},
>>> + { DRV260X_A_TO_V_MAX_INPUT, 0xff},
>>> + { DRV260X_A_TO_V_MIN_OUT, 0x19},
>>> + { DRV260X_A_TO_V_MAX_OUT, 0xff},
>>> + { DRV260X_RATED_VOLT, 0x3e},
>>> + { DRV260X_OD_CLAMP_VOLT, 0x8c},
>>> + { DRV260X_CAL_COMP, 0x0c},
>>> + { DRV260X_CAL_BACK_EMF, 0x6c},
>>> + { DRV260X_FEEDBACK_CTRL, 0x36},
>>> + { DRV260X_CTRL1, 0x93},
>>> + { DRV260X_CTRL2, 0xfa},
>>> + { DRV260X_CTRL3, 0xa0},
>>> + { DRV260X_CTRL4, 0x20},
>>> + { DRV260X_CTRL5, 0x80},
>>> + { DRV260X_LRA_LOOP_PERIOD, 0x33},
>>> + { DRV260X_VBAT_MON, 0x00},
>>> + { DRV260X_LRA_RES_PERIOD, 0x00},
>>> +};
>>> +
>>> +/**
>>> + * Rated and Overdriver Voltages:
>>> + * Calculated using the formula r = v * 255 / 5.6
>>> + * where r is what will be written to the register
>>> + * and v is the rated or overdriver voltage of the actuator
>>> + **/
>>> +#define DRV260X_DEF_RATED_VOLT 0x90
>>> +#define DRV260X_DEF_OD_CLAMP_VOLT 0x90
>>> +
>>> +static int drv260x_calculate_voltage(int voltage)
>>> +{
>>> + return (voltage * 255 / 5600);
>>> +}
>>> +
>>> +static void drv260x_worker(struct work_struct *work)
>>> +{
>>> + struct drv260x_data *haptics = container_of(work, struct drv260x_data, work);
>>> + int ret;
>>> +
>>> + gpiod_set_value(haptics->enable_gpio, 1);
>>> + /* Data sheet says to wait 250us before trying to communicate */
>>> + udelay(250);
>>> +
>>> + ret = regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_RT_PLAYBACK);
>>> + if (ret != 0) {
>>> + dev_err(&haptics->client->dev,
>>> + "Failed to write set mode: %d\n", ret);
>>> + return;
>>> + }
>>> +
>>> + ret = regmap_write(haptics->regmap, DRV260X_RT_PB_IN, haptics->magnitude);
>>> + if (ret != 0) {
>>> + dev_err(&haptics->client->dev,
>>> + "Failed to set magnitude: %d\n", ret);
>>> + }
>>> +}
>>> +
>>> +static int drv260x_haptics_play(struct input_dev *input, void *data,
>>> + struct ff_effect *effect)
>>> +{
>>> + struct drv260x_data *haptics = input_get_drvdata(input);
>>> +
>>> + haptics->mode = DRV260X_LRA_NO_CAL_MODE;
>>> + haptics->magnitude = 0;
>>> +
>>> + if (effect->u.rumble.strong_magnitude ||
>>> + effect->u.rumble.weak_magnitude) {
>>> + if (effect->u.rumble.strong_magnitude > 0)
>>> + haptics->magnitude = effect->u.rumble.strong_magnitude;
>>> + else if (effect->u.rumble.weak_magnitude > 0)
>>> + haptics->magnitude = effect->u.rumble.weak_magnitude;
>>> + }
>>> +
>>> + schedule_work(&haptics->work);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void drv260x_close(struct input_dev *input)
>>> +{
>>> + struct drv260x_data *haptics = input_get_drvdata(input);
>>> + int ret;
>>> +
>>> + cancel_work_sync(&haptics->work);
>>> +
>>> + ret = regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_STANDBY);
>>> + if (ret != 0) {
>>> + dev_err(&haptics->client->dev,
>>> + "Failed to write standby mode: %d\n", ret);
>>> + }
>>> +
>>> + gpiod_set_value(haptics->enable_gpio, 0);
>>> +}
>>> +
>>> +static const struct reg_default drv260x_lra_cal_regs[] = {
>>> + { DRV260X_MODE, DRV260X_AUTO_CAL },
>>> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2},
>>> + { DRV260X_FEEDBACK_CTRL, DRV260X_FB_REG_LRA_MODE | DRV260X_BRAKE_FACTOR_4X | DRV260X_LOOP_GAIN_HIGH },
>>> +};
>>> +
>>> +static const struct reg_default drv260x_lra_init_regs[] = {
>>> + { DRV260X_MODE, DRV260X_RT_PLAYBACK},
>>> + { DRV260X_A_TO_V_CTRL, DRV260X_AUDIO_HAPTICS_PEAK_20MS | DRV260X_AUDIO_HAPTICS_FILTER_125HZ},
>>> + { DRV260X_A_TO_V_MIN_INPUT, DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT },
>>> + { DRV260X_A_TO_V_MAX_INPUT, DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT },
>>> + { DRV260X_A_TO_V_MIN_OUT, DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT },
>>> + { DRV260X_A_TO_V_MAX_OUT, DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT },
>>> + { DRV260X_FEEDBACK_CTRL, DRV260X_FB_REG_LRA_MODE | DRV260X_BRAKE_FACTOR_2X | DRV260X_LOOP_GAIN_MED | DRV260X_BEMF_GAIN_3 },
>>> + { DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
>>> + { DRV260X_CTRL2, DRV260X_SAMP_TIME_250 },
>>> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ANANLOG_IN },
>>> + { DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
>>> +};
>>> +
>>> +static const struct reg_default drv260x_erm_cal_regs[] = {
>>> + { DRV260X_MODE, DRV260X_AUTO_CAL },
>>> + { DRV260X_A_TO_V_MIN_INPUT, DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT },
>>> + { DRV260X_A_TO_V_MAX_INPUT, DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT },
>>> + { DRV260X_A_TO_V_MIN_OUT, DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT },
>>> + { DRV260X_A_TO_V_MAX_OUT, DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT },
>>> + { DRV260X_FEEDBACK_CTRL, DRV260X_BRAKE_FACTOR_3X | DRV260X_LOOP_GAIN_MED | DRV260X_BEMF_GAIN_2 },
>>> + { DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
>>> + { DRV260X_CTRL2, DRV260X_SAMP_TIME_250 | DRV260X_BLANK_TIME_75 | DRV260X_SAMP_TIME_250 | DRV260X_IDISS_TIME_75 },
>>> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ERM_OPEN_LOOP },
>>> + { DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
>>> +};
>>> +
>>> +static int drv260x_init(struct drv260x_data *haptics)
>>> +{
>>> + int ret;
>>> + unsigned int cal_buf;
>>> +
>>> + ret = regmap_write(haptics->regmap,
>>> + DRV260X_RATED_VOLT, haptics->rated_voltage);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + ret = regmap_write(haptics->regmap,
>>> + DRV260X_OD_CLAMP_VOLT, haptics->overdrive_voltage);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + switch(haptics->mode) {
>>> + case DRV260X_LRA_MODE:
>>> + ret = regmap_register_patch(haptics->regmap,
>>> + drv260x_lra_cal_regs,
>>> + ARRAY_SIZE(drv260x_lra_cal_regs));
>>> + if (ret != 0)
>>> + goto write_failure;
>>> + break;
>>> + case DRV260X_ERM_MODE:
>>> + ret = regmap_register_patch(haptics->regmap,
>>> + drv260x_erm_cal_regs,
>>> + ARRAY_SIZE(drv260x_erm_cal_regs));
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + ret = regmap_update_bits(haptics->regmap, DRV260X_LIB_SEL,
>>> + DRV260X_LIB_SEL_MASK,
>>> + haptics->library);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> + break;
>>> + default:
>>> + ret = regmap_register_patch(haptics->regmap,
>>> + drv260x_lra_init_regs,
>>> + ARRAY_SIZE(drv260x_lra_init_regs));
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + ret = regmap_update_bits(haptics->regmap, DRV260X_LIB_SEL,
>>> + DRV260X_LIB_SEL_MASK,
>>> + haptics->library);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + goto skip_go_bit;
>>> + break;
>>> + }
>>> +
>>> + if (ret != 0) {
>>> + dev_err(&haptics->client->dev,
>>> + "Failed to write init registers: %d\n",
>>> + ret);
>>> + goto write_failure;
>>> + }
>>> +
>>> + ret = regmap_write(haptics->regmap, DRV260X_GO, DRV260X_GO_BIT);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> +
>>> + do {
>>> + ret = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
>>> + if (ret != 0)
>>> + goto write_failure;
>>> + } while (cal_buf == DRV260X_GO_BIT || ret != 0);
>>> +
>>> + return ret;
>>> +
>>> +write_failure:
>>> + dev_err(&haptics->client->dev,
>>> + "Failed to write init registers: %d\n",
>>> + ret);
>>> +skip_go_bit:
>>> + return ret;
>>> +}
>>> +
>>> +static const struct regmap_config drv260x_regmap_config = {
>>> + .reg_bits = 8,
>>> + .val_bits = 8,
>>> +
>>> + .max_register = DRV260X_MAX_REG,
>>> + .reg_defaults = drv260x_reg_defs,
>>> + .num_reg_defaults = ARRAY_SIZE(drv260x_reg_defs),
>>> + .cache_type = REGCACHE_NONE,
>>> +};
>>> +
>>> +#ifdef CONFIG_OF
>>> +static int drv260x_parse_dt(struct device_node *dev_node,
>>> + struct drv260x_data *haptics,
>>> + struct device *dev)
>>> +{
>>> + int ret;
>>> + int voltage;
>>> +
>>> + ret = of_property_read_u32(dev_node, "mode", &haptics->mode);
>>> + if (ret < 0) {
>>> + dev_err(dev, "%s: No entry for mode\n", __func__);
>>> +
>>> + return ret;
>>> + }
>>> + ret = of_property_read_u32(dev_node, "library-sel",
>>> + &haptics->library);
>>> + if (ret < 0) {
>>> + dev_err(dev, "%s: No entry for library selection\n",
>>> + __func__);
>>> +
>>> + return ret;
>>> + }
>>> + ret = of_property_read_u32(dev_node, "vib-rated-voltage",
>>> + &voltage);
>>> + if (!ret)
>>> + haptics->rated_voltage = drv260x_calculate_voltage(voltage);
>>> +
>>> +
>>> + ret = of_property_read_u32(dev_node, "vib-overdrive-voltage",
>>> + &voltage);
>>> + if (!ret)
>>> + haptics->overdrive_voltage = drv260x_calculate_voltage(voltage);
>>> +
>>> + return ret;
>>> +
>>> +}
>>> +#else
>>> +static inline int drv260x_parse_dt(struct device *dev)
>>> +{
>>> + dev_err(dev, "no platform data defined\n");
>>> +
>>> + return -EINVAL;
>>> +}
>>> +#endif
>>> +static int drv260x_probe(struct i2c_client *client,
>>> + const struct i2c_device_id *id)
>>> +{
>>> + struct drv260x_data *haptics;
>>> + struct device_node *np = client->dev.of_node;
>>> + struct drv260x_platform_data *pdata = dev_get_platdata(&client->dev);
>>> + int ret;
>>> +
>>> + haptics = devm_kzalloc(&client->dev, sizeof(*haptics), GFP_KERNEL);
>>> + if (!haptics)
>>> + return -ENOMEM;
>>> +
>>> + haptics->rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
>>> + haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
>>> +
>>> + if (pdata) {
>>> + haptics->mode = pdata->mode;
>>> + haptics->library = pdata->library_selection;
>>> + if (pdata->vib_overdrive_voltage)
>>> + haptics->overdrive_voltage = drv260x_calculate_voltage(pdata->vib_overdrive_voltage);
>>> + if (pdata->vib_rated_voltage)
>>> + haptics->rated_voltage = drv260x_calculate_voltage(pdata->vib_rated_voltage);
>>> + } else if (np) {
>>> + ret = drv260x_parse_dt(np, haptics, &client->dev);
>>> + if (ret)
>>> + return ret;
>>> + } else {
>>> + dev_err(&client->dev, "Platform data not set\n");
>>> + return -ENODEV;
>>> + }
>>> +
>>> +
>>> + if (haptics->mode < DRV260X_LRA_MODE ||
>>> + haptics->mode > DRV260X_ERM_MODE) {
>>> + dev_err(&client->dev,
>>> + "Vibrator mode is invalid: %i\n",
>>> + haptics->mode);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (haptics->library < DRV260X_LIB_SEL_DEFAULT ||
>>> + haptics->library > DRV260X_LIB_F) {
>>> + dev_err(&client->dev,
>>> + "Library value is invalid: %i\n", haptics->library);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + haptics->regulator = devm_regulator_get(&client->dev, "vbat");
>>> + if (IS_ERR(haptics->regulator)) {
>>> + ret = PTR_ERR(haptics->regulator);
>>> + dev_err(&client->dev,
>>> + "unable to get regulator, error: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + haptics->enable_gpio = devm_gpiod_get(&client->dev, "enable");
>>> + if (IS_ERR(haptics->enable_gpio)) {
>>> + ret = PTR_ERR(haptics->enable_gpio);
>>> + if (ret != -ENOENT && ret != -ENOSYS)
>>> + return ret;
>>> + haptics->enable_gpio = NULL;
>>> + } else {
>>> + gpiod_direction_output(haptics->enable_gpio, 1);
>>> + }
>>> +
>>> + haptics->input_dev = devm_input_allocate_device(&client->dev);
>>> + if (haptics->input_dev == NULL) {
>>> + dev_err(&client->dev, "Failed to allocate input device\n");
>>> + ret = -ENOMEM;
>>> + return ret;
>>> + }
>>> +
>>> + haptics->input_dev->name = "drv260x:haptics";
>>> + haptics->input_dev->dev.parent = client->dev.parent;
>>> + haptics->input_dev->close = drv260x_close;
>>> + input_set_drvdata(haptics->input_dev, haptics);
>>> + input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
>>> +
>>> + ret = input_ff_create_memless(haptics->input_dev, NULL,
>>> + drv260x_haptics_play);
>>> + if (ret < 0) {
>>> + dev_err(&client->dev, "input_ff_create() failed: %d\n",
>>> + ret);
>>> + return ret;
>>> + }
>>> +
>>> + INIT_WORK(&haptics->work, drv260x_worker);
>>> +
>>> + haptics->client = client;
>>> + i2c_set_clientdata(client, haptics);
>>> +
>>> + haptics->regmap = devm_regmap_init_i2c(client, &drv260x_regmap_config);
>>> + if (IS_ERR(haptics->regmap)) {
>>> + ret = PTR_ERR(haptics->regmap);
>>> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
>>> + ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = drv260x_init(haptics);
>>> + if (ret < 0) {
>>> + dev_err(&client->dev, "Device init failed: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = input_register_device(haptics->input_dev);
>>> + if (ret < 0) {
>>> + dev_err(&client->dev, "couldn't register input device: %d\n",
>>> + ret);
>>> + return ret;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int drv260x_suspend(struct device *dev)
>>> +{
>>> + struct drv260x_data *haptics = dev_get_drvdata(dev);
>>> + int ret = 0;
>>> +
>>> + mutex_lock(&haptics->input_dev->mutex);
>>> +
>>> + if (haptics->input_dev->users) {
>>> + ret = regmap_update_bits(haptics->regmap,
>>> + DRV260X_MODE,
>>> + DRV260X_STANDBY_MASK,
>>> + DRV260X_STANDBY);
>>> + if (ret) {
>>> + dev_err(dev, "Failed to set standby mode\n");
>>> + goto out;
>>> + }
>>> +
>>> + gpiod_set_value(haptics->enable_gpio, 0);
>>> +
>>> + ret = regulator_disable(haptics->regulator);
>>> + if (ret)
>>> + dev_err(dev, "Failed to disable regulator\n");
>>> + }
>>> +out:
>>> + mutex_unlock(&haptics->input_dev->mutex);
>>> + return ret;
>>> +}
>>> +
>>> +static int drv260x_resume(struct device *dev)
>>> +{
>>> + struct drv260x_data *haptics = dev_get_drvdata(dev);
>>> + int ret = 0;
>>> +
>>> + mutex_lock(&haptics->input_dev->mutex);
>>> +
>>> + if (haptics->input_dev->users) {
>>> + ret = regulator_enable(haptics->regulator);
>>> + if (ret) {
>>> + dev_err(dev, "Failed to enable regulator\n");
>>> + goto out;
>>> + }
>>> + ret = regmap_update_bits(haptics->regmap,
>>> + DRV260X_MODE,
>>> + DRV260X_STANDBY_MASK, 0);
>>> + if (ret) {
>>> + dev_err(dev, "Failed to unset standby mode\n");
>>> + goto out;
>>> + }
>>> +
>>> + gpiod_set_value(haptics->enable_gpio, 1);
>>> + }
>>> +
>>> +out:
>>> + mutex_unlock(&haptics->input_dev->mutex);
>>> + return ret;
>>> +}
>>> +#endif
>>> +
>>> +static SIMPLE_DEV_PM_OPS(drv260x_pm_ops, drv260x_suspend, drv260x_resume);
>>> +
>>> +static const struct i2c_device_id drv260x_id[] = {
>>> + { "drv2605l", 0 },
>>> + { }
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, drv260x_id);
>>> +
>>> +#if IS_ENABLED(CONFIG_OF)
>>> +static const struct of_device_id drv260x_of_match[] = {
>>> + { .compatible = "ti,drv2604", },
>>> + { .compatible = "ti,drv2604l", },
>>> + { .compatible = "ti,drv2605", },
>>> + { .compatible = "ti,drv2605l", },
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, drv260x_of_match);
>>> +#endif
>>> +
>>> +static struct i2c_driver drv260x_driver = {
>>> + .probe = drv260x_probe,
>>> + .driver = {
>>> + .name = "drv260x-haptics",
>>> + .owner = THIS_MODULE,
>>> + .of_match_table = of_match_ptr(drv260x_of_match),
>>> + .pm = &drv260x_pm_ops,
>>> + },
>>> + .id_table = drv260x_id,
>>> +};
>>> +module_i2c_driver(drv260x_driver);
>>> +
>>> +MODULE_ALIAS("platform:drv260x-haptics");
>>> +MODULE_DESCRIPTION("TI DRV260x haptics driver");
>>> +MODULE_LICENSE("GPL");
>>> +MODULE_AUTHOR("Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>");
>>> diff --git a/include/dt-bindings/input/ti-drv260x.h b/include/dt-bindings/input/ti-drv260x.h
>>> new file mode 100644
>>> index 0000000..be7f245
>>> --- /dev/null
>>> +++ b/include/dt-bindings/input/ti-drv260x.h
>>> @@ -0,0 +1,35 @@
>>> +/*
>>> + * DRV260X haptics driver family
>>> + *
>>> + * Author: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>>> + *
>>> + * Copyright: (C) 2014 Texas Instruments, Inc.
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#ifndef _DT_BINDINGS_TI_DRV260X_H
>>> +#define _DT_BINDINGS_TI_DRV260X_H
>>> +
>>> +/* Calibration Types */
>>> +#define DRV260X_LRA_MODE 0x00
>>> +#define DRV260X_LRA_NO_CAL_MODE 0x01
>>> +#define DRV260X_ERM_MODE 0x02
>>> +
>>> +/* Library Selection */
>>> +#define DRV260X_LIB_SEL_DEFAULT 0x00
>>> +#define DRV260X_LIB_A 0x01
>>> +#define DRV260X_LIB_B 0x02
>>> +#define DRV260X_LIB_C 0x03
>>> +#define DRV260X_LIB_D 0x04
>>> +#define DRV260X_LIB_E 0x05
>>> +#define DRV260X_LIB_F 0x06
>>> +
>>> +#endif
>>> diff --git a/include/linux/platform_data/drv260x-pdata.h b/include/linux/platform_data/drv260x-pdata.h
>>> new file mode 100644
>>> index 0000000..4091a9b
>>> --- /dev/null
>>> +++ b/include/linux/platform_data/drv260x-pdata.h
>>> @@ -0,0 +1,29 @@
>>> +/*
>>> + * Platform data for DRV260X haptics driver family
>>> + *
>>> + * Author: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>>> + *
>>> + * Copyright: (C) 2014 Texas Instruments, Inc.
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#ifndef _LINUX_DRV260X_PDATA_H
>>> +#define _LINUX_DRV260X_PDATA_H
>>> +
>>> +struct drv260x_platform_data {
>>> + int enable_gpio;
>>> + u32 library_selection;
>>> + u32 mode;
>>> + u32 vib_rated_voltage;
>>> + u32 vib_overdrive_voltage;
>>> +};
>>> +
>>> +#endif
>>>
>>
>>
>> --
>> ------------------
>> Dan Murphy
>
--
------------------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Retire gamecon?
From: Dmitry Torokhov @ 2014-08-12 17:07 UTC (permalink / raw)
To: linux-input; +Cc: Vojtech Pavlik, Jiri Kosina
Hi,
I am wondering it it is time to retire gamecon support from the kernel. It
hasn't been working well ever since cpufreq became mainstream and it becomes
increasingly hard to find hardware and software that would run on such old
hardware.
Please scream if you believe it should stay in.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input/joystick: use get_cycles on ARMv8
From: Dmitry Torokhov @ 2014-08-12 17:01 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-input, linaro-kernel, Mark Brown
In-Reply-To: <1407771730-1641-1-git-send-email-broonie@kernel.org>
On Mon, Aug 11, 2014 at 04:42:10PM +0100, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> As with ARM the ARMv8 architecture provides a cycle counter which can be
> used to provide a high resolution time for the joystick driver and silence
> the build warning that results from not having a precise timer on ARMv8,
> making allmodconfig and allyesconfig quieter.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
Applied, although I wonder if it is time to retire whole gamecon subsystem. I
don't think there are many users left...
> ---
> drivers/input/joystick/analog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index 9135606c8649..ab0fdcd36e18 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -158,7 +158,7 @@ static unsigned int get_time_pit(void)
> #define GET_TIME(x) rdtscl(x)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "TSC"
> -#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_TILE)
> +#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_TILE)
> #define GET_TIME(x) do { x = get_cycles(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "get_cycles"
> --
> 2.0.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: wacom - Fix compiler warning if !CONFIG_PM
From: Dmitry Torokhov @ 2014-08-12 17:00 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Geert Uytterhoeven, linux-input, linux-kernel
In-Reply-To: <20140811144238.GA10029@mail.corp.redhat.com>
On Mon, Aug 11, 2014 at 10:42:38AM -0400, Benjamin Tissoires wrote:
> On Aug 09 2014 or thereabouts, Jiri Kosina wrote:
> > On Sat, 9 Aug 2014, Geert Uytterhoeven wrote:
> >
> > > If CONFIG_PM is not set:
> > >
> > > drivers/hid/wacom_sys.c:1436: warning: ‘wacom_reset_resume’ defined but
> > > not used
> > >
> > > Protect the unused functions by #ifdef CONFIG_PM to fix this.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thanks Geert.
> >
> > hid-wacom is in a sort of temporary mode of operation, being moved from
> > Input to HID driver.
> >
> > Adding Benjamin and Dmitry to CC, as this will likely still go through
> > Dmitry's queue.
> >
>
> Thanks for fixing this Geert.
>
> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thank you.
--
Dmitry
--
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] Input: atmel_mxt_ts - fix a few issues reported by Coverity
From: Stephen Warren @ 2014-08-12 16:41 UTC (permalink / raw)
To: Nick Dyer
Cc: Dmitry Torokhov, linux-input, Yufeng Shen, Benson Leung,
Stephen Warren, linux-kernel
In-Reply-To: <53EA431F.6020908@itdev.co.uk>
On 08/12/2014 10:38 AM, Nick Dyer wrote:
> On 11/08/14 19:03, Dmitry Torokhov wrote:
>> This should fix the following issues reported by Coverity:
>>
>> *** CID 1230625: Logically dead code (DEADCODE)
>> /drivers/input/touchscreen/atmel_mxt_ts.c: 1692 in mxt_initialize()
>>
>> *** CID 1230627: Missing break in switch (MISSING_BREAK)
>> /drivers/input/touchscreen/atmel_mxt_ts.c: 1436 in mxt_get_object_table()
>>
>> *** CID 1230629: Out-of-bounds write (OVERRUN)
>> /drivers/input/touchscreen/atmel_mxt_ts.c: 1267 in mxt_update_cfg()
>>
>> *** CID 1230632: Unused pointer value (UNUSED_VALUE)
>> /drivers/input/touchscreen/atmel_mxt_ts.c: 1211 in mxt_update_cfg()
>>
>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> I've reviewed these changes and they look correct to me. Apologies that
> they slipped through, most of it is bad merging on my part I think.
>
> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Don't you mean Acked-by or Reviewed-by?
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts - fix a few issues reported by Coverity
From: Nick Dyer @ 2014-08-12 16:38 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Yufeng Shen, Benson Leung, Stephen Warren, linux-kernel
In-Reply-To: <20140811180307.GA25677@core.coreip.homeip.net>
On 11/08/14 19:03, Dmitry Torokhov wrote:
> This should fix the following issues reported by Coverity:
>
> *** CID 1230625: Logically dead code (DEADCODE)
> /drivers/input/touchscreen/atmel_mxt_ts.c: 1692 in mxt_initialize()
>
> *** CID 1230627: Missing break in switch (MISSING_BREAK)
> /drivers/input/touchscreen/atmel_mxt_ts.c: 1436 in mxt_get_object_table()
>
> *** CID 1230629: Out-of-bounds write (OVERRUN)
> /drivers/input/touchscreen/atmel_mxt_ts.c: 1267 in mxt_update_cfg()
>
> *** CID 1230632: Unused pointer value (UNUSED_VALUE)
> /drivers/input/touchscreen/atmel_mxt_ts.c: 1211 in mxt_update_cfg()
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
I've reviewed these changes and they look correct to me. Apologies that
they slipped through, most of it is bad merging on my part I think.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
^ permalink raw reply
* Re: [PATCH] HID:hid-logitech: Prevent possibility of infinite loop when using /sys interface
From: Jiri Kosina @ 2014-08-12 14:30 UTC (permalink / raw)
To: Simon Wood; +Cc: linux-input, linux-kernel
In-Reply-To: <1407379951-7038-1-git-send-email-simon@mungewell.org>
On Wed, 6 Aug 2014, Simon Wood wrote:
> If the device data is not accessible for some reason, returning 0 will cause the call to be
> continuously called again as none of the string has been 'consumed'.
Hi Simon,
this patch is missing signoff.
> ---
> drivers/hid/hid-lg4ff.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
> index cc2bd20..7835717 100644
> --- a/drivers/hid/hid-lg4ff.c
> +++ b/drivers/hid/hid-lg4ff.c
> @@ -451,13 +451,13 @@ static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *at
> drv_data = hid_get_drvdata(hid);
> if (!drv_data) {
> hid_err(hid, "Private driver data not found!\n");
> - return 0;
> + return -EINVAL;
> }
>
> entry = drv_data->device_props;
> if (!entry) {
> hid_err(hid, "Device properties not found!\n");
> - return 0;
> + return -EINVAL;
> }
>
> if (range == 0)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation
From: Michal Malý @ 2014-08-12 14:02 UTC (permalink / raw)
To: Jiri Kosina
Cc: simon@mungewell.org, linux-input, linux-kernel@vger.kernel.org,
edwin, elias.vds@gmail.com, Roland Bosa
In-Reply-To: <alpine.LNX.2.00.1408121509550.15220@pobox.suse.cz>
On Tuesday 12 of August 2014 15:10:12 Jiri Kosina wrote:
> On Thu, 31 Jul 2014, simon@mungewell.org wrote:
> > > +#define LG4FF_MSW_MIN 0
> > > +#define LG4FF_MSW_NATIVE 0 /* Switch device to its native mode (if
> > > applicable) */
> > > +#define LG4FF_MSW_DONTSWITCH 1 /* Leave device in its current mode */
> > > +#define LG4FF_MSW_DFP 2 /* Switch device so that it emulates
Driving
> > > Force Pro (only G25, G27, DFGT) */
> > > +#define LG4FF_MSW_G25 3 /* Switch device so that it emulates G25
(only
> > > G27) */
> > > +#define LG4FF_MSW_MAX 3
> >
> > Just to let everyone know I am looking at this patch, and have emailed
> > Michal some questions on whether it covers all options for control.
>
> Hi guys,
>
> did you reach any kind of conclusion here?
Hi,
Simon mailed me his revised patchset which has the changes broken out into
four separate patches and allows to switch "extended compatibility" modes on
the fly through sysfs. I looked them over and I they seem fine to me. I
suppose he'll submit them for review very soon.
Michal
^ permalink raw reply
* Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation
From: Jiri Kosina @ 2014-08-12 13:10 UTC (permalink / raw)
To: simon@mungewell.org
Cc: "Michal Malý", linux-input,
linux-kernel@vger.kernel.org, edwin, elias.vds@gmail.com,
Roland Bosa
In-Reply-To: <f86b6b4fbf48ce4cbeb9b537794a4eb8.squirrel@mungewell.org>
On Thu, 31 Jul 2014, simon@mungewell.org wrote:
> > +#define LG4FF_MSW_MIN 0
> > +#define LG4FF_MSW_NATIVE 0 /* Switch device to its native mode (if
> > applicable) */
> > +#define LG4FF_MSW_DONTSWITCH 1 /* Leave device in its current mode */
> > +#define LG4FF_MSW_DFP 2 /* Switch device so that it emulates Driving
> > Force Pro (only G25, G27, DFGT) */
> > +#define LG4FF_MSW_G25 3 /* Switch device so that it emulates G25 (only
> > G27) */
> > +#define LG4FF_MSW_MAX 3
>
> Just to let everyone know I am looking at this patch, and have emailed
> Michal some questions on whether it covers all options for control.
Hi guys,
did you reach any kind of conclusion here?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* YOUR FUND HAS BEEN APPROVED: PLEASE GET BACK TO US.
From: STANDARD BANK @ 2014-08-12 10:39 UTC (permalink / raw)
In-Reply-To: <1407839830.14934.YahooMailNeo@web126203.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 44 bytes --]
OPEN THE ATTACHED FILE AND GET BACK TO US.
[-- Attachment #2: STANDARD BANK.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 13187 bytes --]
^ permalink raw reply
* Re: [PATCHES] HID: huion: Fix "doing dma on the stack"
From: Jiri Kosina @ 2014-08-12 10:46 UTC (permalink / raw)
To: Nikolai Kondrashov; +Cc: linux-input, DIGImend-devel
In-Reply-To: <53E9E6F3.3040005@gmail.com>
On Tue, 12 Aug 2014, Nikolai Kondrashov wrote:
> > They seem to be missing your signoff though ... is that on purpose?
>
> No, I forgot it, sorry. Would you like me to re-send them with my signoff?
>
> Otherwise:
>
> Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
No need to resend; I've applied the patches now with the signoff added.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHES] HID: huion: Fix "doing dma on the stack"
From: Nikolai Kondrashov @ 2014-08-12 10:05 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, DIGImend-devel
In-Reply-To: <alpine.LNX.2.00.1408121126560.15220@pobox.suse.cz>
On 08/12/2014 12:27 PM, Jiri Kosina wrote:
> On Mon, 11 Aug 2014, Nikolai Kondrashov wrote:
>
>> Hi everyone,
>>
>> These two patches work towards fixing the "doing dma on the stack" reported by
>> a static analyzer (I'm not sure which one) for my recent changes to hid-huion
>> driver.
>>
>> The first one is easier to read with whitespace changes ingored (-w).
>>
>> Both patches were tested by me with a Huion H610N tablet.
>>
>> Nick
>
> Nikolai,
>
> thanks, I will be reviewing the patches soon and queuing for 3.17 still
> eventually.
Thanks, Jiri.
> They seem to be missing your signoff though ... is that on purpose?
No, I forgot it, sorry. Would you like me to re-send them with my signoff?
Otherwise:
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Nick
^ permalink raw reply
* Re: [PATCHES] HID: huion: Fix "doing dma on the stack"
From: Jiri Kosina @ 2014-08-12 9:27 UTC (permalink / raw)
To: Nikolai Kondrashov; +Cc: linux-input, DIGImend-devel
In-Reply-To: <1407779132-26749-1-git-send-email-spbnick@gmail.com>
On Mon, 11 Aug 2014, Nikolai Kondrashov wrote:
> Hi everyone,
>
> These two patches work towards fixing the "doing dma on the stack" reported by
> a static analyzer (I'm not sure which one) for my recent changes to hid-huion
> driver.
>
> The first one is easier to read with whitespace changes ingored (-w).
>
> Both patches were tested by me with a Huion H610N tablet.
>
> Nick
Nikolai,
thanks, I will be reviewing the patches soon and queuing for 3.17 still
eventually.
They seem to be missing your signoff though ... is that on purpose?
Thanks,
--
Jiri Kosina
SUSE Labs
^ 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