* Re: [PATCH v4 2/4] Input: misc: Add haptic driver on max77693
From: Jaewon Kim @ 2014-09-12 1:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Samuel Ortiz, Lee Jones, Chanwoo Choi, linux-kernel, linux-input
In-Reply-To: <20140911171002.GC13083@core.coreip.homeip.net>
Hello Dmity Torokhov.
2014년 09월 12일 02:10에 Dmitry Torokhov 이(가) 쓴 글:
> On Thu, Sep 11, 2014 at 09:54:20PM +0900, Jaewon Kim wrote:
>> This patch add max77693-haptic device driver to support the haptic controller
>> on MAX77693. The MAX77693 is a Multifunction device with PMIC, CHARGER, LED,
>> MUIC, HAPTIC and the patch is haptic device driver in the MAX77693. This driver
>> support external pwm and LRA(Linear Resonant Actuator) motor. User can control
>> the haptic driver by using force feedback framework.
>>
>> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> How do we want to merge this?
>
thanks for review.
Please merge this input device patch only.
Another patchs will be merged by lee jones.
thanks
Jaewon Kim
--
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] Handle spurious backslash key repeats on some keyboards
From: Fredrik Hallenberg @ 2014-09-11 20:35 UTC (permalink / raw)
To: David Herrmann; +Cc: Dmitry Torokhov, Jiri Kosina, open list:HID CORE LAYER
In-Reply-To: <CANq1E4TjgTs+4_84NZGCctGpNJ4x5VG05_ej9=eGjczcdim6Yg@mail.gmail.com>
Thanks I had no idea about the hwdb but I have tried it now, it works if I use
KEYBOARD_KEY_70031=reserved
on my nordic keyboard, but a US keyboard user would have to use
scancode 70032 instead. If you chose the wrong one the backslash key
will be disabled.
I don't think this is good solution as long as there is no way to
detect which version is used with the hardware matcher string.
However I suppose udev should make it possible to do some kind of
script that does something similar to my original patch, that is,
detects which of the two keys in actually used and disables the other
one.
On Thu, Sep 11, 2014 at 2:41 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Thu, Sep 11, 2014 at 10:50 AM, Fredrik Hallenberg
> <megahallon@gmail.com> wrote:
>>>> The nicest fix, obviously, is to blacklist keys that are not
>>>> physically present on the keyboard. But I assume the keyboard reports
>>>
>>> Hmm, somebody could still load keymap with duplicate keycodes though...
>>>
>>
>> The HID mapping is hardcoded, so only key code 43 will have this
>> problem regardless of user keymaps.
>
> I think Dmitry is talking about setkeycode() which can change the
> keycode a scancode is mapped to. This is indeed a problem, but I
> thought we implicitly tell people to not map two scancodes to the same
> keycode.. we simply don't support it (as we only have 1bit state per
> keycode, and 0bit per scancode).
>
> But this reminds me: we can use udev hwdb and setkeycode() to fix your
> keyboard. Simply add this to /lib/udev/hwdb.d/60-keyboard.hwdb:
> keyboard:name:*Corsair*:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
> KEYBOARD_KEY_32=0
>
> this will run setkeycode(0x32, KEY_RESERVED) and thus disable the key
> 0x32 entirely.
> Adding properly crafted match-rules to udev should solve this mess, I
> guess. Imho, this is the cleanest solution, but depends on udev, of
> course.
>
> Thanks
> David
^ permalink raw reply
* Fwd: [PATCH] HID: wacom: make the WL connection friendly for the desktop
From: Ping Cheng @ 2014-09-11 18:08 UTC (permalink / raw)
To: linux-input, linux-kernel@vger.kernel.org
In-Reply-To: <CAF8JNh+U80vPUQ7263cRGFJCZkzsO7nSAg3KOtfOy5Bsp_Xajw@mail.gmail.com>
On Thu, Sep 11, 2014 at 10:14 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> Currently, tablets connected to the WL receiver all share the same
> VID/PID. There is no way for the user space to know which one is which
> besides parsing the name. We can force the PID to be set to the
> actual hardware. This way, the input device will have the correct PID
> which can be match in libwacom.
Nice job, Benjamin! Thank you, on behalf of wireless tablet users ;-).
>
> With only this trick, the pad input does not inherit the ID_INPUT_TABLET
> udev property from its parent. We can force udev to accept it by declaring
> a BTN_STYLUS which is never used.
BTN_STYLUS can be confusing to userland clients that retrieve it to
decide tool types. But, without it, the client is already confused
with joystick. So, unless we introduce a new tool type, which I
proposed a few years ago and was rejected, we may have to keep clients
confused. With that said, the patch is
>
> This way, tablets connected through WL can be used from the user point of
> view in the same way they are used while connected through wire.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Cheers,
Ping
> ---
>
> Hi guys,
>
> to continue on Ping's work regarding the Wireless reciever, here is a patch
> which allows to have the same user experience regardless the transport layer.
> Unfortunately, a libwacom patch is also required, but once both are applied,
> there is no differences between the wired and wireless connections. Yeah!
>
> Cheers,
> Benjamin
>
> drivers/hid/wacom_sys.c | 2 +-
> drivers/hid/wacom_wac.c | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 9e4e188..a8b7f16 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1035,7 +1035,7 @@ static struct input_dev *wacom_allocate_input(struct wacom *wacom)
> input_dev->uniq = hdev->uniq;
> input_dev->id.bustype = hdev->bus;
> input_dev->id.vendor = hdev->vendor;
> - input_dev->id.product = hdev->product;
> + input_dev->id.product = wacom_wac->pid ? wacom_wac->pid : hdev->product;
> input_dev->id.version = hdev->version;
> input_set_drvdata(input_dev, wacom);
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index c3cbbfb..b8180e4 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1990,6 +1990,9 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
> input_set_abs_params(input_dev, ABS_X, 0, 1, 0, 0);
> input_set_abs_params(input_dev, ABS_Y, 0, 1, 0, 0);
>
> + /* kept for making udev and libwacom accepting the pad */
> + __set_bit(BTN_STYLUS, input_dev->keybit);
> +
> switch (features->type) {
> case GRAPHIRE_BT:
> __set_bit(BTN_0, input_dev->keybit);
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts - fix merge in DT documentation
From: Dmitry Torokhov @ 2014-09-11 17:32 UTC (permalink / raw)
To: Nick Dyer
Cc: Stephen Warren, Javier Martinez Canillas, Stephen Warren,
Yufeng Shen, Benson Leung, Doug Anderson, Olof Johansson,
linux-input, devicetree, linux-samsung-soc, linux-kernel
In-Reply-To: <5411B73E.4040404@itdev.co.uk>
On Thu, Sep 11, 2014 at 03:52:46PM +0100, Nick Dyer wrote:
> On 15/08/14 17:13, Stephen Warren wrote:
> >>> Any comments on this? I would really appreciate if you can expand on how
> >>> this DT property is supposed to be used so I can re-spin the atmel support
> >>> patch for Peach boards.
> >>
> >> The below patch improves the documentation for the gpio-property.
> >
> > That patch makes sense, and is a nice description,
> > Acked-by: Stephen Warren <swarren@nvidia.com>
>
> Hi Dmitry-
>
> Something went a bit wrong in merging f5940231a - there's a bit of repeated
> text that's been introduced.
>
> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Hmm, not sure how I messed this up, but I will queue the patch for the
next push.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/3] psmouse: Add support for detecting FocalTech PS/2 touchpads
From: Hans de Goede @ 2014-09-11 17:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Peter Hutterer, Benjamin Tissoires, linux-input
In-Reply-To: <20140911172619.GD13083@core.coreip.homeip.net>
Hi,
On 09/11/2014 07:26 PM, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Thu, Sep 11, 2014 at 10:50:47AM +0200, Hans de Goede wrote:
>> @@ -722,6 +723,13 @@ static int psmouse_extensions(struct psmouse *psmouse,
>> {
>> bool synaptics_hardware = false;
>>
>> +/* Always check for focaltech, this is safe as it uses pnp-id matching */
>> + if (psmouse_do_detect(focaltech_detect, psmouse, set_properties) == 0) {
>> + /* Not supported yet, use bare protocol */
>> + psmouse_max_proto = max_proto = PSMOUSE_PS2;
>> + goto reset_to_defaults;
>
> Why do we need to jump to a new label instead of simply saying
Once we had figured out that psmouse.proto=bare at least made this
touchpad work in mouse emulation mode, that is the first thing I did, but it
is not enough. We also need to set psmouse_max_proto to short-circuit
psmouse_initialize and do the reset.
I'm trying to get access to one of the affected laptops to see if we can
do better.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 3/3] psmouse: Add support for detecting FocalTech PS/2 touchpads
From: Dmitry Torokhov @ 2014-09-11 17:26 UTC (permalink / raw)
To: Hans de Goede; +Cc: Peter Hutterer, Benjamin Tissoires, linux-input
In-Reply-To: <1410425447-9575-3-git-send-email-hdegoede@redhat.com>
Hi Hans,
On Thu, Sep 11, 2014 at 10:50:47AM +0200, Hans de Goede wrote:
> @@ -722,6 +723,13 @@ static int psmouse_extensions(struct psmouse *psmouse,
> {
> bool synaptics_hardware = false;
>
> +/* Always check for focaltech, this is safe as it uses pnp-id matching */
> + if (psmouse_do_detect(focaltech_detect, psmouse, set_properties) == 0) {
> + /* Not supported yet, use bare protocol */
> + psmouse_max_proto = max_proto = PSMOUSE_PS2;
> + goto reset_to_defaults;
Why do we need to jump to a new label instead of simply saying
return PSMOUSE_PS2;
> + }
> +
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] HID: rmi: check sanity of the incoming report
From: Benjamin Tissoires @ 2014-09-11 17:14 UTC (permalink / raw)
To: Andrew Duggan
Cc: linux-input, linux-kernel@vger.kernel.org, Benjamin Tissoires,
Jiri Kosina
In-Reply-To: <1410397358-15308-1-git-send-email-aduggan@synaptics.com>
On Wed, Sep 10, 2014 at 9:02 PM, Andrew Duggan <aduggan@synaptics.com> wrote:
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> In the Dell XPS 13 9333, it appears that sometimes the bus get confused
> and corrupts the incoming data. It fills the input report with the
> sentinel value "ff". Synaptics told us that such behavior does not comes
> from the touchpad itself, so we filter out such reports here.
>
> Unfortunately, we can not simply discard the incoming data because they
> may contain useful information. Most of the time, the misbehavior is
> quite near the end of the report, so we can still use the valid part of
> it.
>
> Fixes:
> https://bugzilla.redhat.com/show_bug.cgi?id=1123584
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
> Here is a v2 based of Benjamin's patch with the feedback from the list.
> I added size checks to rmi_f11_input_event and rmi_f30_input_event. For F30 I
> print a message it any data is missing so that a user is notified if a button click
> doesn't get reported. Also, I decided to only warn once if a corrupted report is
> received. Based on the data I have seen I don't think dropped reports will be a
> significanly noticible issue. But, I also added a debug message which could be turned on
> if soneone wants to see exactly how often incomplete reports are being received.
Fine by me. Thanks for fixing this Andrew!
Cheers,
Benjamin
>
> drivers/hid/hid-rmi.c | 44 ++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 578bbe6..54966ca 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -320,10 +320,7 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
> int offset;
> int i;
>
> - if (size < hdata->f11.report_size)
> - return 0;
> -
> - if (!(irq & hdata->f11.irq_mask))
> + if (!(irq & hdata->f11.irq_mask) || size <= 0)
> return 0;
>
> offset = (hdata->max_fingers >> 2) + 1;
> @@ -332,9 +329,19 @@ static int rmi_f11_input_event(struct hid_device *hdev, u8 irq, u8 *data,
> int fs_bit_position = (i & 0x3) << 1;
> int finger_state = (data[fs_byte_position] >> fs_bit_position) &
> 0x03;
> + int position = offset + 5 * i;
> +
> + if (position + 5 > size) {
> + /* partial report, go on with what we received */
> + printk_once(KERN_WARNING
> + "%s %s: Detected incomplete finger report. Finger reports may occasionally get dropped on this platform.\n",
> + dev_driver_string(&hdev->dev),
> + dev_name(&hdev->dev));
> + hid_dbg(hdev, "Incomplete finger report\n");
> + break;
> + }
>
> - rmi_f11_process_touch(hdata, i, finger_state,
> - &data[offset + 5 * i]);
> + rmi_f11_process_touch(hdata, i, finger_state, &data[position]);
> }
> input_mt_sync_frame(hdata->input);
> input_sync(hdata->input);
> @@ -352,6 +359,11 @@ static int rmi_f30_input_event(struct hid_device *hdev, u8 irq, u8 *data,
> if (!(irq & hdata->f30.irq_mask))
> return 0;
>
> + if (size < (int)hdata->f30.report_size) {
> + hid_warn(hdev, "Click Button pressed, but the click data is missing\n");
> + return 0;
> + }
> +
> for (i = 0; i < hdata->gpio_led_count; i++) {
> if (test_bit(i, &hdata->button_mask)) {
> value = (data[i / 8] >> (i & 0x07)) & BIT(0);
> @@ -412,9 +424,29 @@ static int rmi_read_data_event(struct hid_device *hdev, u8 *data, int size)
> return 1;
> }
>
> +static int rmi_check_sanity(struct hid_device *hdev, u8 *data, int size)
> +{
> + int valid_size = size;
> + /*
> + * On the Dell XPS 13 9333, the bus sometimes get confused and fills
> + * the report with a sentinel value "ff". Synaptics told us that such
> + * behavior does not comes from the touchpad itself, so we filter out
> + * such reports here.
> + */
> +
> + while ((data[valid_size - 1] == 0xff) && valid_size > 0)
> + valid_size--;
> +
> + return valid_size;
> +}
> +
> static int rmi_raw_event(struct hid_device *hdev,
> struct hid_report *report, u8 *data, int size)
> {
> + size = rmi_check_sanity(hdev, data, size);
> + if (size < 2)
> + return 0;
> +
> switch (data[0]) {
> case RMI_READ_DATA_REPORT_ID:
> return rmi_read_data_event(hdev, data, size);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] HID: wacom: make the WL connection friendly for the desktop
From: Benjamin Tissoires @ 2014-09-11 17:14 UTC (permalink / raw)
To: Jiri Kosina, Ping Cheng, killertofu; +Cc: linux-input, linux-kernel
Currently, tablets connected to the WL receiver all share the same
VID/PID. There is no way for the user space to know which one is which
besides parsing the name. We can force the PID to be set to the
actual hardware. This way, the input device will have the correct PID
which can be match in libwacom.
With only this trick, the pad input does not inherit the ID_INPUT_TABLET
udev property from its parent. We can force udev to accept it by declaring
a BTN_STYLUS which is never used.
This way, tablets connected through WL can be used from the user point of
view in the same way they are used while connected through wire.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi guys,
to continue on Ping's work regarding the Wireless reciever, here is a patch
which allows to have the same user experience regardless the transport layer.
Unfortunately, a libwacom patch is also required, but once both are applied,
there is no differences between the wired and wireless connections. Yeah!
Cheers,
Benjamin
drivers/hid/wacom_sys.c | 2 +-
drivers/hid/wacom_wac.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 9e4e188..a8b7f16 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1035,7 +1035,7 @@ static struct input_dev *wacom_allocate_input(struct wacom *wacom)
input_dev->uniq = hdev->uniq;
input_dev->id.bustype = hdev->bus;
input_dev->id.vendor = hdev->vendor;
- input_dev->id.product = hdev->product;
+ input_dev->id.product = wacom_wac->pid ? wacom_wac->pid : hdev->product;
input_dev->id.version = hdev->version;
input_set_drvdata(input_dev, wacom);
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index c3cbbfb..b8180e4 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1990,6 +1990,9 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
input_set_abs_params(input_dev, ABS_X, 0, 1, 0, 0);
input_set_abs_params(input_dev, ABS_Y, 0, 1, 0, 0);
+ /* kept for making udev and libwacom accepting the pad */
+ __set_bit(BTN_STYLUS, input_dev->keybit);
+
switch (features->type) {
case GRAPHIRE_BT:
__set_bit(BTN_0, input_dev->keybit);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v4 2/4] Input: misc: Add haptic driver on max77693
From: Dmitry Torokhov @ 2014-09-11 17:10 UTC (permalink / raw)
To: Jaewon Kim
Cc: Samuel Ortiz, Lee Jones, Chanwoo Choi, linux-kernel, linux-input
In-Reply-To: <1410440062-19963-3-git-send-email-jaewon02.kim@samsung.com>
On Thu, Sep 11, 2014 at 09:54:20PM +0900, Jaewon Kim wrote:
> This patch add max77693-haptic device driver to support the haptic controller
> on MAX77693. The MAX77693 is a Multifunction device with PMIC, CHARGER, LED,
> MUIC, HAPTIC and the patch is haptic device driver in the MAX77693. This driver
> support external pwm and LRA(Linear Resonant Actuator) motor. User can control
> the haptic driver by using force feedback framework.
>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
How do we want to merge this?
--
Dmitry
^ permalink raw reply
* Re: Status of the plan to set i8042.nomux=1 by default ?
From: Dmitry Torokhov @ 2014-09-11 17:05 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-usb
In-Reply-To: <54109401.4000809@redhat.com>
On Wed, Sep 10, 2014 at 08:10:09PM +0200, Hans de Goede wrote:
> Hi Dmitry,
>
> I wonder what the status of $subject is ?
>
> I'm asking because a user joined the discussion here:
> https://bugzilla.kernel.org/show_bug.cgi?id=77391
>
> And I ended up debugging his problem a bit, and his laptop
> needs i8042.nomux=1 .
>
> I've asked him for dmi strings for adding a quirk, but as discussed
> a while back, it may be better to just flip the default.
I'll queue your patch for 3.17 and work on flipping the default for 3.18
then.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: atkbd - Fix broken keyboard in another LG laptop
From: Dmitry Torokhov @ 2014-09-11 17:03 UTC (permalink / raw)
To: Jaime Velasco Juan; +Cc: linux-input, stable, Sheng-Liang Song
In-Reply-To: <87mwa6xfnv.fsf@gmail.com>
On Thu, Sep 11, 2014 at 05:53:08PM +0100, Jaime Velasco Juan wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
>
> > Hi Jamie,
> >
> > On Wed, Sep 10, 2014 at 07:06:14PM +0100, Jaime Velasco Juan wrote:
> >> This model has the same quirk as others, see 3d725caa9dcc "Input:
> >> atkbd - fix keyboard not working on some LG laptops"
> >>
> >
> > How about the patch below instead?
> >
>
> It works for me just the same, thanks.
Thanks, I'll add you as also "tested-by" and queue for the next push.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: atkbd - Fix broken keyboard in another LG laptop
From: Jaime Velasco Juan @ 2014-09-11 16:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, stable, Sheng-Liang Song
In-Reply-To: <20140910205213.GD38736@core.coreip.homeip.net>
Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> Hi Jamie,
>
> On Wed, Sep 10, 2014 at 07:06:14PM +0100, Jaime Velasco Juan wrote:
>> This model has the same quirk as others, see 3d725caa9dcc "Input:
>> atkbd - fix keyboard not working on some LG laptops"
>>
>
> How about the patch below instead?
>
It works for me just the same, thanks.
Regards
> --
> Dmitry
>
> Input: atkbd - do not try 'deactivate' keyboard on any LG laptops
>
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> We are getting more and more reports about LG laptops not having
> functioning keyboard if we try to deactivate keyboard during probe.
> Given that having keyboard deactivated is merely "nice to have"
> instead of a hard requirement for probing, let's disable it on all
> LG boxes instead of trying to hunt down particular models.
>
> This change is prompted by patches trying to add "LG Electronics"/"ROCKY"
> and "LG Electronics"/"LW60-F27B" to the DMI list.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=77051
>
> Cc: stable@vger.kernel.org
> Reported-by: Jaime Velasco Juan <jsagarribay@gmail.com>
> Reported-by: Georgios Tsalikis <georgios@tsalikis.net>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/keyboard/atkbd.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 2dd1d0d..6f5d795 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -1791,14 +1791,6 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
> {
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
> - },
> - .callback = atkbd_deactivate_fixup,
> - },
> - {
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
> },
> .callback = atkbd_deactivate_fixup,
> },
^ permalink raw reply
* [PATCH] Input: atmel_mxt_ts - fix merge in DT documentation
From: Nick Dyer @ 2014-09-11 14:52 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Stephen Warren, Javier Martinez Canillas, Stephen Warren,
Yufeng Shen, Benson Leung, Doug Anderson, Olof Johansson,
linux-input, devicetree, linux-samsung-soc, linux-kernel
In-Reply-To: <53EE319A.1030304@wwwdotorg.org>
On 15/08/14 17:13, Stephen Warren wrote:
>>> Any comments on this? I would really appreciate if you can expand on how
>>> this DT property is supposed to be used so I can re-spin the atmel support
>>> patch for Peach boards.
>>
>> The below patch improves the documentation for the gpio-property.
>
> That patch makes sense, and is a nice description,
> Acked-by: Stephen Warren <swarren@nvidia.com>
Hi Dmitry-
Something went a bit wrong in merging f5940231a - there's a bit of repeated
text that's been introduced.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 4 ----
1 file changed, 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index 0ac23f2..1852906 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -11,10 +11,6 @@ Required properties:
Optional properties for main touchpad device:
-- linux,gpio-keymap: An array of up to 4 entries indicating the Linux
- keycode generated by each GPIO. Linux keycodes are defined in
- <dt-bindings/input/input.h>.
-
- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
on GPIO bit changes. An array of up to 8 entries can be provided
indicating the Linux keycode mapped to each bit of the status byte,
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/4] mfd: max77693: add haptic of_compatible in mfd_cell
From: Jaewon Kim @ 2014-09-11 12:54 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: Chanwoo Choi, linux-kernel, linux-input, Jaewon Kim
In-Reply-To: <1410440062-19963-1-git-send-email-jaewon02.kim@samsung.com>
This patch add haptic of_compatible in order to use the haptic
device driver using Devicetree.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/mfd/max77693.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index fbfed56..5b516fe 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -46,7 +46,10 @@ static const struct mfd_cell max77693_devs[] = {
{ .name = "max77693-charger", },
{ .name = "max77693-flash", },
{ .name = "max77693-muic", },
- { .name = "max77693-haptic", },
+ {
+ .name = "max77693-haptic",
+ .of_compatible = "maxim,max77693-haptic",
+ },
};
static const struct regmap_config max77693_regmap_config = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/4] Input: misc: Add haptic driver on max77693
From: Jaewon Kim @ 2014-09-11 12:54 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: Chanwoo Choi, linux-kernel, linux-input, Jaewon Kim
In-Reply-To: <1410440062-19963-1-git-send-email-jaewon02.kim@samsung.com>
This patch add max77693-haptic device driver to support the haptic controller
on MAX77693. The MAX77693 is a Multifunction device with PMIC, CHARGER, LED,
MUIC, HAPTIC and the patch is haptic device driver in the MAX77693. This driver
support external pwm and LRA(Linear Resonant Actuator) motor. User can control
the haptic driver by using force feedback framework.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/max77693-haptic.c | 354 ++++++++++++++++++++++++++++++++++
include/linux/mfd/max77693-private.h | 9 +
4 files changed, 376 insertions(+)
create mode 100644 drivers/input/misc/max77693-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..c597c52 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -144,6 +144,18 @@ config INPUT_M68K_BEEP
tristate "M68k Beeper support"
depends on M68K
+config INPUT_MAX77693_HAPTIC
+ tristate "MAXIM MAX77693 haptic controller support"
+ depends on MFD_MAX77693 && PWM
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controller
+ on MAXIM MAX77693 chip. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as module, choose M here: the
+ module will be called max77693-haptic.
+
config INPUT_MAX8925_ONKEY
tristate "MAX8925 ONKEY support"
depends on MFD_MAX8925
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4955ad3..b28570c 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
+obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
diff --git a/drivers/input/misc/max77693-haptic.c b/drivers/input/misc/max77693-haptic.c
new file mode 100644
index 0000000..9662b6b
--- /dev/null
+++ b/drivers/input/misc/max77693-haptic.c
@@ -0,0 +1,354 @@
+/*
+ * max77693-haptic.c - MAXIM MAX77693 Haptic device driver
+ *
+ * Copyright (C) 2014 Samsung Electronics
+ * Jaewon Kim <jaewon02.kim@samsung.com>
+ *
+ * This program is not provided / owned by Maxim Integrated Products.
+ *
+ * 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/err.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/regmap.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+#include <linux/regulator/consumer.h>
+#include <linux/mfd/max77693.h>
+#include <linux/mfd/max77693-private.h>
+
+#define MAX_MAGNITUDE_SHIFT 16
+
+enum max77693_haptic_motor_type {
+ MAX77693_HAPTIC_ERM = 0,
+ MAX77693_HAPTIC_LRA,
+};
+
+enum max77693_haptic_pulse_mode {
+ MAX77693_HAPTIC_EXTERNAL_MODE = 0,
+ MAX77693_HAPTIC_INTERNAL_MODE,
+};
+
+enum max77693_haptic_pwm_divisor {
+ MAX77693_HAPTIC_PWM_DIVISOR_32 = 0,
+ MAX77693_HAPTIC_PWM_DIVISOR_64,
+ MAX77693_HAPTIC_PWM_DIVISOR_128,
+ MAX77693_HAPTIC_PWM_DIVISOR_256,
+};
+
+struct max77693_haptic {
+ struct regmap *regmap_pmic;
+ struct regmap *regmap_haptic;
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct pwm_device *pwm_dev;
+ struct regulator *motor_reg;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int magnitude;
+ unsigned int pwm_duty;
+ enum max77693_haptic_motor_type type;
+ enum max77693_haptic_pulse_mode mode;
+ enum max77693_haptic_pwm_divisor pwm_divisor;
+
+ struct work_struct work;
+};
+
+static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
+{
+ int ret;
+ int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+
+ ret = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+ if (ret) {
+ dev_err(haptic->dev, "cannot configuration pwm\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int max77693_haptic_configure(struct max77693_haptic *haptic,
+ bool enable)
+{
+ int ret;
+ unsigned int value;
+
+ value = ((haptic->type << MAX77693_CONFIG2_MODE) |
+ (enable << MAX77693_CONFIG2_MEN) |
+ (haptic->mode << MAX77693_CONFIG2_HTYP) |
+ (haptic->pwm_divisor));
+
+ ret = regmap_write(haptic->regmap_haptic,
+ MAX77693_HAPTIC_REG_CONFIG2, value);
+ if (ret) {
+ dev_err(haptic->dev, "cannot write haptic regmap\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int max77693_haptic_lowsys(struct max77693_haptic *haptic,
+ bool enable)
+{
+ int ret;
+
+ ret = regmap_update_bits(haptic->regmap_pmic,
+ MAX77693_PMIC_REG_LSCNFG,
+ MAX77693_PMIC_LOW_SYS_MASK,
+ enable << MAX77693_PMIC_LOW_SYS_SHIFT);
+ if (ret) {
+ dev_err(haptic->dev, "cannot update pmic regmap\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void max77693_haptic_enable(struct max77693_haptic *haptic)
+{
+ int ret;
+
+ if (haptic->enabled)
+ return;
+
+ ret = pwm_enable(haptic->pwm_dev);
+ if (ret) {
+ dev_err(haptic->dev, "cannot enable haptic pwm device");
+ return;
+ }
+
+ ret = max77693_haptic_lowsys(haptic, true);
+ if (ret)
+ goto err_enable_lowsys;
+
+ ret = max77693_haptic_configure(haptic, true);
+ if (ret)
+ goto err_enable_config;
+
+ haptic->enabled = true;
+
+ return;
+
+err_enable_config:
+ max77693_haptic_lowsys(haptic, false);
+err_enable_lowsys:
+ pwm_disable(haptic->pwm_dev);
+}
+
+static void max77693_haptic_disable(struct max77693_haptic *haptic)
+{
+ int ret;
+
+ if (!haptic->enabled)
+ return;
+
+ ret = max77693_haptic_configure(haptic, false);
+ if (ret)
+ return;
+
+ ret = max77693_haptic_lowsys(haptic, false);
+ if (ret)
+ goto err_disable_lowsys;
+
+ pwm_disable(haptic->pwm_dev);
+ haptic->enabled = false;
+
+ return;
+
+err_disable_lowsys:
+ max77693_haptic_configure(haptic, true);
+}
+
+static void max77693_haptic_play_work(struct work_struct *work)
+{
+ struct max77693_haptic *haptic =
+ container_of(work, struct max77693_haptic, work);
+ int ret;
+
+ ret = max77693_haptic_set_duty_cycle(haptic);
+ if (ret) {
+ dev_err(haptic->dev, "cannot set duty cycle\n");
+ return;
+ }
+
+ if (haptic->magnitude)
+ max77693_haptic_enable(haptic);
+ else
+ max77693_haptic_disable(haptic);
+}
+
+static int max77693_haptic_play_effect(struct input_dev *dev, void *data,
+ struct ff_effect *effect)
+{
+ struct max77693_haptic *haptic = input_get_drvdata(dev);
+ uint64_t period_mag_multi;
+
+ haptic->magnitude = effect->u.rumble.strong_magnitude;
+ if (!haptic->magnitude)
+ haptic->magnitude = effect->u.rumble.weak_magnitude;
+
+ /*
+ * The magnitude comes from force-feedback interface.
+ * The formula convert magnitude to pwm_duty as following:
+ * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0xFFFF)
+ */
+ period_mag_multi = (int64_t)(haptic->pwm_dev->period *
+ haptic->magnitude);
+ haptic->pwm_duty = (unsigned int)(period_mag_multi >>
+ MAX_MAGNITUDE_SHIFT);
+
+ schedule_work(&haptic->work);
+
+ return 0;
+}
+
+static int max77693_haptic_open(struct input_dev *dev)
+{
+ struct max77693_haptic *haptic = input_get_drvdata(dev);
+ int ret;
+
+ ret = regulator_enable(haptic->motor_reg);
+ if (ret) {
+ dev_err(haptic->dev, "cannot enable regulator\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void max77693_haptic_close(struct input_dev *dev)
+{
+ struct max77693_haptic *haptic = input_get_drvdata(dev);
+ int ret;
+
+ cancel_work_sync(&haptic->work);
+ max77693_haptic_disable(haptic);
+
+ ret = regulator_disable(haptic->motor_reg);
+ if (ret)
+ dev_err(haptic->dev, "cannot disable regulator\n");
+}
+
+static int max77693_haptic_probe(struct platform_device *pdev)
+{
+ struct max77693_dev *max77693 = dev_get_drvdata(pdev->dev.parent);
+ struct max77693_haptic *haptic;
+ int ret = 0;
+
+ haptic = devm_kzalloc(&pdev->dev, sizeof(*haptic), GFP_KERNEL);
+ if (!haptic)
+ return -ENOMEM;
+
+ haptic->regmap_pmic = max77693->regmap;
+ haptic->regmap_haptic = max77693->regmap_haptic;
+ haptic->dev = &pdev->dev;
+ haptic->type = MAX77693_HAPTIC_LRA;
+ haptic->mode = MAX77693_HAPTIC_EXTERNAL_MODE;
+ haptic->pwm_divisor = MAX77693_HAPTIC_PWM_DIVISOR_128;
+ haptic->suspend_state = false;
+
+ INIT_WORK(&haptic->work, max77693_haptic_play_work);
+
+ /* Get pwm and regulatot for haptic device */
+ haptic->pwm_dev = devm_pwm_get(&pdev->dev, NULL);
+ if (IS_ERR(haptic->pwm_dev)) {
+ dev_err(&pdev->dev, "failed to get pwm device\n");
+ return PTR_ERR(haptic->pwm_dev);
+ }
+
+ haptic->motor_reg = devm_regulator_get(&pdev->dev, "haptic");
+ if (IS_ERR(haptic->motor_reg)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(haptic->motor_reg);
+ }
+
+ /* Initialize input device for haptic device */
+ haptic->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!haptic->input_dev) {
+ dev_err(&pdev->dev, "failed to allocate input device\n");
+ return -ENOMEM;
+ }
+
+ haptic->input_dev->name = "max77693-haptic";
+ haptic->input_dev->id.version = 1;
+ haptic->input_dev->dev.parent = &pdev->dev;
+ haptic->input_dev->open = max77693_haptic_open;
+ haptic->input_dev->close = max77693_haptic_close;
+ input_set_drvdata(haptic->input_dev, haptic);
+ input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
+
+ ret = input_ff_create_memless(haptic->input_dev, NULL,
+ max77693_haptic_play_effect);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to create force-feedback\n");
+ return ret;
+ }
+
+ ret = input_register_device(haptic->input_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register input device\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, haptic);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int max77693_haptic_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct max77693_haptic *haptic = platform_get_drvdata(pdev);
+
+ if (haptic->enabled) {
+ max77693_haptic_disable(haptic);
+ haptic->suspend_state = true;
+ }
+
+ return 0;
+}
+
+static int max77693_haptic_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct max77693_haptic *haptic = platform_get_drvdata(pdev);
+
+ if (haptic->suspend_state) {
+ max77693_haptic_enable(haptic);
+ haptic->suspend_state = false;
+ }
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(max77693_haptic_pm_ops,
+ max77693_haptic_suspend, max77693_haptic_resume);
+
+static struct platform_driver max77693_haptic_driver = {
+ .driver = {
+ .name = "max77693-haptic",
+ .owner = THIS_MODULE,
+ .pm = &max77693_haptic_pm_ops,
+ },
+ .probe = max77693_haptic_probe,
+};
+module_platform_driver(max77693_haptic_driver);
+
+MODULE_AUTHOR("Jaewon Kim <jaewon02.kim@samsung.com>");
+MODULE_DESCRIPTION("MAXIM MAX77693 Haptic driver");
+MODULE_ALIAS("platform:max77693-haptic");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/max77693-private.h b/include/linux/mfd/max77693-private.h
index c466ff3..d0e578f 100644
--- a/include/linux/mfd/max77693-private.h
+++ b/include/linux/mfd/max77693-private.h
@@ -251,6 +251,15 @@ enum max77693_haptic_reg {
MAX77693_HAPTIC_REG_END,
};
+/* max77693-pmic LSCNFG configuraton register */
+#define MAX77693_PMIC_LOW_SYS_MASK 0x80
+#define MAX77693_PMIC_LOW_SYS_SHIFT 7
+
+/* max77693-haptic configuration register */
+#define MAX77693_CONFIG2_MODE 7
+#define MAX77693_CONFIG2_MEN 6
+#define MAX77693_CONFIG2_HTYP 5
+
enum max77693_irq_source {
LED_INT = 0,
TOPSYS_INT,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 1/4] mfd: max77693: Initialize haptic register map
From: Jaewon Kim @ 2014-09-11 12:54 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: Chanwoo Choi, linux-kernel, linux-input, Jaewon Kim
In-Reply-To: <1410440062-19963-1-git-send-email-jaewon02.kim@samsung.com>
This patch add regmap_haptic initialization to use haptic register map
in haptic device driver.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/max77693.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index 249c139..fbfed56 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -144,6 +144,12 @@ static const struct regmap_irq_chip max77693_muic_irq_chip = {
.num_irqs = ARRAY_SIZE(max77693_muic_irqs),
};
+static const struct regmap_config max77693_regmap_haptic_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MAX77693_HAPTIC_REG_END,
+};
+
static int max77693_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -193,6 +199,15 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
}
i2c_set_clientdata(max77693->haptic, max77693);
+ max77693->regmap_haptic = devm_regmap_init_i2c(max77693->haptic,
+ &max77693_regmap_haptic_config);
+ if (IS_ERR(max77693->regmap_haptic)) {
+ ret = PTR_ERR(max77693->regmap_haptic);
+ dev_err(max77693->dev,
+ "failed to initialize haptic register map: %d\n", ret);
+ goto err_regmap;
+ }
+
/*
* Initialize register map for MUIC device because use regmap-muic
* instance of MUIC device when irq of max77693 is initialized
@@ -204,7 +219,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
ret = PTR_ERR(max77693->regmap_muic);
dev_err(max77693->dev,
"failed to allocate register map: %d\n", ret);
- goto err_regmap_muic;
+ goto err_regmap;
}
ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
@@ -214,7 +229,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
&max77693->irq_data_led);
if (ret) {
dev_err(max77693->dev, "failed to add irq chip: %d\n", ret);
- goto err_regmap_muic;
+ goto err_regmap;
}
ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
@@ -265,7 +280,7 @@ err_irq_charger:
regmap_del_irq_chip(max77693->irq, max77693->irq_data_topsys);
err_irq_topsys:
regmap_del_irq_chip(max77693->irq, max77693->irq_data_led);
-err_regmap_muic:
+err_regmap:
i2c_unregister_device(max77693->haptic);
err_i2c_haptic:
i2c_unregister_device(max77693->muic);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/4] mfd: max77693: Update DT binding to support haptic
From: Jaewon Kim @ 2014-09-11 12:54 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: Chanwoo Choi, linux-kernel, linux-input, Jaewon Kim
In-Reply-To: <1410440062-19963-1-git-send-email-jaewon02.kim@samsung.com>
This patch add haptic DT binding documentation and example
to support haptic driver in max77693 Multifunction device.
Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
---
Documentation/devicetree/bindings/mfd/max77693.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
index 11921cc..d178b9e 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -27,6 +27,17 @@ Optional properties:
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+- haptic : The haptic of max77693 have to be instantiated under subnod
+ named "haptic" using the following haptic format in example.
+ Haptic sensation from motor can be changed by changing a period cycle in pwms.
+
+ Required properties:
+ - compatible : Must be "maxim,max77693-hpatic"
+ - haptic-supply : power supply for haptic motor
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+ - pwms : phandle to the physical PWM device,
+ [*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+
Example:
max77693@66 {
compatible = "maxim,max77693";
@@ -52,4 +63,11 @@ Example:
regulator-boot-on;
};
};
+
+ haptic {
+ compatible = "maxim,max77693-haptic";
+ haptic-supply = <&haptic_supply>;
+ pwms = <&pwm 0 40000 0>;
+ pwm-names = "haptic";
+ };
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 0/4] Add max77693 haptic driver
From: Jaewon Kim @ 2014-09-11 12:54 UTC (permalink / raw)
To: Dmitry Torokhov, Samuel Ortiz, Lee Jones
Cc: Chanwoo Choi, linux-kernel, linux-input, Jaewon Kim
This series adds max77693 haptic driver.
The max77693 is a Multifunction device with PMIC, CHARGER, LED,
MUIC, HAPTIC and this series is haptic device driver in MAX77693.
The haptic driver use regmap method for i2c communication and
support force feedback framework in input device.
Changes in v4:
- mfd : fix tabbing in mfd_cell
- driver : move regulator enable/disable to input open()/close()
- driver : add resume function
Changes in v3:
- driver : remove mutex in workqueue
- driver : mv max77693_haptic_set_duty_cyle() to workqueue.
- driver : remove max77693_haptic_remove[]
- driver : add suspend() function to turn-off entering suspend.
Changes in v2:
- split to documentation and mfd patchs.
- Documentation : change explanation of haptic
- Documentation : remove pwm-names propertie in example
Jaewon Kim (4):
mfd: max77693: Initialize haptic register map
Input: misc: Add haptic driver on max77693
mfd: max77693: add haptic of_compatible in mfd_cell
mfd: max77693: Update DT binding to support haptic
Documentation/devicetree/bindings/mfd/max77693.txt | 18 +
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/max77693-haptic.c | 354 ++++++++++++++++++++
drivers/mfd/max77693.c | 26 +-
include/linux/mfd/max77693-private.h | 9 +
6 files changed, 416 insertions(+), 4 deletions(-)
create mode 100644 drivers/input/misc/max77693-haptic.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] Handle spurious backslash key repeats on some keyboards
From: David Herrmann @ 2014-09-11 12:41 UTC (permalink / raw)
To: Fredrik Hallenberg; +Cc: Dmitry Torokhov, Jiri Kosina, open list:HID CORE LAYER
In-Reply-To: <CAMsZVf_NiHJW9mv+k7Tu4hX5EfcAosnyCfn7G1pVWR8oG5qQ0Q@mail.gmail.com>
Hi
On Thu, Sep 11, 2014 at 10:50 AM, Fredrik Hallenberg
<megahallon@gmail.com> wrote:
>>> The nicest fix, obviously, is to blacklist keys that are not
>>> physically present on the keyboard. But I assume the keyboard reports
>>
>> Hmm, somebody could still load keymap with duplicate keycodes though...
>>
>
> The HID mapping is hardcoded, so only key code 43 will have this
> problem regardless of user keymaps.
I think Dmitry is talking about setkeycode() which can change the
keycode a scancode is mapped to. This is indeed a problem, but I
thought we implicitly tell people to not map two scancodes to the same
keycode.. we simply don't support it (as we only have 1bit state per
keycode, and 0bit per scancode).
But this reminds me: we can use udev hwdb and setkeycode() to fix your
keyboard. Simply add this to /lib/udev/hwdb.d/60-keyboard.hwdb:
keyboard:name:*Corsair*:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
KEYBOARD_KEY_32=0
this will run setkeycode(0x32, KEY_RESERVED) and thus disable the key
0x32 entirely.
Adding properly crafted match-rules to udev should solve this mess, I
guess. Imho, this is the cleanest solution, but depends on udev, of
course.
Thanks
David
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
From: Nick Dyer @ 2014-09-11 12:24 UTC (permalink / raw)
To: Javier Martinez Canillas, Wolfram Sang
Cc: Sjoerd Simons, Lee Jones, Dmitry Torokhov, linux-input,
linux-kernel, linux-samsung-soc, Bowens, Alan, Benson Leung,
yufeng Shen
In-Reply-To: <54118A7E.4090902@collabora.co.uk>
On 11/09/14 12:41, Javier Martinez Canillas wrote:
> On 09/11/2014 01:35 PM, Wolfram Sang wrote:
>>>> This is a workaround. It would make sense, however, to add it because we
>>>> want to support i2c_board_info structures.
>>>>
>>>
>>> I think it really depends if an IP block can be used on non-DT platforms
>>> (which I think is true for this trackpad) but if a driver is for an IP block
>>> that can only be used on a DT-only platform (e.g: a PMIC that is controlled
>>> over I2C and is only compatible with a DT-only SoC) then I don't think we need
>>> to support the i2c_board_info structure and can get rid of the I2C ID table on
>>> these drivers once Lee series land.
>>
>> That is exactly what I meant. It should be only added if there is a
>> reason other than "workaround". If you say, it doesn't make sense on
>> non-DT, then it should not be added.
>
> Sorry for explaining myself badly. I just tried to say that this is a decision
> that has to be made on a per-driver basis but I don't really know if makes
> sense or not in this case since I don't know if this device is (or could be)
> shipped on non-DT platforms. Nick is in a much better position to answer that
> question.
There are plenty of out-of-tree users of this driver which don't use DT.
The most significant use I'm aware of is on Chromium OS systems.
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: misc: introduce palmas-pwrbutton
From: Nishanth Menon @ 2014-09-11 12:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Murphy, Dan, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140910211353.GE38736@core.coreip.homeip.net>
Hi Dimtry,
On 14:13-20140910, Dmitry Torokhov wrote:
> On Thu, Aug 21, 2014 at 02:01:43PM -0500, Nishanth Menon wrote:
> > On 08/21/2014 01:03 PM, Dmitry Torokhov wrote:
> >
> > I believe I have taken care of other concerns on v2, but..Arrgh.. I
> > did not reply to this comment..
> > > BTW, I do not think you need to use of_node_get/put here, it's not going anywhere.
> > It has been mentioned as a good practice to ensure we use get_put in
> > to ensure reference count is appropriately maintained. So, I have'nt
> > changed that in v3.
>
> You only need to maintain reference count if you pass the handle on.
> Otherwise you'd have to do get/put every time you dereference something.
>
> Anyway, I did a few changes to the driver (no need to store current
> state, do not fre einput device after unregister, etc.), could you
> please tell me if the version below still works for you?
[...]
Thanks for taking the time to do all the changes - they are awesome and
the resultant driver does work.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
From: Javier Martinez Canillas @ 2014-09-11 11:41 UTC (permalink / raw)
To: Wolfram Sang
Cc: Nick Dyer, Sjoerd Simons, Lee Jones, Dmitry Torokhov, linux-input,
linux-kernel, linux-samsung-soc, Bowens, Alan
In-Reply-To: <20140911113548.GB5149@katana>
Hello Wolfram,
On 09/11/2014 01:35 PM, Wolfram Sang wrote:
>
>> > This is a workaround. It would make sense, however, to add it because we
>> > want to support i2c_board_info structures.
>> >
>>
>> I think it really depends if an IP block can be used on non-DT platforms
>> (which I think is true for this trackpad) but if a driver is for an IP block
>> that can only be used on a DT-only platform (e.g: a PMIC that is controlled
>> over I2C and is only compatible with a DT-only SoC) then I don't think we need
>> to support the i2c_board_info structure and can get rid of the I2C ID table on
>> these drivers once Lee series land.
>
> That is exactly what I meant. It should be only added if there is a
> reason other than "workaround". If you say, it doesn't make sense on
> non-DT, then it should not be added.
>
Sorry for explaining myself badly. I just tried to say that this is a decision
that has to be made on a per-driver basis but I don't really know if makes
sense or not in this case since I don't know if this device is (or could be)
shipped on non-DT platforms. Nick is in a much better position to answer that
question.
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
From: Wolfram Sang @ 2014-09-11 11:35 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Nick Dyer, Sjoerd Simons, Lee Jones, Dmitry Torokhov, linux-input,
linux-kernel, linux-samsung-soc, Bowens, Alan
In-Reply-To: <54118687.8040802@collabora.co.uk>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
> > This is a workaround. It would make sense, however, to add it because we
> > want to support i2c_board_info structures.
> >
>
> I think it really depends if an IP block can be used on non-DT platforms
> (which I think is true for this trackpad) but if a driver is for an IP block
> that can only be used on a DT-only platform (e.g: a PMIC that is controlled
> over I2C and is only compatible with a DT-only SoC) then I don't think we need
> to support the i2c_board_info structure and can get rid of the I2C ID table on
> these drivers once Lee series land.
That is exactly what I meant. It should be only added if there is a
reason other than "workaround". If you say, it doesn't make sense on
non-DT, then it should not be added.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
From: Javier Martinez Canillas @ 2014-09-11 11:24 UTC (permalink / raw)
To: Wolfram Sang, Nick Dyer
Cc: Sjoerd Simons, Lee Jones, Dmitry Torokhov, linux-input,
linux-kernel, linux-samsung-soc, Bowens, Alan
In-Reply-To: <20140911110829.GA5149@katana>
Hello Wolfram,
On 09/11/2014 01:08 PM, Wolfram Sang wrote:
>
> Funny timing. I am just reviewing the series from Lee and also stumbled
> over modaliases, too...
>
> On Thu, Sep 11, 2014 at 10:19:54AM +0100, Nick Dyer wrote:
>> On 11/09/14 09:38, Javier Martinez Canillas wrote:
>> > To expand on what Sjoerd already said and just to be sure everyone is on the
>> > same page.
>> >
>> > The problem is that right now the driver reports the following modalias:
>> >
>> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
>> > i2c:maxtouch
>> >
>> > but if you look at the module information, that is not a valid alias:
>> >
>> > # modinfo atmel_mxt_ts | grep alias
>> > alias: i2c:mXT224
>> > alias: i2c:atmel_mxt_tp
>> > alias: i2c:atmel_mxt_ts
>> > alias: i2c:qt602240_ts
>> > alias: of:N*T*Catmel,maxtouch*
>> >
>> > which means that udev/kmod can't load the module automatically based on the
>> > alias information.
>> >
>> > The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
>> > MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
>> >
>> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
>> > i2c:maxtouch
>> >
>> > # modinfo atmel_mxt_ts | grep alias
>> > alias: i2c:mXT224
>> > alias: i2c:maxtouch
>> > alias: i2c:atmel_mxt_tp
>> > alias: i2c:atmel_mxt_ts
>> > alias: i2c:qt602240_ts
>> >
>> > which matches the reported uevent so the module will be auto-loaded.
>> >
>> > This is because the I2C subsystem hardcodes i2c:<client->name>, if you look at
>> > drivers/i2c/i2c-core.c:
>> >
>> > /* uevent helps with hotplug: modprobe -q $(MODALIAS) */
>> > static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>> > {
>> > ...
>> > if (add_uevent_var(env, "MODALIAS=%s%s",
>> > I2C_MODULE_PREFIX, client->name))
>> > ...
>> > }
>> >
>> > I've looked at Lee's series and AFAICT that remains the same so I second
>> > Sjoerd that module auto-loading will continue to be broken.
>
> I think the above code in the i2c core needs a fix. Will have a closer
> look after lunch.
>
Agreed, I just posted an RFC patch [0] with the fix but as Sjoerd pointed out
on an internal review, changing that will regress all the drivers that were
relying on the old behavior.
>> The i2c aliases are a bit confusing. The original device the driver was
>> written for was called qt602240, which was renamed by Atmel to mXT224 when
>> the chip series was called "maXTouch". The driver now actually supports
>> many other chips which aren't listed (more than 20 devices that I've
>> personally tested). I could add them all, but it would be an extremely long
>> list. It may be preferable to use the generic name maXTouch.
>
> This is probably true for some more I2C devices. Like RTCs being
> compatible or, most prominent, EEPROMS. I don't want to have a list of
> all vendors producing 24c02s if they are all compatible. If generic
> entries are frowned upon, I'd agree on a "first come, first served" policy:
> Somebody provides one compatible-property with the vendor which happens
> to be on that board, and the others have to reuse that
> compatible-property since they are, well, compatible.
>
Agreed.
>> So I think the sensible thing to do here would be to add "maxtouch" to the
>> i2c list to fix the module autoload issue.
>
> This is a workaround. It would make sense, however, to add it because we
> want to support i2c_board_info structures.
>
I think it really depends if an IP block can be used on non-DT platforms
(which I think is true for this trackpad) but if a driver is for an IP block
that can only be used on a DT-only platform (e.g: a PMIC that is controlled
over I2C and is only compatible with a DT-only SoC) then I don't think we need
to support the i2c_board_info structure and can get rid of the I2C ID table on
these drivers once Lee series land.
> Regards,
>
> Wolfram
>
Best regards,
Javier
[0]: https://patchwork.ozlabs.org/patch/388200/
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts: Add of node type to the i2c table
From: Wolfram Sang @ 2014-09-11 11:08 UTC (permalink / raw)
To: Nick Dyer
Cc: Javier Martinez Canillas, Sjoerd Simons, Lee Jones,
Dmitry Torokhov, linux-input, linux-kernel, linux-samsung-soc,
Bowens, Alan
In-Reply-To: <5411693A.3050300@itdev.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]
Funny timing. I am just reviewing the series from Lee and also stumbled
over modaliases, too...
On Thu, Sep 11, 2014 at 10:19:54AM +0100, Nick Dyer wrote:
> On 11/09/14 09:38, Javier Martinez Canillas wrote:
> > To expand on what Sjoerd already said and just to be sure everyone is on the
> > same page.
> >
> > The problem is that right now the driver reports the following modalias:
> >
> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> > i2c:maxtouch
> >
> > but if you look at the module information, that is not a valid alias:
> >
> > # modinfo atmel_mxt_ts | grep alias
> > alias: i2c:mXT224
> > alias: i2c:atmel_mxt_tp
> > alias: i2c:atmel_mxt_ts
> > alias: i2c:qt602240_ts
> > alias: of:N*T*Catmel,maxtouch*
> >
> > which means that udev/kmod can't load the module automatically based on the
> > alias information.
> >
> > The aliases are filled by both MODULE_DEVICE_TABLE(i2c, mxt_id) and
> > MODULE_DEVICE_TABLE(of, mxt_of_match) so after Sjoerd's patch:
> >
> > # cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
> > i2c:maxtouch
> >
> > # modinfo atmel_mxt_ts | grep alias
> > alias: i2c:mXT224
> > alias: i2c:maxtouch
> > alias: i2c:atmel_mxt_tp
> > alias: i2c:atmel_mxt_ts
> > alias: i2c:qt602240_ts
> >
> > which matches the reported uevent so the module will be auto-loaded.
> >
> > This is because the I2C subsystem hardcodes i2c:<client->name>, if you look at
> > drivers/i2c/i2c-core.c:
> >
> > /* uevent helps with hotplug: modprobe -q $(MODALIAS) */
> > static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > {
> > ...
> > if (add_uevent_var(env, "MODALIAS=%s%s",
> > I2C_MODULE_PREFIX, client->name))
> > ...
> > }
> >
> > I've looked at Lee's series and AFAICT that remains the same so I second
> > Sjoerd that module auto-loading will continue to be broken.
I think the above code in the i2c core needs a fix. Will have a closer
look after lunch.
> The i2c aliases are a bit confusing. The original device the driver was
> written for was called qt602240, which was renamed by Atmel to mXT224 when
> the chip series was called "maXTouch". The driver now actually supports
> many other chips which aren't listed (more than 20 devices that I've
> personally tested). I could add them all, but it would be an extremely long
> list. It may be preferable to use the generic name maXTouch.
This is probably true for some more I2C devices. Like RTCs being
compatible or, most prominent, EEPROMS. I don't want to have a list of
all vendors producing 24c02s if they are all compatible. If generic
entries are frowned upon, I'd agree on a "first come, first served" policy:
Somebody provides one compatible-property with the vendor which happens
to be on that board, and the others have to reuse that
compatible-property since they are, well, compatible.
> So I think the sensible thing to do here would be to add "maxtouch" to the
> i2c list to fix the module autoload issue.
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
Regards,
Wolfram
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 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