* Re: [PATCH v2] input: touchscreen: edt-ft5x06: fix driver autoprobing
From: Wolfram Sang @ 2014-11-22 9:06 UTC (permalink / raw)
To: Felipe Balbi
Cc: Dmitry Torokhov, Linux OMAP Mailing List, linux-input, stable
In-Reply-To: <20141122010524.GA26751@saruman>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
> Can you comment on this ? As of today i2c-based drivers will probe with
> DT-based boot if DT's compatible is set to the same id as in struct
> i2c_device_id. No i2c driver with of_device_id can autoprobe using OF
> ids.
Long standing problem. Last one to tackle this was Lee Jones:
https://lkml.org/lkml/2014/8/28/283
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2] hid-multitouch: Add quirk for VTL touch panels
From: Mathieu Magnaudet @ 2014-11-22 11:02 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
VTL panels do not switch to the multitouch mode until the input mode
feature is read by the host. This should normally be done by
usbhid, but it looks like an other bug prevents usbhid to properly
retrieve the feature state. As a workaround, we force the reading of
the feature in mt_set_input_mode for such devices.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
---
v1 -> v2
use hid_alloc_report_buf instead of kzalloc
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-multitouch.c | 27 +++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 7c86373..d6cc6a9 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -931,6 +931,9 @@
#define USB_DEVICE_ID_VERNIER_CYCLOPS 0x0004
#define USB_DEVICE_ID_VERNIER_LCSPEC 0x0006
+#define USB_VENDOR_ID_VTL 0x0306
+#define USB_DEVICE_ID_VTL_MULTITOUCH_FF3F 0xff3f
+
#define USB_VENDOR_ID_WACOM 0x056a
#define USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH 0x81
#define USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH 0x00BD
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 51e25b9..683cda6 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -67,6 +67,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_IGNORE_DUPLICATES (1 << 10)
#define MT_QUIRK_HOVERING (1 << 11)
#define MT_QUIRK_CONTACT_CNT_ACCURATE (1 << 12)
+#define MT_QUIRK_FORCE_GET_FEATURE (1 << 13)
#define MT_INPUTMODE_TOUCHSCREEN 0x02
#define MT_INPUTMODE_TOUCHPAD 0x03
@@ -150,6 +151,7 @@ static void mt_post_parse(struct mt_device *td);
#define MT_CLS_FLATFROG 0x0107
#define MT_CLS_GENERALTOUCH_TWOFINGERS 0x0108
#define MT_CLS_GENERALTOUCH_PWT_TENFINGERS 0x0109
+#define MT_CLS_VTL 0x0110
#define MT_DEFAULT_MAXCONTACT 10
#define MT_MAX_MAXCONTACT 250
@@ -255,6 +257,11 @@ static struct mt_class mt_classes[] = {
.sn_move = 2048,
.maxcontacts = 40,
},
+ { .name = MT_CLS_VTL,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_CONTACT_CNT_ACCURATE |
+ MT_QUIRK_FORCE_GET_FEATURE,
+ },
{ }
};
@@ -809,6 +816,9 @@ static void mt_set_input_mode(struct hid_device *hdev)
struct mt_device *td = hid_get_drvdata(hdev);
struct hid_report *r;
struct hid_report_enum *re;
+ struct mt_class *cls = &td->mtclass;
+ char *buf;
+ int report_len;
if (td->inputmode < 0)
return;
@@ -816,6 +826,18 @@ static void mt_set_input_mode(struct hid_device *hdev)
re = &(hdev->report_enum[HID_FEATURE_REPORT]);
r = re->report_id_hash[td->inputmode];
if (r) {
+ if (cls->quirks & MT_QUIRK_FORCE_GET_FEATURE) {
+ report_len = ((r->size - 1) >> 3) + 1 + (r->id > 0);
+ buf = hid_alloc_report_buf(r, GFP_KERNEL);
+ if (!buf) {
+ hid_err(hdev, "failed to allocate buffer for report\n");
+ return;
+ }
+ hid_hw_raw_request(hdev, r->id, buf, report_len,
+ HID_FEATURE_REPORT,
+ HID_REQ_GET_REPORT);
+ kfree(buf);
+ }
r->field[0]->value[td->inputmode_index] = td->inputmode_value;
hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
}
@@ -1281,6 +1303,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_UNITEC,
USB_DEVICE_ID_UNITEC_USB_TOUCH_0A19) },
+ /* VTL panels */
+ { .driver_data = MT_CLS_VTL,
+ MT_USB_DEVICE(USB_VENDOR_ID_VTL,
+ USB_DEVICE_ID_VTL_MULTITOUCH_FF3F) },
+
/* Wistron panels */
{ .driver_data = MT_CLS_NSMU,
MT_USB_DEVICE(USB_VENDOR_ID_WISTRON,
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] HID: usbhid: get/put around clearing needs_remote_wakeup
From: Alan Stern @ 2014-11-22 15:55 UTC (permalink / raw)
To: Benson Leung
Cc: johan, Jiri Kosina, linux-usb, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Sameer Nanda
In-Reply-To: <CANLzEkuPr0hhjecVHaMkGfX7_DZr4wUV=-yP2+V6uBaYdAkhXw@mail.gmail.com>
On Fri, 21 Nov 2014, Benson Leung wrote:
> Sorry for the delay in my response. I did some more checking of my
> particular failure, and my commit message is incorrect. The
> usb_kill_urb is actually not the cause of this problem. It does not
> result in autosuspend_check() itself, and is only serving to add some
> delay.
>
> hidraw_release() in hidraw.c calls drop_ref(), which calls the
> following in sequence upon clearing the last reader :
> /* close device for last reader */
> hid_hw_power(hidraw->hid, PM_HINT_NORMAL);
> hid_hw_close(hidraw->hid);
>
> hid_hw_power results in a usb_autopm_put_interface. In this case, the
> reference count is decremented to 0, and a delayed autosuspend request
> is attempted.
> hid_hw_close leads to usbhid_close, which clears needs_remote_wakeup.
>
> However, there's no guarantee that the clear of needs_remote_wakeup
> will occur before the delayed work ( runtime_idle() ->
> autosuspend_check() ) runs. Moving usbhid->intf->needs_remote_wakeup
> = 0 to before the usb_kill_urb(usbhid->urbin) only serves to reduce
> the amount of time between these events and makes this particular
> failure less likely.
>
> The correct solution is to put get/put around each change of
> needs_remote_wakeup, as that will correctly trigger another delayed
> autosuspend_check(), whose result is affected by the state of
> needs_remote_wakeup.
>
> Since autosuspend_check() occurs as delayed work, I think it is
> appropriate to add get/put around the clear in usbhid_stop as well.
As Oliver pointed out, there's no real need to resume a device which is
already suspended (the only effect would be to allow it to suspend
again but with wakeup disabled -- and this would happen anyway if a
wakeup occurred). Instead of using get and put, we should have an idle
call.
There is no USB wrapper for pm_runtime_idle calls, but one could be
added. Still, in the meantime can you check to see what happens if you
add
pm_runtime_idle(&usbhid->intf->dev);
in usbhid_close() just after needs_remote_wakeup is set to 0? You can
do the same thing in usbhid_stop() if you want.
Alan Stern
^ permalink raw reply
* Touchpad/Clickpad Linux Project
From: Felipe Lavratti @ 2014-11-22 15:59 UTC (permalink / raw)
To: linux-input
Hello,
I'd like to ask if there's any undergoing Linux project regarding the
Touchpad/Clickpad Linux sub system and where can I get in touch with
the developers.
Thanks.
At.
^ permalink raw reply
* Re: [PATCH] HID: usbhid: get/put around clearing needs_remote_wakeup
From: Alan Stern @ 2014-11-22 16:02 UTC (permalink / raw)
To: Benson Leung
Cc: johan, Jiri Kosina, linux-usb, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Sameer Nanda
In-Reply-To: <Pine.LNX.4.44L0.1411221043060.23393-100000@netrider.rowland.org>
On Sat, 22 Nov 2014, Alan Stern wrote:
> There is no USB wrapper for pm_runtime_idle calls, but one could be
> added. Still, in the meantime can you check to see what happens if you
> add
>
> pm_runtime_idle(&usbhid->intf->dev);
>
> in usbhid_close() just after needs_remote_wakeup is set to 0? You can
> do the same thing in usbhid_stop() if you want.
Come to think of it, we probably need
pm_runtime_idle(usbhid->intf->dev->parent);
in addition to the function call above. When a USB wrapper is written,
it can take care of these details.
Alan Stern
^ permalink raw reply
* Re: Touchpad/Clickpad Linux Project
From: Felipe Lavratti @ 2014-11-22 16:04 UTC (permalink / raw)
To: linux-input
In-Reply-To: <CAF2ZALXeSywH386un2rOZ3AP1ULk8EuAMoXGDuZNnJFKgFymqg@mail.gmail.com>
Hello,
I'd like to ask if there's any undergoing Linux project regarding the
Touchpad/Clickpad Linux sub system and where can I get in touch with
the developers.
Thanks.
At.
^ permalink raw reply
* Reported key not released
From: Pali Rohár @ 2014-11-23 13:13 UTC (permalink / raw)
To: linux-input, platform-driver-x86
Cc: Matthew Garrett, Darren Hart, Gabriele Mazzotta, Alex Hung
[-- Attachment #1: Type: Text/Plain, Size: 1604 bytes --]
Hello,
my laptop (Dell Latitude E6440) has HW switch which for disabling
some radio devices (bluetooth, wifi, 3g; list of devices can be
configured in BIOS).
When I enable or disable this switch it correctly enable or
disable devices (and also hard rfkill status is set correctly).
But problem is that switch generate key press event on i8042
keyboard controller without release event. See output:
$ sudo input-events 4
/dev/input/event4
bustype : BUS_I8042
vendor : 0x1
product : 0x1
version : 43841
name : "AT Translated Set 2 keyboard"
phys : "isa0060/serio0/input0"
bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP
waiting for events
...
(here I enabled switch)
14:04:07.047897: EV_MSC MSC_SCAN 136
14:04:07.047897: EV_KEY KEY_UNKNOWN (0xf0) pressed
14:04:07.047897: EV_SYN code=0 value=0
(and after that my terminal emulator start writing dummy chars)
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1
(here I disabled switch)
14:04:08.730526: EV_MSC MSC_SCAN 136
14:04:08.730526: EV_KEY KEY_UNKNOWN (0xf0) pressed
14:04:08.730526: EV_SYN code=0 value=0
So I think that above chars were written because there was no
release event.
I have two questions:
1) Should kernel for this special switch key emit also release
event? And if yes, how to do that if keyboard controller do not
do that?
2) It is possible to remap KEY_UNKNOWN to something meaningful?
Or it should be KEY_UNKNOWN iff BIOS already handle hard rfkill
state?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Side effect of pressing special keys
From: Pali Rohár @ 2014-11-23 13:41 UTC (permalink / raw)
To: linux-input, platform-driver-x86; +Cc: Gabriele Mazzotta, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
Hello,
pressing some keys on laptops could cause some side effects.
Example scenario 1:
Laptop has Fn key for enabling/disabling WIFI and when that key
is pressed BIOS is doing two things:
1) Switch hard rfkill state of WIFI
2) Report that Fn key was pressed to kernel
(either via i8042 bus or via ACPI/WMI)
Example scenario 2:
Another laptop has Fn key too, but BIOS does not change state of
hard rfkill. So system (kernel or userspace) is responsible for
interpreting what that Fn key means and call correct action (find
rfkill device for WIFI and soft block it).
And my questions are:
1) What should userspace do if some input device report that
KEY_WLAN or KEY_RFKILL was pressed?
2) Should kernel report to userspace that (on specific laptop)
has pressed key some side effect?
3) How to deal with existing userspace application which
interpret all pressed keys as described in example scenario 2
also on laptops from scenario 1? KDE4, NetworkManager, ... are
know to do that!
Note that this problem is not only about rfkill/wifi keys. Same
apply for keyboard brightness Fn keys and also for key
KEY_KBDILLUMTOGGLE (which toggle keyboard illumination level).
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Input: xpad: use proper endpoint type
From: Greg Kroah-Hartman @ 2014-11-24 2:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Pierre-Loup A. Griffais
The xpad wireless endpoint is not a bulk endpoint on my devices, but
rather an interrupt one, so the USB core complains when it is submitted.
I'm guessing that the author really did mean that this should be an
interrupt urb, but as there are a zillion different xpad devices out
there, let's cover out bases and handle both bulk and interrupt
endpoints just as easily.
Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
---
This has been in my local tree since January, don't know why it never
got pushed out, sorry for the delay. Valve has been using a version of
this patch for a year now.
drivers/input/joystick/xpad.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1179,9 +1179,19 @@ static int xpad_probe(struct usb_interfa
}
ep_irq_in = &intf->cur_altsetting->endpoint[1].desc;
- usb_fill_bulk_urb(xpad->bulk_out, udev,
- usb_sndbulkpipe(udev, ep_irq_in->bEndpointAddress),
- xpad->bdata, XPAD_PKT_LEN, xpad_bulk_out, xpad);
+ if (usb_endpoint_is_bulk_out(ep_irq_in)) {
+ usb_fill_bulk_urb(xpad->bulk_out, udev,
+ usb_sndbulkpipe(udev,
+ ep_irq_in->bEndpointAddress),
+ xpad->bdata, XPAD_PKT_LEN,
+ xpad_bulk_out, xpad);
+ } else {
+ usb_fill_int_urb(xpad->bulk_out, udev,
+ usb_sndintpipe(udev,
+ ep_irq_in->bEndpointAddress),
+ xpad->bdata, XPAD_PKT_LEN,
+ xpad_bulk_out, xpad, 0);
+ }
/*
* Submit the int URB immediately rather than waiting for open
^ permalink raw reply
* Re: [PATCH] Input: Initialize input_no by -1
From: Aniroop Mathur @ 2014-11-24 3:20 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input@vger.kernel.org
In-Reply-To: <CADYu30-dyHvidn6z6NW0w8hEwFd6Nctf8_5Yb5LKU4MFKvwLHw@mail.gmail.com>
Dear Mr. Torokhov and Linux-Input Community,
Greetings of the day !!
Kindly update about the below patch.
Thank you,
Aniroop Mathur
On Sat, Nov 22, 2014 at 12:18 AM, Aniroop Mathur
<aniroop.mathur@gmail.com> wrote:
>
> This patch initializes input_no by -1 in order to avoid extra subtraction
> operation performed everytime for allocation of an input device.
>
> Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com>
> ---
> drivers/input/input.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 29ca0bb..01fe49e 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1774,7 +1774,7 @@ EXPORT_SYMBOL_GPL(input_class);
> */
> struct input_dev *input_allocate_device(void)
> {
> - static atomic_t input_no = ATOMIC_INIT(0);
> + static atomic_t input_no = ATOMIC_INIT(-1);
> struct input_dev *dev;
>
> dev = kzalloc(sizeof(struct input_dev), GFP_KERNEL);
> @@ -1789,7 +1789,7 @@ struct input_dev *input_allocate_device(void)
> INIT_LIST_HEAD(&dev->node);
>
> dev_set_name(&dev->dev, "input%ld",
> - (unsigned long) atomic_inc_return(&input_no) - 1);
> + (unsigned long) atomic_inc_return(&input_no));
>
> __module_get(THIS_MODULE);
> }
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Johannes Pointner @ 2014-11-24 8:32 UTC (permalink / raw)
To: Griffis, Brad
Cc: Richard Cochran, Nori, Sekhar, R, Vignesh, Dmitry Torokhov,
Lee Jones, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Benoit Cousson, Tony Lindgren, Russell King,
Jonathan Cameron, Hartmut Knaack, Sebastian Andrzej Siewior,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Balbi, Felipe,
Sanjeev Sharma, Paul Gortmaker, Jan Kardell
In-Reply-To: <912A29987EAE174BA6CF187D7CDFA9CE26F6D664@DLEE08.ent.ti.com>
2014-11-21 23:25 GMT+01:00 Griffis, Brad <bgriffis@ti.com>:
>
>> -----Original Message-----
>> From: Richard Cochran [mailto:richardcochran@gmail.com]
>>
>> On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
>> > Before the patches were also jumps but I thought it is something
>> > Vignesh should know. Maybe there is some fix for that too?
>
> I believe I've seen the "jumping" behavior pop up at a couple random times in my testing. I think it relates to the hardware not properly registering a pen-up interrupt. When that's happening can you try running ts_calibrate? If you're not registering a pen-up event then you won't be able to advance through those touch points. Is this behavior related to capturing ADC samples, or do you see this behavior even without capturing ADC samples?
Is it the right way to test? Because I think the ts_lib will cover
misbehavior of the touchscreen driver.
>
>> > As Richard also noted, it would be nice if ti could let us know how to
>> > get the delay values right. By trial and error is IMHO not the best
>> > way.
>>
>> That is not only an opinion, it is a matter of fact. TI really dropped the ball on
>> this one. I thought the patch series was a sign they finally were going to
>> properly address this issue. Wrong again.
>
> These patches originate from work I did on TI's SDK 7.00 (3.12 kernel). The touchscreen is working beautifully in that environment and we are putting forth significant effort to bring those improvements to the community.
>
> Things do not seem to be working as well with the current mainline kernel. I've been reviewing various patches between 3.12 and the mainline to understand why it's different. I believe I have figured this out, and I have discussions going separately with individuals that contributed those patches in order to come up with the best possible solution, i.e. we likely need a few additional changes to this patch set.
Ok, then I'm looking forward for a new patch set to test. Furthermore,
I would be interested which changes you are talking about.
>
> The CHARGECONFIG delay serves precisely the same purpose as the udelay in the original code base. How did you determine the udelay value in the first place? I went through the effort of figuring out a way to make the delay into a HARDWARE delay instead of a software delay so that it could be removed from the ISR. That delay time relates to "settling time" and so it's going to be dependent on your PCB. You could hook up an oscilloscope and attempt to capture this parameter from the signals themselves. Personally I think that's a lot more difficult than just doing a few iterations of testing.
I did measure with an oscilloscope to get the right charge delay and
it looks fine to me. But I can't affect the jumps with the charge
delay, the only thing that helped, was to add some sample delay. But
it didn't solve it.
>
>> The data sheet for the TI part used to have a reference to an app-note for
>> the touch controller.
>>
>> spruh73f page 1154
>>
>> The Pen IRQ can only occur if the correct Pen Ctrl bits are high
>> (AFE Pen Ctrl bits 6:5 in the TSC_ADC control register) and if
>> the correct ground transistor biasing is set in the StepConfig
>> [N] Register. Refer to the application notes for the correct
>> settings.
>>
>> I searched high and low for this application note. Then, the data sheet got
>> revised.
>
> Such an application note does not exist, which explains why you didn't find it and why we have removed that reference from the TRM. Sorry for your trouble. We always strive for accurate documentation.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Sebastian Andrzej Siewior @ 2014-11-24 8:57 UTC (permalink / raw)
To: Richard Cochran, Sekhar Nori
Cc: Dmitry Torokhov, Lee Jones, Vignesh R, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Benoit Cousson,
Tony Lindgren, Russell King, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Brad Griffis, Sanjeev Sharma, Paul Gortmaker, Jan Kardell,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-k
In-Reply-To: <20141121131036.GA18931-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 11/21/2014 02:10 PM, Richard Cochran wrote:
> On the BB white using the LCD4 cape and the shipped debian kernel, the
> cursor *does* jump away, but not as often or as far as on the custom
> design I was working with.
This sounds like the ADC is still sampling while the input data becomes
invalid. Usually there is a resistor on the wiper line and the
touchscreen manual says how much it should be at least. Could you
please check if this is properly installed?
>
> Thanks,
> Richard
Sebastian
^ permalink raw reply
* Re: [PATCH] HID: usbhid: get/put around clearing needs_remote_wakeup
From: Oliver Neukum @ 2014-11-24 9:13 UTC (permalink / raw)
To: Benson Leung
Cc: johan, Jiri Kosina, linux-usb, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Sameer Nanda
In-Reply-To: <CANLzEkvcm5g_T+FsEQF2UFzS5A2u7CWgdTiEJAxidfxgAE5bHw@mail.gmail.com>
On Fri, 2014-11-21 at 17:00 -0800, Benson Leung wrote:
> If devices are already asleep with this flag enabled, that means that
> they are presently configured for remote wake.
Yes, but that doesn't matter. The drivers must be ready for a device
being resumed at any time. Remote wakeup just adds one more reason.
> Waking the device in the case of a close() is appropriate because it
> also has the effect of re-suspending the device with the capability
> disabled, as it is no longer necessary.
But there is very little to be gained by switching off remote wakeup.
The additional energy consumption devices with remote wakeup enabled
will be dwarfed by the energy needed for an additional wakeup.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Richard Cochran @ 2014-11-24 10:01 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Sekhar Nori, Dmitry Torokhov, Lee Jones, Vignesh R, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz,
Felipe Balbi, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-om
In-Reply-To: <5472F30A.1000608@linutronix.de>
On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote:
> On 11/21/2014 02:10 PM, Richard Cochran wrote:
>
> > On the BB white using the LCD4 cape and the shipped debian kernel, the
> > cursor *does* jump away, but not as often or as far as on the custom
> > design I was working with.
>
> This sounds like the ADC is still sampling while the input data becomes
> invalid. Usually there is a resistor on the wiper line and the
> touchscreen manual says how much it should be at least. Could you
> please check if this is properly installed?
Wiper line? This is a four wire device.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v4 0/6] Touchscreen performance related fixes
From: Sebastian Andrzej Siewior @ 2014-11-24 11:51 UTC (permalink / raw)
To: Vignesh R
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, richardcochran, Dmitry Torokhov, Lee Jones,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Brad Griffis, Sanjeev Sharma, Paul Gortmaker, Jan Kardell,
devicetree, linux-kernel, linux-omap, linux-arm-kerne
In-Reply-To: <1415941651-28962-1-git-send-email-vigneshr@ti.com>
* Vignesh R | 2014-11-14 10:37:25 [+0530]:
>This series of patches fix TSC defects related to lag in touchscreen
>performance and cursor jump at touch release. The lag was result of
>udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
>The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
am335x not -evm. The am335x-evm is a board (with its own advisory
document) built around the SoC.
Just testing the v4. I can use now IIO and touchscren at the same time.
back at v1 I reported that it does not work, this has been fixed now.
I had it running for a few minutes, now I see one of WARN_ON() beeing
triggered (I've cut a few numbers so don't wonder about PID 2 and so on):
|dmesg |grep WARNING | wc -l
|10
| dmesg |grep WARNING
|[306.257995] WARNING: CPU: 0 PID: 97 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[365.469591] WARNING: CPU: 0 PID: 58 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[379.255904] WARNING: CPU: 0 PID: 24 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[426.230505] WARNING: CPU: 0 PID: 35 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[435.654091] WARNING: CPU: 0 PID: 28 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[438.897519] WARNING: CPU: 0 PID: 91 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[525.720193] WARNING: CPU: 0 PID: 88 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[527.644770] WARNING: CPU: 0 PID: 38 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[557.218349] WARNING: CPU: 0 PID: 56 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
|[610.077274] WARNING: CPU: 0 PID: 2 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
The complete trace:
|[610.110692] CPU: 0 PID: 4422 Comm: cat Tainted: G W 3.18.0-rc6+ #1745
|[610.118577] [<c00138ec>] (unwind_backtrace) from [<c0011544>] (show_stack+0x10/0x14)
|[610.126772] [<c0011544>] (show_stack) from [<c003c9b0>] (warn_slowpath_common+0x68/0x88)
|[610.135313] [<c003c9b0>] (warn_slowpath_common) from [<c003c9ec>] (warn_slowpath_null+0x1c/0x24)
|[610.144586] [<c003c9ec>] (warn_slowpath_null) from [<bf00569c>] (am335x_tsc_se_set_once+0xf8/0x104 [ti_am335x_tscadc])
|[610.155886] [<bf00569c>] (am335x_tsc_se_set_once [ti_am335x_tscadc]) from [<bf067494>] (tiadc_read_raw+0xbc/0x190 [ti_am335x_adc])
|[610.168326] [<bf067494>] (tiadc_read_raw [ti_am335x_adc]) from [<bf02dccc>] (iio_read_channel_info+0x9c/0xa4 [industrialio])
|[610.180191] [<bf02dccc>] (iio_read_channel_info [industrialio]) from [<c02a42d4>] (dev_attr_show+0x1c/0x48)
|[610.190477] [<c02a42d4>] (dev_attr_show) from [<c013d544>] (sysfs_kf_seq_show+0x8c/0x110)
|[610.199108] [<c013d544>] (sysfs_kf_seq_show) from [<c013c1c8>] (kernfs_seq_show+0x24/0x28)
|[610.207833] [<c013c1c8>] (kernfs_seq_show) from [<c0102658>] (seq_read+0x1b4/0x47c)
|[610.215922] [<c0102658>] (seq_read) from [<c00e6700>] (vfs_read+0x8c/0x148)
|[610.223269] [<c00e6700>] (vfs_read) from [<c00e67fc>] (SyS_read+0x40/0x8c)
|[610.230525] [<c00e67fc>] (SyS_read) from [<c000e640>] (ret_fast_syscall+0x0/0x30)
Could you please look at that one? (I tested it on am335x-evm btw).
Sebastian
^ permalink raw reply
* Re: [PATCH v4 0/6] Touchscreen performance related fixes
From: Vignesh R @ 2014-11-24 12:16 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, richardcochran, Dmitry Torokhov, Lee Jones,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Brad Griffis, Sanjeev Sharma, Paul Gortmaker, Jan Kardell,
devicetree, linux-kernel, linux-omap
In-Reply-To: <20141124115116.GA14997@linutronix.de>
On Monday 24 November 2014 05:21 PM, Sebastian Andrzej Siewior wrote:
> * Vignesh R | 2014-11-14 10:37:25 [+0530]:
>
>> This series of patches fix TSC defects related to lag in touchscreen
>> performance and cursor jump at touch release. The lag was result of
>> udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
>> The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
> am335x not -evm. The am335x-evm is a board (with its own advisory
> document) built around the SoC.
>
> Just testing the v4. I can use now IIO and touchscren at the same time.
> back at v1 I reported that it does not work, this has been fixed now.
> I had it running for a few minutes, now I see one of WARN_ON() beeing
> triggered (I've cut a few numbers so don't wonder about PID 2 and so on):
>
> |dmesg |grep WARNING | wc -l
> |10
> | dmesg |grep WARNING
> |[306.257995] WARNING: CPU: 0 PID: 97 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[365.469591] WARNING: CPU: 0 PID: 58 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[379.255904] WARNING: CPU: 0 PID: 24 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[426.230505] WARNING: CPU: 0 PID: 35 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[435.654091] WARNING: CPU: 0 PID: 28 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[438.897519] WARNING: CPU: 0 PID: 91 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[525.720193] WARNING: CPU: 0 PID: 88 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[527.644770] WARNING: CPU: 0 PID: 38 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[557.218349] WARNING: CPU: 0 PID: 56 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
> |[610.077274] WARNING: CPU: 0 PID: 2 at mfd/ti_am335x_tscadc.c:94 am335x_tsc_se_set_once+0xf8/0x104
>
> The complete trace:
>
> |[610.110692] CPU: 0 PID: 4422 Comm: cat Tainted: G W 3.18.0-rc6+ #1745
> |[610.118577] [<c00138ec>] (unwind_backtrace) from [<c0011544>] (show_stack+0x10/0x14)
> |[610.126772] [<c0011544>] (show_stack) from [<c003c9b0>] (warn_slowpath_common+0x68/0x88)
> |[610.135313] [<c003c9b0>] (warn_slowpath_common) from [<c003c9ec>] (warn_slowpath_null+0x1c/0x24)
> |[610.144586] [<c003c9ec>] (warn_slowpath_null) from [<bf00569c>] (am335x_tsc_se_set_once+0xf8/0x104 [ti_am335x_tscadc])
> |[610.155886] [<bf00569c>] (am335x_tsc_se_set_once [ti_am335x_tscadc]) from [<bf067494>] (tiadc_read_raw+0xbc/0x190 [ti_am335x_adc])
> |[610.168326] [<bf067494>] (tiadc_read_raw [ti_am335x_adc]) from [<bf02dccc>] (iio_read_channel_info+0x9c/0xa4 [industrialio])
> |[610.180191] [<bf02dccc>] (iio_read_channel_info [industrialio]) from [<c02a42d4>] (dev_attr_show+0x1c/0x48)
> |[610.190477] [<c02a42d4>] (dev_attr_show) from [<c013d544>] (sysfs_kf_seq_show+0x8c/0x110)
> |[610.199108] [<c013d544>] (sysfs_kf_seq_show) from [<c013c1c8>] (kernfs_seq_show+0x24/0x28)
> |[610.207833] [<c013c1c8>] (kernfs_seq_show) from [<c0102658>] (seq_read+0x1b4/0x47c)
> |[610.215922] [<c0102658>] (seq_read) from [<c00e6700>] (vfs_read+0x8c/0x148)
> |[610.223269] [<c00e6700>] (vfs_read) from [<c00e67fc>] (SyS_read+0x40/0x8c)
> |[610.230525] [<c00e67fc>] (SyS_read) from [<c000e640>] (ret_fast_syscall+0x0/0x30)
>
> Could you please look at that one? (I tested it on am335x-evm btw).
I have tried running both IIO and TSC at the same time. But I have never
seen WARN_ON() even after running for close to 30 min. Can you send me
the exact script, so that it will be easy to reproduce?
Regards
Vignesh
>
> Sebastian
>
^ permalink raw reply
* Re: [PATCH v4 0/6] Touchscreen performance related fixes
From: Sebastian Andrzej Siewior @ 2014-11-24 12:35 UTC (permalink / raw)
To: Vignesh R
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, richardcochran, Dmitry Torokhov, Lee Jones,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Brad Griffis, Sanjeev Sharma, Paul Gortmaker, Jan Kardell,
devicetree, linux-kernel, linux-omap, linux-arm-kerne
In-Reply-To: <547321A2.6010207@ti.com>
On 11/24/2014 01:16 PM, Vignesh R wrote:
> I have tried running both IIO and TSC at the same time. But I have never
> seen WARN_ON() even after running for close to 30 min. Can you send me
> the exact script, so that it will be easy to reproduce?
Sure thing.
- one shell
evtest /dev/input/event2
- second shell
./iio-test.sh
with:
|#!/bin/sh
|
|while [ 1 = 1 ]
|do
| cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw
|done
the kernel config: https://breakpoint.cc/am335x-config
>
> Regards
> Vignesh
Sebastian
^ permalink raw reply
* [PATCH v2 0/2] Add regulator-haptic driver
From: Jaewon Kim @ 2014-11-24 14:50 UTC (permalink / raw)
To: Kukjin Kim, Dmitry Torokhov, Pankaj Dubey, Dan Murphy,
Chanwoo Choi, Hyunhee Kim
Cc: linux-kernel, linux-input, linux-samsung-soc, Jaewon Kim
This patch series adds regulator-haptic driver.
The regulator-haptic has haptic motor and it is controlled by
voltage of regulator via force feedback framework.
Changes in v2:
- remove driver owner
- merge enable/disable function
- support platform data
- fix wrong suspends_state check in regulator_haptic_resume()
Jaewon Kim (2):
Input: add regulator haptic driver
ARM: dts: Add regulator-haptic device node for exynos3250-rinato
.../devicetree/bindings/input/regulator-haptic.txt | 24 ++
arch/arm/boot/dts/exynos3250-rinato.dts | 7 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/regulator-haptic.c | 247 ++++++++++++++++++++
include/linux/input/regulator-haptic.h | 30 +++
6 files changed, 320 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/2] Input: add regulator haptic driver
From: Jaewon Kim @ 2014-11-24 14:50 UTC (permalink / raw)
To: Kukjin Kim, Dmitry Torokhov, Pankaj Dubey, Dan Murphy,
Chanwoo Choi, Hyunhee Kim
Cc: linux-kernel, linux-input, linux-samsung-soc, Jaewon Kim
In-Reply-To: <1416840651-17141-1-git-send-email-jaewon02.kim@samsung.com>
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Signed-off-by: Hyunhee Kim <hyunhee.kim@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
---
.../devicetree/bindings/input/regulator-haptic.txt | 24 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/regulator-haptic.c | 247 ++++++++++++++++++++
include/linux/input/regulator-haptic.h | 30 +++
5 files changed, 313 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 0000000..5a44e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be "regulator-haptic"
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <&motor_regulator>;
+ max-microvolt = <2700000>;
+ min-microvolt = <1100000>;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate "regulator haptics support"
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate "Retu Power button Driver"
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 0000000..c61dd99
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,247 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim <jaewon02.kim@samsung.com>
+ * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
+ *
+ * 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/input.h>
+#include <linux/input/regulator-haptic.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#define MAX_MAGNITUDE_SHIFT 16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+ struct work_struct work;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool state)
+{
+ int error;
+
+ if (haptic->enabled == state)
+ return;
+
+ if (state)
+ error = regulator_enable(haptic->regulator);
+ else
+ error = regulator_disable(haptic->regulator);
+ if (error) {
+ dev_err(haptic->dev, "cannot enable regulator\n");
+ return;
+ }
+
+ haptic->enabled = state;
+}
+
+static void regulator_haptic_work(struct work_struct *work)
+{
+ struct regulator_haptic *haptic = container_of(work,
+ struct regulator_haptic, work);
+ int error;
+
+ error = regulator_set_voltage(haptic->regulator,
+ haptic->intensity + haptic->min_volt, haptic->max_volt);
+ if (error) {
+ dev_err(haptic->dev, "cannot set regulator voltage\n");
+ return;
+ }
+
+ if (haptic->magnitude)
+ regulator_haptic_enable(haptic, true);
+ else
+ regulator_haptic_enable(haptic, false);
+}
+
+static int regulator_haptic_play_effect(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+ u64 volt_mag_multi;
+
+ haptic->magnitude = effect->u.rumble.strong_magnitude;
+ if (!haptic->magnitude)
+ haptic->magnitude = effect->u.rumble.weak_magnitude;
+
+
+ volt_mag_multi = (u64)(haptic->max_volt - haptic->min_volt) *
+ haptic->magnitude;
+ haptic->intensity = (unsigned int)(volt_mag_multi >>
+ MAX_MAGNITUDE_SHIFT);
+
+ schedule_work(&haptic->work);
+
+ return 0;
+}
+
+static void regulator_haptic_close(struct input_dev *input)
+{
+ struct regulator_haptic *haptic = input_get_drvdata(input);
+
+ cancel_work_sync(&haptic->work);
+ regulator_haptic_enable(haptic, false);
+}
+
+#ifdef CONFIG_OF
+static int regulator_haptic_parse_dt(struct regulator_haptic *haptic)
+{
+ struct device_node *node = haptic->dev->of_node;
+ int error;
+
+ error = of_property_read_u32(node, "max-microvolt", &haptic->max_volt);
+ if (error) {
+ dev_err(haptic->dev, "cannot parse max-microvolt\n");
+ return error;
+ }
+
+ error = of_property_read_u32(node, "min-microvolt", &haptic->min_volt);
+ if (error) {
+ dev_err(haptic->dev, "cannot parse min-microvolt\n");
+ return error;
+ }
+
+ return 0;
+}
+#else
+static int regulator_haptic_parse_dt(struct regulator_haptic *haptic)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
+static int regulator_haptic_probe(struct platform_device *pdev)
+{
+ struct regulator_haptic *haptic;
+ struct regulator_haptic_data *data;
+ struct input_dev *input_dev;
+ int error;
+
+ haptic = devm_kzalloc(&pdev->dev, sizeof(*haptic), GFP_KERNEL);
+ if (!haptic)
+ return -ENOMEM;
+
+ haptic->dev = &pdev->dev;
+ haptic->enabled = false;
+ haptic->suspend_state = false;
+ INIT_WORK(&haptic->work, regulator_haptic_work);
+
+ if (pdev->dev.of_node) {
+ error = regulator_haptic_parse_dt(haptic);
+ if (error) {
+ dev_err(&pdev->dev, "failed to parse device tree\n");
+ return error;
+ }
+ } else {
+ data = dev_get_platdata(&pdev->dev);
+ if (data) {
+ dev_err(&pdev->dev, "failed to get platdata\n");
+ return -EINVAL;
+ }
+
+ haptic->regulator = data->regulator;
+ haptic->max_volt = data->max_volt;
+ haptic->min_volt = data->min_volt;
+ }
+
+ haptic->regulator = devm_regulator_get(&pdev->dev, "haptic");
+ if (IS_ERR(haptic->regulator)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(haptic->regulator);
+ }
+
+ input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ haptic->input_dev = input_dev;
+ haptic->input_dev->name = "regulator-haptic";
+ haptic->input_dev->dev.parent = &pdev->dev;
+ haptic->input_dev->close = regulator_haptic_close;
+ input_set_drvdata(haptic->input_dev, haptic);
+ input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
+
+ error = input_ff_create_memless(input_dev, NULL,
+ regulator_haptic_play_effect);
+ if (error) {
+ dev_err(&pdev->dev, "failed to create force-feedback\n");
+ return error;
+ }
+
+ error = input_register_device(haptic->input_dev);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register input device\n");
+ return error;
+ }
+
+ platform_set_drvdata(pdev, haptic);
+
+ return 0;
+}
+
+static int __maybe_unused regulator_haptic_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
+
+ if (haptic->enabled) {
+ regulator_haptic_enable(haptic, false);
+ haptic->suspend_state = true;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused regulator_haptic_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
+
+ if (haptic->suspend_state) {
+ regulator_haptic_enable(haptic, true);
+ haptic->suspend_state = false;
+ }
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(regulator_haptic_pm_ops,
+ regulator_haptic_suspend, regulator_haptic_resume);
+
+static struct of_device_id regulator_haptic_dt_match[] = {
+ { .compatible = "regulator-haptic" },
+ {},
+};
+
+static struct platform_driver regulator_haptic_driver = {
+ .probe = regulator_haptic_probe,
+ .driver = {
+ .name = "regulator-haptic",
+ .of_match_table = regulator_haptic_dt_match,
+ .pm = ®ulator_haptic_pm_ops,
+ },
+};
+module_platform_driver(regulator_haptic_driver);
+
+MODULE_AUTHOR("Jaewon Kim <jaewon02.kim@samsung.com>");
+MODULE_AUTHOR("Hyunhee Kim <hyunhee.kim@samsung.com>");
+MODULE_DESCRIPTION("Regulator haptic driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/input/regulator-haptic.h b/include/linux/input/regulator-haptic.h
new file mode 100644
index 0000000..15a629c
--- /dev/null
+++ b/include/linux/input/regulator-haptic.h
@@ -0,0 +1,30 @@
+/*
+ * Regulator Haptic Platform Data
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim <jaewon02.kim@samsung.com>
+ * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
+ *
+ * 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.
+ */
+
+#ifndef _REGULATOR_HAPTIC_H
+
+/*
+ * struct regulator_haptic_data - Platform device data
+ *
+ * @regulator: Power supply to the haptic motor
+ * @max_volt: maximum voltage value supplied to the haptic motor.
+ * <The unit of the voltage is a micro>
+ * @min_volt: minimum voltage value supplied to the haptic motor.
+ * <The unit of the voltage is a micro>
+ */
+struct regulator_haptic_data {
+ struct regulator *regulator;
+ unsigned int max_volt;
+ unsigned int min_volt;
+};
+
+#endif /* _REGULATOR_HAPTIC_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato
From: Jaewon Kim @ 2014-11-24 14:50 UTC (permalink / raw)
To: Kukjin Kim, Dmitry Torokhov, Pankaj Dubey, Dan Murphy,
Chanwoo Choi, Hyunhee Kim
Cc: linux-kernel, linux-input, linux-samsung-soc, Jaewon Kim
In-Reply-To: <1416840651-17141-1-git-send-email-jaewon02.kim@samsung.com>
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
---
arch/arm/boot/dts/exynos3250-rinato.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..da03005 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -104,6 +104,13 @@
};
};
};
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <&motor_reg>;
+ min-microvolt = <1100000>;
+ max-microvolt = <2700000>;
+ };
};
&adc {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] hid-multitouch: Add quirk for VTL touch panels
From: Benjamin Tissoires @ 2014-11-24 15:09 UTC (permalink / raw)
To: Mathieu Magnaudet
Cc: Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <1416654127-2433-1-git-send-email-mathieu.magnaudet@enac.fr>
Hi,
On Sat, Nov 22, 2014 at 6:02 AM, Mathieu Magnaudet
<mathieu.magnaudet@gmail.com> wrote:
> VTL panels do not switch to the multitouch mode until the input mode
> feature is read by the host. This should normally be done by
> usbhid, but it looks like an other bug prevents usbhid to properly
> retrieve the feature state. As a workaround, we force the reading of
> the feature in mt_set_input_mode for such devices.
>
> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Indeed, this is still reviewed by me.
> Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
> ---
> v1 -> v2
> use hid_alloc_report_buf instead of kzalloc
>
> drivers/hid/hid-ids.h | 3 +++
> drivers/hid/hid-multitouch.c | 27 +++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 7c86373..d6cc6a9 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -931,6 +931,9 @@
> #define USB_DEVICE_ID_VERNIER_CYCLOPS 0x0004
> #define USB_DEVICE_ID_VERNIER_LCSPEC 0x0006
>
> +#define USB_VENDOR_ID_VTL 0x0306
> +#define USB_DEVICE_ID_VTL_MULTITOUCH_FF3F 0xff3f
> +
> #define USB_VENDOR_ID_WACOM 0x056a
> #define USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH 0x81
> #define USB_DEVICE_ID_WACOM_INTUOS4_BLUETOOTH 0x00BD
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 51e25b9..683cda6 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -67,6 +67,7 @@ MODULE_LICENSE("GPL");
> #define MT_QUIRK_IGNORE_DUPLICATES (1 << 10)
> #define MT_QUIRK_HOVERING (1 << 11)
> #define MT_QUIRK_CONTACT_CNT_ACCURATE (1 << 12)
> +#define MT_QUIRK_FORCE_GET_FEATURE (1 << 13)
>
> #define MT_INPUTMODE_TOUCHSCREEN 0x02
> #define MT_INPUTMODE_TOUCHPAD 0x03
> @@ -150,6 +151,7 @@ static void mt_post_parse(struct mt_device *td);
> #define MT_CLS_FLATFROG 0x0107
> #define MT_CLS_GENERALTOUCH_TWOFINGERS 0x0108
> #define MT_CLS_GENERALTOUCH_PWT_TENFINGERS 0x0109
> +#define MT_CLS_VTL 0x0110
>
> #define MT_DEFAULT_MAXCONTACT 10
> #define MT_MAX_MAXCONTACT 250
> @@ -255,6 +257,11 @@ static struct mt_class mt_classes[] = {
> .sn_move = 2048,
> .maxcontacts = 40,
> },
> + { .name = MT_CLS_VTL,
> + .quirks = MT_QUIRK_ALWAYS_VALID |
> + MT_QUIRK_CONTACT_CNT_ACCURATE |
> + MT_QUIRK_FORCE_GET_FEATURE,
> + },
> { }
> };
>
> @@ -809,6 +816,9 @@ static void mt_set_input_mode(struct hid_device *hdev)
> struct mt_device *td = hid_get_drvdata(hdev);
> struct hid_report *r;
> struct hid_report_enum *re;
> + struct mt_class *cls = &td->mtclass;
> + char *buf;
> + int report_len;
>
> if (td->inputmode < 0)
> return;
> @@ -816,6 +826,18 @@ static void mt_set_input_mode(struct hid_device *hdev)
> re = &(hdev->report_enum[HID_FEATURE_REPORT]);
> r = re->report_id_hash[td->inputmode];
> if (r) {
> + if (cls->quirks & MT_QUIRK_FORCE_GET_FEATURE) {
> + report_len = ((r->size - 1) >> 3) + 1 + (r->id > 0);
I don't like seeing that a third time in the hid subsystem. Mathieu,
would you mind sending an other patch on top of this one which would
export hid_report_len() in hid.h (and replace the calls here and in
wacom_sys.c)?
I would say a "static inline" declaration would be good enough.
Cheers,
Benjamin
> + buf = hid_alloc_report_buf(r, GFP_KERNEL);
> + if (!buf) {
> + hid_err(hdev, "failed to allocate buffer for report\n");
> + return;
> + }
> + hid_hw_raw_request(hdev, r->id, buf, report_len,
> + HID_FEATURE_REPORT,
> + HID_REQ_GET_REPORT);
> + kfree(buf);
> + }
> r->field[0]->value[td->inputmode_index] = td->inputmode_value;
> hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
> }
> @@ -1281,6 +1303,11 @@ static const struct hid_device_id mt_devices[] = {
> MT_USB_DEVICE(USB_VENDOR_ID_UNITEC,
> USB_DEVICE_ID_UNITEC_USB_TOUCH_0A19) },
>
> + /* VTL panels */
> + { .driver_data = MT_CLS_VTL,
> + MT_USB_DEVICE(USB_VENDOR_ID_VTL,
> + USB_DEVICE_ID_VTL_MULTITOUCH_FF3F) },
> +
> /* Wistron panels */
> { .driver_data = MT_CLS_NSMU,
> MT_USB_DEVICE(USB_VENDOR_ID_WISTRON,
> --
> 1.9.3
>
> --
> 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] HID: i2c-hid: fix race condition reading reports
From: Benjamin Tissoires @ 2014-11-24 16:07 UTC (permalink / raw)
To: Antonio Borneo
Cc: Jiri Kosina, linux-input, Benjamin Tissoires,
linux-kernel@vger.kernel.org, Jean-Baptiste Maneyrol
In-Reply-To: <1416415597-21235-1-git-send-email-borneo.antonio@gmail.com>
On Wed, Nov 19, 2014 at 11:46 AM, Antonio Borneo
<borneo.antonio@gmail.com> wrote:
> From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
>
> Current driver uses a common buffer for reading reports either
> synchronously in i2c_hid_get_raw_report() and asynchronously in
> the interrupt handler.
> There is race condition if an interrupt arrives immediately after
> the report is received in i2c_hid_get_raw_report(); the common
> buffer is modified by the interrupt handler with the new report
> and then i2c_hid_get_raw_report() proceed using wrong data.
>
> Fix it by using a separate buffers for synchronous reports.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> [Antonio Borneo: cleanup, rebase to v3.17, submit mainline]
> Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
> Cc: stable@vger.kernel.org
> ---
> V1 -> V2
> rename the synchronous buffer as rawbuf (instead of the
> asynchronous one)
Sorry for the lag and thanks for resubmitting.
This one is reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
>
> drivers/hid/i2c-hid/i2c-hid.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 933bf10..c66e6ac 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -137,6 +137,7 @@ struct i2c_hid {
> * descriptor. */
> unsigned int bufsize; /* i2c buffer size */
> char *inbuf; /* Input buffer */
> + char *rawbuf; /* Raw Input buffer */
> char *cmdbuf; /* Command buffer */
> char *argsbuf; /* Command arguments buffer */
>
> @@ -504,9 +505,11 @@ static void i2c_hid_find_max_report(struct hid_device *hid, unsigned int type,
> static void i2c_hid_free_buffers(struct i2c_hid *ihid)
> {
> kfree(ihid->inbuf);
> + kfree(ihid->rawbuf);
> kfree(ihid->argsbuf);
> kfree(ihid->cmdbuf);
> ihid->inbuf = NULL;
> + ihid->rawbuf = NULL;
> ihid->cmdbuf = NULL;
> ihid->argsbuf = NULL;
> ihid->bufsize = 0;
> @@ -522,10 +525,11 @@ static int i2c_hid_alloc_buffers(struct i2c_hid *ihid, size_t report_size)
> report_size; /* report */
>
> ihid->inbuf = kzalloc(report_size, GFP_KERNEL);
> + ihid->rawbuf = kzalloc(report_size, GFP_KERNEL);
> ihid->argsbuf = kzalloc(args_len, GFP_KERNEL);
> ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
>
> - if (!ihid->inbuf || !ihid->argsbuf || !ihid->cmdbuf) {
> + if (!ihid->inbuf || !ihid->rawbuf || !ihid->argsbuf || !ihid->cmdbuf) {
> i2c_hid_free_buffers(ihid);
> return -ENOMEM;
> }
> @@ -552,12 +556,12 @@ static int i2c_hid_get_raw_report(struct hid_device *hid,
>
> ret = i2c_hid_get_report(client,
> report_type == HID_FEATURE_REPORT ? 0x03 : 0x01,
> - report_number, ihid->inbuf, ask_count);
> + report_number, ihid->rawbuf, ask_count);
>
> if (ret < 0)
> return ret;
>
> - ret_count = ihid->inbuf[0] | (ihid->inbuf[1] << 8);
> + ret_count = ihid->rawbuf[0] | (ihid->rawbuf[1] << 8);
>
> if (ret_count <= 2)
> return 0;
> @@ -566,7 +570,7 @@ static int i2c_hid_get_raw_report(struct hid_device *hid,
>
> /* The query buffer contains the size, dropping it in the reply */
> count = min(count, ret_count - 2);
> - memcpy(buf, ihid->inbuf + 2, count);
> + memcpy(buf, ihid->rawbuf + 2, count);
>
> return count;
> }
> --
> 2.1.3
>
> --
> 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
* qt2160: applying settings
From: Alexander Varnin @ 2014-11-24 17:17 UTC (permalink / raw)
To: linux-input
Hello!
My work task now is related with AT42QT2160 [1] chip, that has qt2160
driver in linux kernel.
There is some settings of this chip, that is required to be set to
registers during initialization or at runtime.
These settings are totally unimplemented in current driver. For example
this are registers 12, 13, 20, 38-53, 54-69.
Registers 38-69 are related to calibration, that is required to be
passed on initialization, and 12 is related to power saving, and need to
be changed at runtime.
Of course, I can just write a hack for my purposes, but I want to solve
it in a rightful (and upstream applicable) way.
I suppose that initialization parameters should be passed in a kinda
platform data and that what is need to be set at runtime should go as a
sysfs node.
Could you please hint me the right way?
[1]
http://www.atmel.com/Images/Atmel-9502-AT42-QTouch-BSW-AT42QT2160_Datasheet.pdf
^ permalink raw reply
* Re: Reported key not released
From: Matthew Garrett @ 2014-11-24 20:04 UTC (permalink / raw)
To: Pali Rohár
Cc: linux-input, platform-driver-x86, Darren Hart, Gabriele Mazzotta,
Alex Hung
In-Reply-To: <201411231413.30076@pali>
On Sun, Nov 23, 2014 at 02:13:30PM +0100, Pali Rohár wrote:
> When I enable or disable this switch it correctly enable or
> disable devices (and also hard rfkill status is set correctly).
If the switch changes the rfkill state, you shouldn't be emitting any
presses - the rfkill state change will notify userspace. Consume the
event in the filter and don't pass it through.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
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: Reported key not released
From: Pali Rohár @ 2014-11-24 20:58 UTC (permalink / raw)
To: Matthew Garrett
Cc: linux-input, platform-driver-x86, Darren Hart, Gabriele Mazzotta,
Alex Hung
In-Reply-To: <20141124200433.GA3459@srcf.ucam.org>
[-- Attachment #1: Type: Text/Plain, Size: 590 bytes --]
On Monday 24 November 2014 21:04:33 Matthew Garrett wrote:
> On Sun, Nov 23, 2014 at 02:13:30PM +0100, Pali Rohár wrote:
> > When I enable or disable this switch it correctly enable or
> > disable devices (and also hard rfkill status is set
> > correctly).
>
> If the switch changes the rfkill state, you shouldn't be
> emitting any presses - the rfkill state change will notify
> userspace. Consume the event in the filter and don't pass it
> through.
So kernel should filter i8042 atk key press events which
represent HW switch?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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