* Re: [PATCH] HID: sony: Add force feedback support for Dualshock3 USB
From: Jiri Kosina @ 2013-11-11 10:26 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: linux-input, Colin Leitner
In-Reply-To: <1384021557-24106-1-git-send-email-sven@narfation.org>
On Sat, 9 Nov 2013, Sven Eckelmann wrote:
> Sony Dualshock 3 controllers have two motors which can be used to provide
> simple force feedback rumble effects. The right motor is can be used to create
> a weak rumble effect but does not allow to set the force. The left motor is
> used to create a strong rumble effect with adjustable intensity.
>
> The state of both motors can be changed using HID_OUTPUT_REPORT packets and
> have no timing information. FF memless is used to keep track of the timing and
> the sony driver just generates the necessary URBs.
>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)
From: Henrik Rydberg @ 2013-11-11 10:27 UTC (permalink / raw)
To: Florian Echtler, Dmitry Torokhov
Cc: linux-input, benjamin.tissoires, dh.herrmann
In-Reply-To: <5280AC87.4020905@butterbrot.org>
>> Also, does the patch below mess up or device or it still works?
> I'll test this tomorrow (no access to SUR40 today). If everything works,
> should I resubmit my patch with yours included or just tell you that
> it's fine?
No need to resubmit, a confirmation will do nicely. Thanks!
Henrik
^ permalink raw reply
* Re: [PATCH 2/2] Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs
From: Forest Bond @ 2013-11-11 13:06 UTC (permalink / raw)
To: Jiri Kosina
Cc: Dmitry Torokhov, linux-input, Sebastian Dalfuß, Daniel Ritz,
Max Weninger, Christian Engelmayer
In-Reply-To: <alpine.LNX.2.00.1311111121290.7751@pobox.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi,
On Mon, Nov 11, 2013 at 11:21:42AM +0100, Jiri Kosina wrote:
> On Fri, 8 Nov 2013, Dmitry Torokhov wrote:
>
> > > > From: Forest Bond <forest.bond@rapidrollout.com>
> > > >
> > > > The HID driver now handles these devices, regardless of what protocol
> > > > the device claims it supports.
> > > >
> > > > Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
> > >
> > > Dmitry,
> > >
> > > could you please Ack this, so that it can be applied together with 1/2?
> > > Thanks!
> >
> > Jiri,
> >
> > Sorry for the delay. Yes, please merge through your tree.
> >
> > Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Thanks, I have applied both patches now.
Thanks for your help, Dmitry and Jiri.
-Forest
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCHv3 1/2] Input: twl4030-keypad - add device tree support
From: Pavel Machek @ 2013-11-11 22:19 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Dmitry Torokhov, Dmitry Torokhov, linux-input,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Grant Likely, devicetree, linux-doc,
linux-kernel
In-Reply-To: <1383948866-32672-2-git-send-email-sre@debian.org>
Hi!
> + if (of_get_property(np, "linux,input-no-autorepeat", NULL))
> + keypad_data->no_autorepeat = true;
>From 2/2:
+Optional Properties specific to linux:
+- linux,keypad-no-autorepeat: do not enable autorepeat feature.
I'm confused now.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: wacom - add support for three new Intuos devices
From: Peter Hutterer @ 2013-11-12 0:56 UTC (permalink / raw)
To: Chris Bagwell
Cc: Ping Cheng, linux-input@vger.kernel.org, Dmitry Torokhov,
Ping Cheng
In-Reply-To: <CAGzDe_a_VF7697u66LsWoV+C6+VLRzQJ8FWnct9SGK6DQurULQ@mail.gmail.com>
On Thu, Nov 07, 2013 at 08:25:40PM -0600, Chris Bagwell wrote:
> On Thu, Oct 10, 2013 at 4:17 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> > This series of models added a hardware switch to turn touch
> > data on/off. To report the state of the switch, SW_TOUCH
> > is added in include/uapi/linux/input.h.
>
> So I guess the big point is this patch can't go in until a SW_TOUCH
> goes in first.
>
> Since the 1/2 or this 2/2 series has already gone in, would you mind
> breaking this
> remaining patch up into the basic support for new Intuos (without the
> SW_TOUCH) and
> then a separate patch to add SW_TOUCH support on top of that? Then
> the basic support can go in ASAP.
>
> I only have comments on this patch related to the SW_TOUCH part... things like:
>
> * should the SW_TOUCH be reported against the wireless interface or
> the touch interface... userland apps may have an opinion on which is
> best.
against the touch device. from userspace, seeing that something is a touch
device but SW_TOUCH is off is a lot easier to deal with than having a
separate device report SW_TOUCH and we'll have to find the matching
userspace device this applies to.
(unless I'm misreading something here)
> * the part with updating SW_TOUCH from unrelated interfaces could use
> a review by someone like Dmitry for possible issues.
> * It would be better if you didn't add that EV_SW for HW that will
> not report the SW_TOUCH.
definitely agree here.
I still don't think that changing the INTUOS naming convention to use
underscores is a good idea given that in a year's time no-one will care that
some intuos used to be bamboos but we'll be stuck with the mismatched naming
scheme for a while.
Acked-by: Peter Hutterer <peter.hutterer@who-t.net> otherwise though
Cheers,
Peter
> If you break the patch into 2, you can add my line for the basic
> support without SW_TOUCH:
>
> Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
>
> Chris
>
> >
> > The driver is also updated to process wireless devices that do
> > not support touch interface.
> >
> > Tested-by: Jason Gerecke <killertofu@gmail.com>
> > Signed-off-by: Ping Cheng <pingc@wacom.com>
> > ---
> > v2: Change SW_TOUCH_ENABLED to SW_TOUCH and clear BTN_TOUCH bit
> > for button only interfaces as suggested by Peter Hutterer.
> > ---
> > drivers/input/tablet/wacom_sys.c | 16 +++++++-
> > drivers/input/tablet/wacom_wac.c | 87 ++++++++++++++++++++++++++++++++--------
> > drivers/input/tablet/wacom_wac.h | 7 ++++
> > include/uapi/linux/input.h | 1 +
> > 4 files changed, 93 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
> > index 7bdb5e9..efd9729 100644
> > --- a/drivers/input/tablet/wacom_sys.c
> > +++ b/drivers/input/tablet/wacom_sys.c
> > @@ -1190,12 +1190,15 @@ static void wacom_wireless_work(struct work_struct *work)
> > wacom_wac1->features.device_type = BTN_TOOL_PEN;
> > snprintf(wacom_wac1->name, WACOM_NAME_MAX, "%s (WL) Pen",
> > wacom_wac1->features.name);
> > + wacom_wac1->shared->touch_max = wacom_wac1->features.touch_max;
> > + wacom_wac1->shared->type = wacom_wac1->features.type;
> > error = wacom_register_input(wacom1);
> > if (error)
> > goto fail;
> >
> > /* Touch interface */
> > - if (wacom_wac1->features.touch_max) {
> > + if (wacom_wac1->features.touch_max ||
> > + wacom_wac1->features.type == INTUOS_HT) {
> > wacom_wac2->features =
> > *((struct wacom_features *)id->driver_info);
> > wacom_wac2->features.pktlen = WACOM_PKGLEN_BBTOUCH3;
> > @@ -1210,6 +1213,10 @@ static void wacom_wireless_work(struct work_struct *work)
> > error = wacom_register_input(wacom2);
> > if (error)
> > goto fail;
> > +
> > + if (wacom_wac1->features.type == INTUOS_HT &&
> > + wacom_wac1->features.touch_max)
> > + wacom_wac->shared->touch_input = wacom_wac2->input;
> > }
> >
> > error = wacom_initialize_battery(wacom);
> > @@ -1318,7 +1325,7 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
> > * HID descriptor. If this is the touch interface (wMaxPacketSize
> > * of WACOM_PKGLEN_BBTOUCH3), override the table values.
> > */
> > - if (features->type >= INTUOS5S && features->type <= INTUOSPL) {
> > + if (features->type >= INTUOS5S && features->type <= INTUOS_HT) {
> > if (endpoint->wMaxPacketSize == WACOM_PKGLEN_BBTOUCH3) {
> > features->device_type = BTN_TOOL_FINGER;
> > features->pktlen = WACOM_PKGLEN_BBTOUCH3;
> > @@ -1390,6 +1397,11 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
> > }
> > }
> >
> > + if (wacom_wac->features.type == INTUOS_HT && wacom_wac->features.touch_max) {
> > + if (wacom_wac->features.device_type == BTN_TOOL_FINGER)
> > + wacom_wac->shared->touch_input = wacom_wac->input;
> > + }
> > +
> > return 0;
> >
> > fail5: wacom_destroy_leds(wacom);
> > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> > index 9c8eded..4cbea85 100644
> > --- a/drivers/input/tablet/wacom_wac.c
> > +++ b/drivers/input/tablet/wacom_wac.c
> > @@ -1176,10 +1176,17 @@ static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)
> > static void wacom_bpt3_button_msg(struct wacom_wac *wacom, unsigned char *data)
> > {
> > struct input_dev *input = wacom->input;
> > + struct wacom_features *features = &wacom->features;
> >
> > - input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
> > + if (features->type == INTUOS_HT) {
> > + input_report_key(input, BTN_LEFT, (data[1] & 0x02) != 0);
> > + input_report_key(input, BTN_BACK, (data[1] & 0x08) != 0);
> > + } else {
> > +
> > + input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
> > + input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
> > + }
> > input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0);
> > - input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
> > input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
> > }
> >
> > @@ -1213,13 +1220,23 @@ static int wacom_bpt3_touch(struct wacom_wac *wacom)
> >
> > static int wacom_bpt_pen(struct wacom_wac *wacom)
> > {
> > + struct wacom_features *features = &wacom->features;
> > struct input_dev *input = wacom->input;
> > unsigned char *data = wacom->data;
> > int prox = 0, x = 0, y = 0, p = 0, d = 0, pen = 0, btn1 = 0, btn2 = 0;
> >
> > - if (data[0] != 0x02)
> > + if (data[0] != WACOM_REPORT_PENABLED && data[0] != WACOM_REPORT_USB_MODE)
> > return 0;
> >
> > + if (data[0] == WACOM_REPORT_USB_MODE) {
> > + if ((features->type == INTUOS_HT) && features->touch_max) {
> > + input_report_switch(wacom->shared->touch_input,
> > + SW_TOUCH, data[8] & 0x40);
> > + input_sync(wacom->shared->touch_input);
> > + }
> > + return 0;
> > + }
> > +
> > prox = (data[1] & 0x20) == 0x20;
> >
> > /*
> > @@ -1297,13 +1314,20 @@ static int wacom_wireless_irq(struct wacom_wac *wacom, size_t len)
> > unsigned char *data = wacom->data;
> > int connected;
> >
> > - if (len != WACOM_PKGLEN_WIRELESS || data[0] != 0x80)
> > + if (len != WACOM_PKGLEN_WIRELESS || data[0] != WACOM_REPORT_WL_MODE)
> > return 0;
> >
> > connected = data[1] & 0x01;
> > if (connected) {
> > int pid, battery;
> >
> > + if ((wacom->shared->type == INTUOS_HT) &&
> > + wacom->shared->touch_max) {
> > + input_report_switch(wacom->shared->touch_input,
> > + SW_TOUCH, data[5] & 0x40);
> > + input_sync(wacom->shared->touch_input);
> > + }
> > +
> > pid = get_unaligned_be16(&data[6]);
> > battery = data[5] & 0x3f;
> > if (wacom->pid != pid) {
> > @@ -1391,6 +1415,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
> > break;
> >
> > case BAMBOO_PT:
> > + case INTUOS_HT:
> > sync = wacom_bpt_irq(wacom_wac, len);
> > break;
> >
> > @@ -1459,7 +1484,7 @@ void wacom_setup_device_quirks(struct wacom_features *features)
> >
> > /* these device have multiple inputs */
> > if (features->type >= WIRELESS ||
> > - (features->type >= INTUOS5S && features->type <= INTUOSPL) ||
> > + (features->type >= INTUOS5S && features->type <= INTUOS_HT) ||
> > (features->oVid && features->oPid))
> > features->quirks |= WACOM_QUIRK_MULTI_INPUT;
> >
> > @@ -1531,7 +1556,8 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
> > struct wacom_features *features = &wacom_wac->features;
> > int i;
> >
> > - input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> > + input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) |
> > + BIT_MASK(EV_SW);
> >
> > __set_bit(BTN_TOUCH, input_dev->keybit);
> > __set_bit(ABS_MISC, input_dev->absbit);
> > @@ -1771,33 +1797,48 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
> > __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > break;
> >
> > + case INTUOS_HT:
> > + if (features->touch_max &&
> > + (features->device_type == BTN_TOOL_FINGER))
> > + __set_bit(SW_TOUCH, input_dev->swbit);
> > + /* fall through */
> > +
> > case BAMBOO_PT:
> > __clear_bit(ABS_MISC, input_dev->absbit);
> >
> > - __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > -
> > if (features->device_type == BTN_TOOL_FINGER) {
> > - unsigned int flags = INPUT_MT_POINTER;
> >
> > __set_bit(BTN_LEFT, input_dev->keybit);
> > __set_bit(BTN_FORWARD, input_dev->keybit);
> > __set_bit(BTN_BACK, input_dev->keybit);
> > __set_bit(BTN_RIGHT, input_dev->keybit);
> >
> > - if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
> > - input_set_abs_params(input_dev,
> > + if (features->touch_max) {
> > + /* touch interface */
> > + unsigned int flags = INPUT_MT_POINTER;
> > +
> > + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > + if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
> > + input_set_abs_params(input_dev,
> > ABS_MT_TOUCH_MAJOR,
> > 0, features->x_max, 0, 0);
> > - input_set_abs_params(input_dev,
> > + input_set_abs_params(input_dev,
> > ABS_MT_TOUCH_MINOR,
> > 0, features->y_max, 0, 0);
> > + } else {
> > + __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> > + __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
> > + flags = 0;
> > + }
> > + input_mt_init_slots(input_dev, features->touch_max, flags);
> > } else {
> > - __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
> > - __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
> > - flags = 0;
> > + /* buttons/keys only interface */
> > + __clear_bit(ABS_X, input_dev->absbit);
> > + __clear_bit(ABS_Y, input_dev->absbit);
> > + __clear_bit(BTN_TOUCH, input_dev->keybit);
> > }
> > - input_mt_init_slots(input_dev, features->touch_max, flags);
> > } else if (features->device_type == BTN_TOOL_PEN) {
> > + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
> > __set_bit(BTN_TOOL_PEN, input_dev->keybit);
> > __set_bit(BTN_STYLUS, input_dev->keybit);
> > @@ -2194,6 +2235,17 @@ static const struct wacom_features wacom_features_0x300 =
> > static const struct wacom_features wacom_features_0x301 =
> > { "Wacom Bamboo One M", WACOM_PKGLEN_BBPEN, 21648, 13530, 1023,
> > 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> > +static const struct wacom_features wacom_features_0x302 =
> > + { "Wacom Intuos PT S", WACOM_PKGLEN_BBPEN, 15200, 9500, 1023,
> > + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
> > + .touch_max = 16 };
> > +static const struct wacom_features wacom_features_0x303 =
> > + { "Wacom Intuos PT M", WACOM_PKGLEN_BBPEN, 21600, 13500, 1023,
> > + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
> > + .touch_max = 16 };
> > +static const struct wacom_features wacom_features_0x30E =
> > + { "Wacom Intuos S", WACOM_PKGLEN_BBPEN, 15200, 9500, 1023,
> > + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> > static const struct wacom_features wacom_features_0x6004 =
> > { "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
> > 0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
> > @@ -2329,6 +2381,9 @@ const struct usb_device_id wacom_ids[] = {
> > { USB_DEVICE_WACOM(0x10D) },
> > { USB_DEVICE_WACOM(0x300) },
> > { USB_DEVICE_WACOM(0x301) },
> > + { USB_DEVICE_WACOM(0x302) },
> > + { USB_DEVICE_DETAILED(0x303, USB_CLASS_HID, 0, 0) },
> > + { USB_DEVICE_DETAILED(0x30E, USB_CLASS_HID, 0, 0) },
> > { USB_DEVICE_WACOM(0x304) },
> > { USB_DEVICE_DETAILED(0x314, USB_CLASS_HID, 0, 0) },
> > { USB_DEVICE_DETAILED(0x315, USB_CLASS_HID, 0, 0) },
> > diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
> > index fd23a37..ba9e335 100644
> > --- a/drivers/input/tablet/wacom_wac.h
> > +++ b/drivers/input/tablet/wacom_wac.h
> > @@ -54,6 +54,8 @@
> > #define WACOM_REPORT_TPCST 16
> > #define WACOM_REPORT_TPC1FGE 18
> > #define WACOM_REPORT_24HDT 1
> > +#define WACOM_REPORT_WL_MODE 128
> > +#define WACOM_REPORT_USB_MODE 192
> >
> > /* device quirks */
> > #define WACOM_QUIRK_MULTI_INPUT 0x0001
> > @@ -81,6 +83,7 @@ enum {
> > INTUOSPS,
> > INTUOSPM,
> > INTUOSPL,
> > + INTUOS_HT,
> > WACOM_21UX2,
> > WACOM_22HD,
> > DTK,
> > @@ -129,6 +132,10 @@ struct wacom_features {
> > struct wacom_shared {
> > bool stylus_in_proximity;
> > bool touch_down;
> > + /* for wireless device to access USB interfaces */
> > + unsigned touch_max;
> > + int type;
> > + struct input_dev *touch_input;
> > };
> >
> > struct wacom_wac {
> > diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> > index d08abf9..70e53e8 100644
> > --- a/include/uapi/linux/input.h
> > +++ b/include/uapi/linux/input.h
> > @@ -855,6 +855,7 @@ struct input_keymap_entry {
> > #define SW_FRONT_PROXIMITY 0x0b /* set = front proximity sensor active */
> > #define SW_ROTATE_LOCK 0x0c /* set = rotate locked/disabled */
> > #define SW_LINEIN_INSERT 0x0d /* set = inserted */
> > +#define SW_TOUCH 0x0e /* set = touch switch turned on (touch events off) */
> > #define SW_MAX 0x0f
> > #define SW_CNT (SW_MAX+1)
> >
> > --
> > 1.8.1.2
> >
> --
> 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 2/2] Input: wacom - add support for three new Intuos devices
From: Chris Bagwell @ 2013-11-12 2:50 UTC (permalink / raw)
To: Ping Cheng; +Cc: linux-input@vger.kernel.org, Dmitry Torokhov, Peter Hutterer
In-Reply-To: <CAF8JNh+Vh3FswdDYPffi603iJmnnSgQDtfiJVfP=mqCqTW8dXQ@mail.gmail.com>
On Fri, Nov 8, 2013 at 1:13 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> On Thu, Nov 7, 2013 at 6:25 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>> On Thu, Oct 10, 2013 at 4:17 PM, Ping Cheng <pinglinux@gmail.com> wrote:
>>> This series of models added a hardware switch to turn touch
>>> data on/off. To report the state of the switch, SW_TOUCH
>>> is added in include/uapi/linux/input.h.
>>
>> So I guess the big point is this patch can't go in until a SW_TOUCH
>> goes in first.
>>
>> Since the 1/2 or this 2/2 series has already gone in, would you mind
>> breaking this
>> remaining patch up into the basic support for new Intuos (without the
>> SW_TOUCH) and
>> then a separate patch to add SW_TOUCH support on top of that? Then
>> the basic support can go in ASAP.
>
> Chris, thank you for pushing the process forward.
>
> SW_TOUCH is truly part of the basic support for the new series. The
> main new feature of this series is touch switch. If we do not report
> its status in the same patch, it means we are not reporting a complete
> set of data.
>
>> I only have comments on this patch related to the SW_TOUCH part... things like:
>>
>> * should the SW_TOUCH be reported against the wireless interface or
>> the touch interface... userland apps may have an opinion on which is
>> best.
>
> We can not report SW_TOUCH status from touch interface since once
> touch is turned off (by end users), no events can go on touch
> interface. Plus, we do not know when a user may switch touch on.
> That's why SW_TOUCH are regularly updated and reported through
> wireless interface for wireless connection.
I think I made wrong assumption of HW. Does HW stop sending touch
events when switch is toggled or is switch an indication to ignore
touch events in either driver or userland?
I was thinking it was for later case. When userland has to ignore, it
is not easy to know switch value on /dev/input/foo really means what
to do related to events on /dev/input/bar. So thats were my thoughts
were about moving it to input that needs to be disabled. In former
case, it just status so not so important to decide which input to
report over.
>
>> * the part with updating SW_TOUCH from unrelated interfaces could use
>
> It is not unrelated interface. It is how it works.
>
>> a review by someone like Dmitry for possible issues.
I meant any issues with parsing data in context of /dev/input/foo but
doing an input_sync(/dev/input/bar) in that same context. Probably no
issue but I don't know kernel internals to be sure.
>> * It would be better if you didn't add that EV_SW for HW that will
>> not report the SW_TOUCH.
>
> I can consider that in the next version.
>
>> If you break the patch into 2, you can add my line for the basic
>
> I'd like to know your opinion about my comments before updating the
> patch. IMO, using two patches to process one set of raw data
> complicates the support.
Assuming SW_TOUCH for this device is only for status reporting, I
don't have much opinion. If it because a request to disable touch
events in userland then I think it should move to device its related
to.
Chris
>
> Ping
>
>> support without SW_TOUCH:
>>
>> Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
>>
>> Chris
>>
>>>
>>> The driver is also updated to process wireless devices that do
>>> not support touch interface.
>>>
>>> Tested-by: Jason Gerecke <killertofu@gmail.com>
>>> Signed-off-by: Ping Cheng <pingc@wacom.com>
>>> ---
>>> v2: Change SW_TOUCH_ENABLED to SW_TOUCH and clear BTN_TOUCH bit
>>> for button only interfaces as suggested by Peter Hutterer.
>>> ---
>>> drivers/input/tablet/wacom_sys.c | 16 +++++++-
>>> drivers/input/tablet/wacom_wac.c | 87 ++++++++++++++++++++++++++++++++--------
>>> drivers/input/tablet/wacom_wac.h | 7 ++++
>>> include/uapi/linux/input.h | 1 +
>>> 4 files changed, 93 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
>>> index 7bdb5e9..efd9729 100644
>>> --- a/drivers/input/tablet/wacom_sys.c
>>> +++ b/drivers/input/tablet/wacom_sys.c
>>> @@ -1190,12 +1190,15 @@ static void wacom_wireless_work(struct work_struct *work)
>>> wacom_wac1->features.device_type = BTN_TOOL_PEN;
>>> snprintf(wacom_wac1->name, WACOM_NAME_MAX, "%s (WL) Pen",
>>> wacom_wac1->features.name);
>>> + wacom_wac1->shared->touch_max = wacom_wac1->features.touch_max;
>>> + wacom_wac1->shared->type = wacom_wac1->features.type;
>>> error = wacom_register_input(wacom1);
>>> if (error)
>>> goto fail;
>>>
>>> /* Touch interface */
>>> - if (wacom_wac1->features.touch_max) {
>>> + if (wacom_wac1->features.touch_max ||
>>> + wacom_wac1->features.type == INTUOS_HT) {
>>> wacom_wac2->features =
>>> *((struct wacom_features *)id->driver_info);
>>> wacom_wac2->features.pktlen = WACOM_PKGLEN_BBTOUCH3;
>>> @@ -1210,6 +1213,10 @@ static void wacom_wireless_work(struct work_struct *work)
>>> error = wacom_register_input(wacom2);
>>> if (error)
>>> goto fail;
>>> +
>>> + if (wacom_wac1->features.type == INTUOS_HT &&
>>> + wacom_wac1->features.touch_max)
>>> + wacom_wac->shared->touch_input = wacom_wac2->input;
>>> }
>>>
>>> error = wacom_initialize_battery(wacom);
>>> @@ -1318,7 +1325,7 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
>>> * HID descriptor. If this is the touch interface (wMaxPacketSize
>>> * of WACOM_PKGLEN_BBTOUCH3), override the table values.
>>> */
>>> - if (features->type >= INTUOS5S && features->type <= INTUOSPL) {
>>> + if (features->type >= INTUOS5S && features->type <= INTUOS_HT) {
>>> if (endpoint->wMaxPacketSize == WACOM_PKGLEN_BBTOUCH3) {
>>> features->device_type = BTN_TOOL_FINGER;
>>> features->pktlen = WACOM_PKGLEN_BBTOUCH3;
>>> @@ -1390,6 +1397,11 @@ static int wacom_probe(struct usb_interface *intf, const struct usb_device_id *i
>>> }
>>> }
>>>
>>> + if (wacom_wac->features.type == INTUOS_HT && wacom_wac->features.touch_max) {
>>> + if (wacom_wac->features.device_type == BTN_TOOL_FINGER)
>>> + wacom_wac->shared->touch_input = wacom_wac->input;
>>> + }
>>> +
>>> return 0;
>>>
>>> fail5: wacom_destroy_leds(wacom);
>>> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
>>> index 9c8eded..4cbea85 100644
>>> --- a/drivers/input/tablet/wacom_wac.c
>>> +++ b/drivers/input/tablet/wacom_wac.c
>>> @@ -1176,10 +1176,17 @@ static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)
>>> static void wacom_bpt3_button_msg(struct wacom_wac *wacom, unsigned char *data)
>>> {
>>> struct input_dev *input = wacom->input;
>>> + struct wacom_features *features = &wacom->features;
>>>
>>> - input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
>>> + if (features->type == INTUOS_HT) {
>>> + input_report_key(input, BTN_LEFT, (data[1] & 0x02) != 0);
>>> + input_report_key(input, BTN_BACK, (data[1] & 0x08) != 0);
>>> + } else {
>>> +
>>> + input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
>>> + input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
>>> + }
>>> input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0);
>>> - input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
>>> input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
>>> }
>>>
>>> @@ -1213,13 +1220,23 @@ static int wacom_bpt3_touch(struct wacom_wac *wacom)
>>>
>>> static int wacom_bpt_pen(struct wacom_wac *wacom)
>>> {
>>> + struct wacom_features *features = &wacom->features;
>>> struct input_dev *input = wacom->input;
>>> unsigned char *data = wacom->data;
>>> int prox = 0, x = 0, y = 0, p = 0, d = 0, pen = 0, btn1 = 0, btn2 = 0;
>>>
>>> - if (data[0] != 0x02)
>>> + if (data[0] != WACOM_REPORT_PENABLED && data[0] != WACOM_REPORT_USB_MODE)
>>> return 0;
>>>
>>> + if (data[0] == WACOM_REPORT_USB_MODE) {
>>> + if ((features->type == INTUOS_HT) && features->touch_max) {
>>> + input_report_switch(wacom->shared->touch_input,
>>> + SW_TOUCH, data[8] & 0x40);
>>> + input_sync(wacom->shared->touch_input);
>>> + }
>>> + return 0;
>>> + }
>>> +
>>> prox = (data[1] & 0x20) == 0x20;
>>>
>>> /*
>>> @@ -1297,13 +1314,20 @@ static int wacom_wireless_irq(struct wacom_wac *wacom, size_t len)
>>> unsigned char *data = wacom->data;
>>> int connected;
>>>
>>> - if (len != WACOM_PKGLEN_WIRELESS || data[0] != 0x80)
>>> + if (len != WACOM_PKGLEN_WIRELESS || data[0] != WACOM_REPORT_WL_MODE)
>>> return 0;
>>>
>>> connected = data[1] & 0x01;
>>> if (connected) {
>>> int pid, battery;
>>>
>>> + if ((wacom->shared->type == INTUOS_HT) &&
>>> + wacom->shared->touch_max) {
>>> + input_report_switch(wacom->shared->touch_input,
>>> + SW_TOUCH, data[5] & 0x40);
>>> + input_sync(wacom->shared->touch_input);
>>> + }
>>> +
>>> pid = get_unaligned_be16(&data[6]);
>>> battery = data[5] & 0x3f;
>>> if (wacom->pid != pid) {
>>> @@ -1391,6 +1415,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
>>> break;
>>>
>>> case BAMBOO_PT:
>>> + case INTUOS_HT:
>>> sync = wacom_bpt_irq(wacom_wac, len);
>>> break;
>>>
>>> @@ -1459,7 +1484,7 @@ void wacom_setup_device_quirks(struct wacom_features *features)
>>>
>>> /* these device have multiple inputs */
>>> if (features->type >= WIRELESS ||
>>> - (features->type >= INTUOS5S && features->type <= INTUOSPL) ||
>>> + (features->type >= INTUOS5S && features->type <= INTUOS_HT) ||
>>> (features->oVid && features->oPid))
>>> features->quirks |= WACOM_QUIRK_MULTI_INPUT;
>>>
>>> @@ -1531,7 +1556,8 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
>>> struct wacom_features *features = &wacom_wac->features;
>>> int i;
>>>
>>> - input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
>>> + input_dev->evbit[0] |= BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) |
>>> + BIT_MASK(EV_SW);
>>>
>>> __set_bit(BTN_TOUCH, input_dev->keybit);
>>> __set_bit(ABS_MISC, input_dev->absbit);
>>> @@ -1771,33 +1797,48 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
>>> __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>>> break;
>>>
>>> + case INTUOS_HT:
>>> + if (features->touch_max &&
>>> + (features->device_type == BTN_TOOL_FINGER))
>>> + __set_bit(SW_TOUCH, input_dev->swbit);
>>> + /* fall through */
>>> +
>>> case BAMBOO_PT:
>>> __clear_bit(ABS_MISC, input_dev->absbit);
>>>
>>> - __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>>> -
>>> if (features->device_type == BTN_TOOL_FINGER) {
>>> - unsigned int flags = INPUT_MT_POINTER;
>>>
>>> __set_bit(BTN_LEFT, input_dev->keybit);
>>> __set_bit(BTN_FORWARD, input_dev->keybit);
>>> __set_bit(BTN_BACK, input_dev->keybit);
>>> __set_bit(BTN_RIGHT, input_dev->keybit);
>>>
>>> - if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
>>> - input_set_abs_params(input_dev,
>>> + if (features->touch_max) {
>>> + /* touch interface */
>>> + unsigned int flags = INPUT_MT_POINTER;
>>> +
>>> + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>>> + if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
>>> + input_set_abs_params(input_dev,
>>> ABS_MT_TOUCH_MAJOR,
>>> 0, features->x_max, 0, 0);
>>> - input_set_abs_params(input_dev,
>>> + input_set_abs_params(input_dev,
>>> ABS_MT_TOUCH_MINOR,
>>> 0, features->y_max, 0, 0);
>>> + } else {
>>> + __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
>>> + __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
>>> + flags = 0;
>>> + }
>>> + input_mt_init_slots(input_dev, features->touch_max, flags);
>>> } else {
>>> - __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
>>> - __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
>>> - flags = 0;
>>> + /* buttons/keys only interface */
>>> + __clear_bit(ABS_X, input_dev->absbit);
>>> + __clear_bit(ABS_Y, input_dev->absbit);
>>> + __clear_bit(BTN_TOUCH, input_dev->keybit);
>>> }
>>> - input_mt_init_slots(input_dev, features->touch_max, flags);
>>> } else if (features->device_type == BTN_TOOL_PEN) {
>>> + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
>>> __set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
>>> __set_bit(BTN_TOOL_PEN, input_dev->keybit);
>>> __set_bit(BTN_STYLUS, input_dev->keybit);
>>> @@ -2194,6 +2235,17 @@ static const struct wacom_features wacom_features_0x300 =
>>> static const struct wacom_features wacom_features_0x301 =
>>> { "Wacom Bamboo One M", WACOM_PKGLEN_BBPEN, 21648, 13530, 1023,
>>> 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>>> +static const struct wacom_features wacom_features_0x302 =
>>> + { "Wacom Intuos PT S", WACOM_PKGLEN_BBPEN, 15200, 9500, 1023,
>>> + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
>>> + .touch_max = 16 };
>>> +static const struct wacom_features wacom_features_0x303 =
>>> + { "Wacom Intuos PT M", WACOM_PKGLEN_BBPEN, 21600, 13500, 1023,
>>> + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES,
>>> + .touch_max = 16 };
>>> +static const struct wacom_features wacom_features_0x30E =
>>> + { "Wacom Intuos S", WACOM_PKGLEN_BBPEN, 15200, 9500, 1023,
>>> + 31, INTUOS_HT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>>> static const struct wacom_features wacom_features_0x6004 =
>>> { "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
>>> 0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>>> @@ -2329,6 +2381,9 @@ const struct usb_device_id wacom_ids[] = {
>>> { USB_DEVICE_WACOM(0x10D) },
>>> { USB_DEVICE_WACOM(0x300) },
>>> { USB_DEVICE_WACOM(0x301) },
>>> + { USB_DEVICE_WACOM(0x302) },
>>> + { USB_DEVICE_DETAILED(0x303, USB_CLASS_HID, 0, 0) },
>>> + { USB_DEVICE_DETAILED(0x30E, USB_CLASS_HID, 0, 0) },
>>> { USB_DEVICE_WACOM(0x304) },
>>> { USB_DEVICE_DETAILED(0x314, USB_CLASS_HID, 0, 0) },
>>> { USB_DEVICE_DETAILED(0x315, USB_CLASS_HID, 0, 0) },
>>> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
>>> index fd23a37..ba9e335 100644
>>> --- a/drivers/input/tablet/wacom_wac.h
>>> +++ b/drivers/input/tablet/wacom_wac.h
>>> @@ -54,6 +54,8 @@
>>> #define WACOM_REPORT_TPCST 16
>>> #define WACOM_REPORT_TPC1FGE 18
>>> #define WACOM_REPORT_24HDT 1
>>> +#define WACOM_REPORT_WL_MODE 128
>>> +#define WACOM_REPORT_USB_MODE 192
>>>
>>> /* device quirks */
>>> #define WACOM_QUIRK_MULTI_INPUT 0x0001
>>> @@ -81,6 +83,7 @@ enum {
>>> INTUOSPS,
>>> INTUOSPM,
>>> INTUOSPL,
>>> + INTUOS_HT,
>>> WACOM_21UX2,
>>> WACOM_22HD,
>>> DTK,
>>> @@ -129,6 +132,10 @@ struct wacom_features {
>>> struct wacom_shared {
>>> bool stylus_in_proximity;
>>> bool touch_down;
>>> + /* for wireless device to access USB interfaces */
>>> + unsigned touch_max;
>>> + int type;
>>> + struct input_dev *touch_input;
>>> };
>>>
>>> struct wacom_wac {
>>> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
>>> index d08abf9..70e53e8 100644
>>> --- a/include/uapi/linux/input.h
>>> +++ b/include/uapi/linux/input.h
>>> @@ -855,6 +855,7 @@ struct input_keymap_entry {
>>> #define SW_FRONT_PROXIMITY 0x0b /* set = front proximity sensor active */
>>> #define SW_ROTATE_LOCK 0x0c /* set = rotate locked/disabled */
>>> #define SW_LINEIN_INSERT 0x0d /* set = inserted */
>>> +#define SW_TOUCH 0x0e /* set = touch switch turned on (touch events off) */
>>> #define SW_MAX 0x0f
>>> #define SW_CNT (SW_MAX+1)
>>>
>>> --
>>> 1.8.1.2
>>>
^ permalink raw reply
* Re: [PATCHv3 1/2] Input: twl4030-keypad - add device tree support
From: Sebastian Reichel @ 2013-11-12 3:25 UTC (permalink / raw)
To: Pavel Machek
Cc: Dmitry Torokhov, Dmitry Torokhov, linux-input, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Rob Landley, Grant Likely, devicetree, linux-doc, linux-kernel
In-Reply-To: <20131111221941.GB23331@amd.pavel.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
Hi,
On Mon, Nov 11, 2013 at 11:19:41PM +0100, Pavel Machek wrote:
> > + if (of_get_property(np, "linux,input-no-autorepeat", NULL))
> > + keypad_data->no_autorepeat = true;
>
> From 2/2:
>
> +Optional Properties specific to linux:
> +- linux,keypad-no-autorepeat: do not enable autorepeat feature.
>
> I'm confused now.
good catch! That happens when one tries to mimic other drivers :/
I just checked all DT input drivers for autorepeat keyword:
DRIVER CODE DOCUMENTATION
twl4030-keypad linux,input-no-autorepeat linux,keypad-no-autorepeat
omap4-keypad linux,input-no-autorepeat linux,keypad-no-autorepeat
samsung-keypad linux,input-no-autorepeat linux,keypad-no-autorepeat
stmpe-keypad st,no-autorepeat st,no-autorepeat
spear-keyboard autorepeat autorepeat
tca8418-keypad keypad,autorepeat --- not documented ---
gpio-matrix-keypad linux,no-autorepeat linux,no-autorepeat
gpio-keys-polled autorepeat autorepeat
gpio-keys autorepeat --- no documentation ---
Any suggestions how to continue fixing this mess? I guess first of
all the documentation of omap4-keypad, samsung-keypad and of course
the new twl4030-keypad driver should be fixed.
Next it would be nice to choose one standard property name for this
and use it for twl4030-keypad. I suggest to use "linux,input-no-autorepeat".
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Input: Add new driver for GPIO beeper
From: Alexander Shiyan @ 2013-11-12 10:07 UTC (permalink / raw)
To: linux-input-u79uwXL29TY76Z2rM5mHXA
Cc: Dmitry Torokhov, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Alexander Shiyan
This patch adds a new driver for the beeper controlled via GPIO pin.
The driver does not depend on the architecture and is positioned as
a replacement for the specific drivers that are used for this function.
Signed-off-by: Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
---
.../devicetree/bindings/input/gpio-beeper.txt | 15 +++
drivers/input/misc/Kconfig | 9 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/gpio-beeper.c | 129 +++++++++++++++++++++
4 files changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/gpio-beeper.txt
create mode 100644 drivers/input/misc/gpio-beeper.c
diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
new file mode 100644
index 0000000..8081605
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
@@ -0,0 +1,15 @@
+* GPIO beeper device tree bindings
+
+Registers a beeper connected to GPIO pin.
+
+Required properties:
+- compatible: should be "gpio-beeper".
+- gpios: From common gpio binding; gpio connection to beeper enable pin.
+
+Example:
+
+beeper: input@0 {
+ compatible = "gpio-beeper";
+ reg = <0>;
+ gpios = <&gpio3 23 0>;
+};
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5f4967d..4ffc397 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -222,6 +222,15 @@ config INPUT_GP2A
To compile this driver as a module, choose M here: the
module will be called gp2ap002a00f.
+config INPUT_GPIO_BEEPER
+ tristate "Generic GPIO Beeper support"
+ depends on OF_GPIO
+ help
+ Say Y here if you have a beeper connected to a GPIO pin.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gpio-beeper.
+
config INPUT_GPIO_TILT_POLLED
tristate "Polled GPIO tilt switch"
depends on GPIOLIB
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 0ebfb6d..cda71fc 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
+obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
diff --git a/drivers/input/misc/gpio-beeper.c b/drivers/input/misc/gpio-beeper.c
new file mode 100644
index 0000000..832c838
--- /dev/null
+++ b/drivers/input/misc/gpio-beeper.c
@@ -0,0 +1,129 @@
+/*
+ * Generic GPIO beeper driver
+ *
+ * Copyright (C) 2013 Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
+ *
+ * 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/input.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/workqueue.h>
+#include <linux/platform_device.h>
+
+#define BEEPER_MODNAME "gpio-beeper"
+
+struct gpio_beeper {
+ struct work_struct work;
+ int gpio;
+ bool active_low;
+ bool beeping;
+};
+
+static void gpio_beeper_toggle(struct gpio_beeper *beep, bool on)
+{
+ gpio_set_value_cansleep(beep->gpio, on ^ beep->active_low);
+}
+
+static void gpio_beeper_work(struct work_struct *work)
+{
+ struct gpio_beeper *beep = container_of(work, struct gpio_beeper, work);
+
+ gpio_beeper_toggle(beep, beep->beeping);
+}
+
+static int gpio_beeper_event(struct input_dev *dev, unsigned int type,
+ unsigned int code, int value)
+{
+ struct gpio_beeper *beep = input_get_drvdata(dev);
+
+ if (type != EV_SND || code != SND_BELL)
+ return -ENOTSUPP;
+
+ if (value < 0)
+ return -EINVAL;
+
+ beep->beeping = value;
+ /* Schedule work to actually turn the beeper on or off */
+ schedule_work(&beep->work);
+
+ return 0;
+}
+
+static void gpio_beeper_close(struct input_dev *input)
+{
+ struct gpio_beeper *beep = input_get_drvdata(input);
+
+ cancel_work_sync(&beep->work);
+ gpio_beeper_toggle(beep, false);
+}
+
+static int gpio_beeper_probe(struct platform_device *pdev)
+{
+ struct gpio_beeper *beep;
+ enum of_gpio_flags flags;
+ struct input_dev *input;
+ unsigned long gflags;
+ int err;
+
+ beep = devm_kzalloc(&pdev->dev, sizeof(*beep), GFP_KERNEL);
+ if (!beep)
+ return -ENOMEM;
+
+ beep->gpio = of_get_named_gpio_flags(pdev->dev.of_node, "gpios",
+ 0, &flags);
+ if (!gpio_is_valid(beep->gpio))
+ return -EINVAL;
+
+ input = devm_input_allocate_device(&pdev->dev);
+ if (!input)
+ return -ENOMEM;
+
+ INIT_WORK(&beep->work, gpio_beeper_work);
+
+ input->name = pdev->name;
+ input->phys = BEEPER_MODNAME "/input0";
+ input->id.bustype = BUS_HOST;
+ input->id.vendor = 0x0001;
+ input->id.product = 0x0001;
+ input->id.version = 0x0100;
+ input->close = gpio_beeper_close;
+ input->event = gpio_beeper_event;
+
+ input_set_capability(input, EV_SND, SND_BELL);
+
+ beep->active_low = flags & OF_GPIO_ACTIVE_LOW;
+ gflags = beep->active_low ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+
+ err = devm_gpio_request_one(&pdev->dev, beep->gpio, gflags, pdev->name);
+ if (err)
+ return err;
+
+ input_set_drvdata(input, beep);
+
+ return input_register_device(input);
+}
+
+static struct of_device_id gpio_beeper_of_match[] = {
+ { .compatible = BEEPER_MODNAME, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpio_beeper_of_match);
+
+static struct platform_driver gpio_beeper_platform_driver = {
+ .driver = {
+ .name = BEEPER_MODNAME,
+ .owner = THIS_MODULE,
+ .of_match_table = gpio_beeper_of_match,
+ },
+ .probe = gpio_beeper_probe,
+};
+module_platform_driver(gpio_beeper_platform_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>");
+MODULE_DESCRIPTION("Generic GPIO beeper driver");
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] Input: Add new driver for GPIO beeper
From: Mark Rutland @ 2013-11-12 10:15 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-input@vger.kernel.org, Dmitry Torokhov,
devicetree@vger.kernel.org, rob.herring@calxeda.com, Pawel Moll,
Stephen Warren, Ian Campbell
In-Reply-To: <1384250833-4600-1-git-send-email-shc_work@mail.ru>
On Tue, Nov 12, 2013 at 10:07:13AM +0000, Alexander Shiyan wrote:
> This patch adds a new driver for the beeper controlled via GPIO pin.
> The driver does not depend on the architecture and is positioned as
> a replacement for the specific drivers that are used for this function.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> .../devicetree/bindings/input/gpio-beeper.txt | 15 +++
> drivers/input/misc/Kconfig | 9 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/gpio-beeper.c | 129 +++++++++++++++++++++
> 4 files changed, 154 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/gpio-beeper.txt
> create mode 100644 drivers/input/misc/gpio-beeper.c
>
> diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
> new file mode 100644
> index 0000000..8081605
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
> @@ -0,0 +1,15 @@
> +* GPIO beeper device tree bindings
> +
> +Registers a beeper connected to GPIO pin.
> +
> +Required properties:
> +- compatible: should be "gpio-beeper".
> +- gpios: From common gpio binding; gpio connection to beeper enable pin.
> +
> +Example:
> +
> +beeper: input@0 {
> + compatible = "gpio-beeper";
> + reg = <0>;
> + gpios = <&gpio3 23 0>;
> +};
What are the reg / unit-address for?
Also, a beeper doesn't strike me as an input device, regardless of how
the kernel sees it internally. I'd expect the node to just be named
"beeper" or something along those lines.
Otherwise I believe this looks sane.
Mark.
^ permalink raw reply
* Re: [PATCH] Input: Add new driver for GPIO beeper
From: Alexander Shiyan @ 2013-11-12 10:47 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-input@vger.kernel.org, Dmitry Torokhov,
devicetree@vger.kernel.org, rob.herring@calxeda.com, Pawel Moll,
Stephen Warren, Ian Campbell
In-Reply-To: <20131112101544.GD2976@e106331-lin.cambridge.arm.com>
Hello.
> On Tue, Nov 12, 2013 at 10:07:13AM +0000, Alexander Shiyan wrote:
> > This patch adds a new driver for the beeper controlled via GPIO pin.
> > The driver does not depend on the architecture and is positioned as
> > a replacement for the specific drivers that are used for this function.
> >
> > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
...
> > diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
...
> > +Example:
> > +
> > +beeper: input@0 {
> > + compatible = "gpio-beeper";
> > + reg = <0>;
> > + gpios = <&gpio3 23 0>;
> > +};
>
> What are the reg / unit-address for?
Just an example from "simple-bus" container.
---
^ permalink raw reply
* Re: [PATCH] Input: Add new driver for GPIO beeper
From: Mark Rutland @ 2013-11-12 10:59 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-input@vger.kernel.org, Dmitry Torokhov,
devicetree@vger.kernel.org, rob.herring@calxeda.com, Pawel Moll,
Stephen Warren, Ian Campbell
In-Reply-To: <1384253277.731839001@f27.i.mail.ru>
On Tue, Nov 12, 2013 at 10:47:57AM +0000, Alexander Shiyan wrote:
> Hello.
>
> > On Tue, Nov 12, 2013 at 10:07:13AM +0000, Alexander Shiyan wrote:
> > > This patch adds a new driver for the beeper controlled via GPIO pin.
> > > The driver does not depend on the architecture and is positioned as
> > > a replacement for the specific drivers that are used for this function.
> > >
> > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ...
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
> ...
> > > +Example:
> > > +
> > > +beeper: input@0 {
> > > + compatible = "gpio-beeper";
> > > + reg = <0>;
> > > + gpios = <&gpio3 23 0>;
> > > +};
> >
> > What are the reg / unit-address for?
>
> Just an example from "simple-bus" container.
If they have no meaning, they should go. They're unnecessary and make
things more confusing.
I'd expect the example to be:
beeper: beeper {
compatible = "gpio-beeper";
gpios - <&gpio3 23 0>;
};
And if we have multiple beepers, something like:
beeper0: beeper0 { ... };
beeper1: beeper1 { ... };
Thanks,
Mark.
^ permalink raw reply
* [PATCH RESEND 3/3] input: gpio_keys{_polled}: Replace enable/disable callbacks with regulator API
From: Alexander Shiyan @ 2013-11-12 10:38 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Alexander Shiyan
In-Reply-To: <1384252705-18553-1-git-send-email-shc_work@mail.ru>
Typical use to enable/disable is a power switch, so replace these
callbacks to the regulator API. This will allow using devices,
which depends on the regulator, from devicetree.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
.../devicetree/bindings/input/gpio-keys-polled.txt | 1 +
drivers/input/keyboard/gpio_keys.c | 16 ++++++++++------
drivers/input/keyboard/gpio_keys_polled.c | 16 ++++++++++------
include/linux/gpio_keys.h | 2 --
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt
index 313abef..a210963 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt
@@ -7,6 +7,7 @@ Required properties:
Optional properties:
- autorepeat: Boolean, Enable auto repeat feature of Linux input
subsystem.
+ - vcc-supply: The regulator to drive the GPIOs.
Each button (key) is represented as a sub-node of "gpio-keys-polled":
Subnode properties:
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 50c2746..659c426 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -30,6 +30,7 @@
#include <linux/of_platform.h>
#include <linux/of_gpio.h>
#include <linux/spinlock.h>
+#include <linux/regulator/consumer.h>
struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -48,6 +49,7 @@ struct gpio_keys_drvdata {
struct input_dev *input;
struct mutex disable_lock;
struct gpio_button_data data[0];
+ struct regulator *regulator;
};
/*
@@ -528,11 +530,10 @@ static void gpio_keys_report_state(struct gpio_keys_drvdata *ddata)
static int gpio_keys_open(struct input_dev *input)
{
struct gpio_keys_drvdata *ddata = input_get_drvdata(input);
- const struct gpio_keys_platform_data *pdata = ddata->pdata;
int error;
- if (pdata->enable) {
- error = pdata->enable(input->dev.parent);
+ if (!IS_ERR(ddata->regulator)) {
+ error = regulator_enable(ddata->regulator);
if (error)
return error;
}
@@ -546,10 +547,9 @@ static int gpio_keys_open(struct input_dev *input)
static void gpio_keys_close(struct input_dev *input)
{
struct gpio_keys_drvdata *ddata = input_get_drvdata(input);
- const struct gpio_keys_platform_data *pdata = ddata->pdata;
- if (pdata->disable)
- pdata->disable(input->dev.parent);
+ if (!IS_ERR(ddata->regulator))
+ regulator_disable(ddata->regulator);
}
/*
@@ -683,6 +683,10 @@ static int gpio_keys_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ ddata->regulator = devm_regulator_get(&pdev->dev, "vcc");
+ if (PTR_ERR(ddata->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
ddata->pdata = pdata;
ddata->input = input;
mutex_init(&ddata->disable_lock);
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 0dce49d..955a59d 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -28,6 +28,7 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
#define DRV_NAME "gpio-keys-polled"
@@ -43,6 +44,7 @@ struct gpio_keys_polled_dev {
struct device *dev;
const struct gpio_keys_platform_data *pdata;
struct gpio_keys_button_data data[0];
+ struct regulator *regulator;
};
static void gpio_keys_polled_check_state(struct input_dev *input,
@@ -88,19 +90,17 @@ static void gpio_keys_polled_poll(struct input_polled_dev *dev)
static void gpio_keys_polled_open(struct input_polled_dev *dev)
{
struct gpio_keys_polled_dev *bdev = dev->private;
- const struct gpio_keys_platform_data *pdata = bdev->pdata;
- if (pdata->enable)
- pdata->enable(bdev->dev);
+ if (!IS_ERR(bdev->regulator))
+ WARN_ON(regulator_enable(bdev->regulator));
}
static void gpio_keys_polled_close(struct input_polled_dev *dev)
{
struct gpio_keys_polled_dev *bdev = dev->private;
- const struct gpio_keys_platform_data *pdata = bdev->pdata;
- if (pdata->disable)
- pdata->disable(bdev->dev);
+ if (!IS_ERR(bdev->regulator))
+ regulator_disable(bdev->regulator);
}
#ifdef CONFIG_OF
@@ -227,6 +227,10 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ bdev->regulator = devm_regulator_get(&pdev->dev, "vcc");
+ if (PTR_ERR(bdev->regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
poll_dev = input_allocate_polled_device();
if (!poll_dev) {
dev_err(dev, "no memory for polled device\n");
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index a7e977f..05d3bf8 100644
--- a/include/linux/gpio_keys.h
+++ b/include/linux/gpio_keys.h
@@ -23,8 +23,6 @@ struct gpio_keys_platform_data {
unsigned int poll_interval; /* polling interval in msecs -
for polling driver only */
unsigned int rep:1; /* enable input subsystem auto repeat */
- int (*enable)(struct device *dev);
- void (*disable)(struct device *dev);
const char *name; /* input device name */
};
--
1.8.1.5
^ permalink raw reply related
* [PATCH RESEND 2/3] input: gpio_keys: Convert to devm-* API
From: Alexander Shiyan @ 2013-11-12 10:38 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Alexander Shiyan
In-Reply-To: <1384252705-18553-1-git-send-email-shc_work@mail.ru>
Replace existing resource handling in the driver with managed
device resource, this ensures more consistent error values and
simplifies error paths.
kzalloc -> devm_kzalloc
gpio_request_one -> devm_gpio_request_one
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/input/keyboard/gpio_keys.c | 96 +++++++++++---------------------------
1 file changed, 28 insertions(+), 68 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 2db1324..50c2746 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -433,7 +433,7 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
struct device *dev = &pdev->dev;
irq_handler_t isr;
unsigned long irqflags;
- int irq, error;
+ int error;
bdata->input = input;
bdata->button = button;
@@ -441,7 +441,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
if (gpio_is_valid(button->gpio)) {
- error = gpio_request_one(button->gpio, GPIOF_IN, desc);
+ error = devm_gpio_request_one(&pdev->dev, button->gpio,
+ GPIOF_IN, desc);
if (error < 0) {
dev_err(dev, "Failed to request GPIO %d, error %d\n",
button->gpio, error);
@@ -457,15 +458,13 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
button->debounce_interval;
}
- irq = gpio_to_irq(button->gpio);
- if (irq < 0) {
- error = irq;
+ bdata->irq = gpio_to_irq(button->gpio);
+ if (bdata->irq < 0) {
dev_err(dev,
"Unable to get irq number for GPIO %d, error %d\n",
- button->gpio, error);
- goto fail;
+ button->gpio, bdata->irq);
+ return bdata->irq;
}
- bdata->irq = irq;
INIT_WORK(&bdata->work, gpio_keys_gpio_work_func);
setup_timer(&bdata->timer,
@@ -507,16 +506,10 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
if (error < 0) {
dev_err(dev, "Unable to claim irq %d; error %d\n",
bdata->irq, error);
- goto fail;
+ return error;
}
return 0;
-
-fail:
- if (gpio_is_valid(button->gpio))
- gpio_free(button->gpio);
-
- return error;
}
static void gpio_keys_report_state(struct gpio_keys_drvdata *ddata)
@@ -573,28 +566,20 @@ gpio_keys_get_devtree_pdata(struct device *dev)
struct device_node *node, *pp;
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
- int error;
- int nbuttons;
- int i;
+ int i, nbuttons;
node = dev->of_node;
- if (!node) {
- error = -ENODEV;
- goto err_out;
- }
+ if (!node)
+ return ERR_PTR(-ENODEV);
nbuttons = of_get_child_count(node);
- if (nbuttons == 0) {
- error = -ENODEV;
- goto err_out;
- }
+ if (nbuttons == 0)
+ return ERR_PTR(-ENODEV);
- pdata = kzalloc(sizeof(*pdata) + nbuttons * (sizeof *button),
- GFP_KERNEL);
- if (!pdata) {
- error = -ENOMEM;
- goto err_out;
- }
+ pdata = devm_kzalloc(dev, sizeof(*pdata) + nbuttons * (sizeof *button),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
pdata->nbuttons = nbuttons;
@@ -614,12 +599,11 @@ gpio_keys_get_devtree_pdata(struct device *dev)
gpio = of_get_gpio_flags(pp, 0, &flags);
if (gpio < 0) {
- error = gpio;
- if (error != -EPROBE_DEFER)
+ if (gpio != -EPROBE_DEFER)
dev_err(dev,
"Failed to get gpio flags, error: %d\n",
- error);
- goto err_free_pdata;
+ gpio);
+ return ERR_PTR(gpio);
}
button = &pdata->buttons[i++];
@@ -630,8 +614,7 @@ gpio_keys_get_devtree_pdata(struct device *dev)
if (of_property_read_u32(pp, "linux,code", &button->code)) {
dev_err(dev, "Button without keycode: 0x%x\n",
button->gpio);
- error = -EINVAL;
- goto err_free_pdata;
+ return ERR_PTR(-EINVAL);
}
button->desc = of_get_property(pp, "label", NULL);
@@ -646,17 +629,10 @@ gpio_keys_get_devtree_pdata(struct device *dev)
button->debounce_interval = 5;
}
- if (pdata->nbuttons == 0) {
- error = -EINVAL;
- goto err_free_pdata;
- }
+ if (!pdata->nbuttons)
+ return ERR_PTR(-EINVAL);
return pdata;
-
-err_free_pdata:
- kfree(pdata);
-err_out:
- return ERR_PTR(error);
}
static struct of_device_id gpio_keys_of_match[] = {
@@ -681,8 +657,6 @@ static void gpio_remove_key(struct gpio_button_data *bdata)
if (bdata->timer_debounce)
del_timer_sync(&bdata->timer);
cancel_work_sync(&bdata->work);
- if (gpio_is_valid(bdata->button->gpio))
- gpio_free(bdata->button->gpio);
}
static int gpio_keys_probe(struct platform_device *pdev)
@@ -700,14 +674,13 @@ static int gpio_keys_probe(struct platform_device *pdev)
return PTR_ERR(pdata);
}
- ddata = kzalloc(sizeof(struct gpio_keys_drvdata) +
- pdata->nbuttons * sizeof(struct gpio_button_data),
- GFP_KERNEL);
- input = input_allocate_device();
+ ddata = devm_kzalloc(&pdev->dev, sizeof(struct gpio_keys_drvdata) +
+ pdata->nbuttons * sizeof(struct gpio_button_data),
+ GFP_KERNEL);
+ input = devm_input_allocate_device(&pdev->dev);
if (!ddata || !input) {
dev_err(dev, "failed to allocate state\n");
- error = -ENOMEM;
- goto fail1;
+ return -ENOMEM;
}
ddata->pdata = pdata;
@@ -768,13 +741,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
while (--i >= 0)
gpio_remove_key(&ddata->data[i]);
- fail1:
- input_free_device(input);
- kfree(ddata);
- /* If we have no platform data, we allocated pdata dynamically. */
- if (!dev_get_platdata(&pdev->dev))
- kfree(pdata);
-
return error;
}
@@ -793,12 +759,6 @@ static int gpio_keys_remove(struct platform_device *pdev)
input_unregister_device(input);
- /* If we have no platform data, we allocated pdata dynamically. */
- if (!dev_get_platdata(&pdev->dev))
- kfree(ddata->pdata);
-
- kfree(ddata);
-
return 0;
}
--
1.8.1.5
^ permalink raw reply related
* [PATCH RESEND 1/3] input: gpio_keys_polled: Convert to devm-* API
From: Alexander Shiyan @ 2013-11-12 10:38 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Alexander Shiyan
Replace existing resource handling in the driver with managed
device resource, this ensures more consistent error values and
simplifies error paths.
kzalloc -> devm_kzalloc
gpio_request_one -> devm_gpio_request_one
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/input/keyboard/gpio_keys_polled.c | 87 ++++++++-----------------------
1 file changed, 23 insertions(+), 64 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 4e42819..0dce49d 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -109,9 +109,7 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
struct device_node *node, *pp;
struct gpio_keys_platform_data *pdata;
struct gpio_keys_button *button;
- int error;
- int nbuttons;
- int i;
+ int i, nbuttons;
node = dev->of_node;
if (!node)
@@ -121,12 +119,10 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
if (nbuttons == 0)
return NULL;
- pdata = kzalloc(sizeof(*pdata) + nbuttons * (sizeof *button),
- GFP_KERNEL);
- if (!pdata) {
- error = -ENOMEM;
- goto err_out;
- }
+ pdata = devm_kzalloc(dev, sizeof(*pdata) + nbuttons * (sizeof *button),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
pdata->buttons = (struct gpio_keys_button *)(pdata + 1);
pdata->nbuttons = nbuttons;
@@ -147,12 +143,11 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
gpio = of_get_gpio_flags(pp, 0, &flags);
if (gpio < 0) {
- error = gpio;
- if (error != -EPROBE_DEFER)
+ if (gpio != -EPROBE_DEFER)
dev_err(dev,
"Failed to get gpio flags, error: %d\n",
- error);
- goto err_free_pdata;
+ gpio);
+ return ERR_PTR(gpio);
}
button = &pdata->buttons[i++];
@@ -163,8 +158,7 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
if (of_property_read_u32(pp, "linux,code", &button->code)) {
dev_err(dev, "Button without keycode: 0x%x\n",
button->gpio);
- error = -EINVAL;
- goto err_free_pdata;
+ return ERR_PTR(-EINVAL);
}
button->desc = of_get_property(pp, "label", NULL);
@@ -179,17 +173,10 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
button->debounce_interval = 5;
}
- if (pdata->nbuttons == 0) {
- error = -EINVAL;
- goto err_free_pdata;
- }
+ if (!pdata->nbuttons)
+ return ERR_PTR(-EINVAL);
return pdata;
-
-err_free_pdata:
- kfree(pdata);
-err_out:
- return ERR_PTR(error);
}
static struct of_device_id gpio_keys_polled_of_match[] = {
@@ -229,24 +216,21 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
if (!pdata->poll_interval) {
dev_err(dev, "missing poll_interval value\n");
- error = -EINVAL;
- goto err_free_pdata;
+ return -EINVAL;
}
- bdev = kzalloc(sizeof(struct gpio_keys_polled_dev) +
- pdata->nbuttons * sizeof(struct gpio_keys_button_data),
- GFP_KERNEL);
+ bdev = devm_kzalloc(&pdev->dev, sizeof(struct gpio_keys_polled_dev) +
+ pdata->nbuttons * sizeof(struct gpio_keys_button_data),
+ GFP_KERNEL);
if (!bdev) {
dev_err(dev, "no memory for private data\n");
- error = -ENOMEM;
- goto err_free_pdata;
+ return -ENOMEM;
}
poll_dev = input_allocate_polled_device();
if (!poll_dev) {
dev_err(dev, "no memory for polled device\n");
- error = -ENOMEM;
- goto err_free_bdev;
+ return -ENOMEM;
}
poll_dev->private = bdev;
@@ -279,15 +263,15 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
if (button->wakeup) {
dev_err(dev, DRV_NAME " does not support wakeup\n");
error = -EINVAL;
- goto err_free_gpio;
+ goto err_out;
}
- error = gpio_request_one(gpio, GPIOF_IN,
- button->desc ?: DRV_NAME);
+ error = devm_gpio_request_one(&pdev->dev, gpio, GPIOF_IN,
+ button->desc ? : DRV_NAME);
if (error) {
dev_err(dev, "unable to claim gpio %u, err=%d\n",
gpio, error);
- goto err_free_gpio;
+ goto err_out;
}
bdata->can_sleep = gpio_cansleep(gpio);
@@ -307,7 +291,7 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
if (error) {
dev_err(dev, "unable to register polled device, err=%d\n",
error);
- goto err_free_gpio;
+ goto err_out;
}
/* report initial state of the buttons */
@@ -317,45 +301,20 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
return 0;
-err_free_gpio:
- while (--i >= 0)
- gpio_free(pdata->buttons[i].gpio);
-
+err_out:
input_free_polled_device(poll_dev);
-err_free_bdev:
- kfree(bdev);
-
-err_free_pdata:
- /* If we have no platform_data, we allocated pdata dynamically. */
- if (!dev_get_platdata(&pdev->dev))
- kfree(pdata);
-
return error;
}
static int gpio_keys_polled_remove(struct platform_device *pdev)
{
struct gpio_keys_polled_dev *bdev = platform_get_drvdata(pdev);
- const struct gpio_keys_platform_data *pdata = bdev->pdata;
- int i;
input_unregister_polled_device(bdev->poll_dev);
- for (i = 0; i < pdata->nbuttons; i++)
- gpio_free(pdata->buttons[i].gpio);
-
input_free_polled_device(bdev->poll_dev);
- /*
- * If we had no platform_data, we allocated pdata dynamically and
- * must free it here.
- */
- if (!dev_get_platdata(&pdev->dev))
- kfree(pdata);
-
- kfree(bdev);
-
return 0;
}
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH v3] add sur40 driver for Samsung SUR40 (aka MS Surface 2.0/Pixelsense)
From: Florian Echtler @ 2013-11-12 13:35 UTC (permalink / raw)
To: Henrik Rydberg, Dmitry Torokhov
Cc: linux-input, benjamin.tissoires, dh.herrmann
In-Reply-To: <5280B0FE.5080203@euromail.se>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On 11.11.2013 11:27, Henrik Rydberg wrote:
> >> Also, does the patch below mess up or device or it still works?
>> I'll test this tomorrow (no access to SUR40 today). If everything works,
>> should I resubmit my patch with yours included or just tell you that
>> it's fine?
> No need to resubmit, a confirmation will do nicely. Thanks!
> Henrik
I've tested Dmitry's additional patch, confirmed to work. Just for the
record:
Tested-by: Florian Echtler <floe@butterbrot.org>
BR, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 4/5 v3] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2013-11-12 15:31 UTC (permalink / raw)
To: devicetree, Dmitry Torokhov, linux-input
Cc: linux-kernel, linux-arm-kernel, Mark Rutland, Linus Walleij
Implement device tree probing for the tc3589x keypad driver.
This is modeled on the STMPE keypad driver and tested on the
Ux500 TVK1281618 UIB.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Use two local u32 variables to avoid weirdness in u8 casting
of the resulting values to the pointers.
ChangeLog v1->v2:
- Fix rows/columns binding to read two u32's insead of two
u8 /bits/ as noted by Mark Rutland.
---
drivers/input/keyboard/tc3589x-keypad.c | 66 ++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/tc3589x-keypad.c b/drivers/input/keyboard/tc3589x-keypad.c
index 208de7cbb7fa..7f36e7addb86 100644
--- a/drivers/input/keyboard/tc3589x-keypad.c
+++ b/drivers/input/keyboard/tc3589x-keypad.c
@@ -297,6 +297,65 @@ static void tc3589x_keypad_close(struct input_dev *input)
tc3589x_keypad_disable(keypad);
}
+#ifdef CONFIG_OF
+static const struct tc3589x_keypad_platform_data *
+tc3589x_keypad_of_probe(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct tc3589x_keypad_platform_data *plat;
+ u32 cols, rows;
+ u32 debounce_ms;
+ int proplen;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL);
+ if (!plat)
+ return ERR_PTR(-ENOMEM);
+
+ of_property_read_u32(np, "keypad,num-columns", &cols);
+ of_property_read_u32(np, "keypad,num-rows", &rows);
+ plat->kcol = (u8) cols;
+ plat->krow = (u8) rows;
+ if (!plat->krow || !plat->kcol ||
+ plat->krow > TC_KPD_ROWS || plat->kcol > TC_KPD_COLUMNS) {
+ dev_err(dev,
+ "keypad columns/rows not properly specified (%ux%u)\n",
+ plat->kcol, plat->krow);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (!of_get_property(np, "linux,keymap", &proplen)) {
+ dev_err(dev, "property linux,keymap not found\n");
+ return ERR_PTR(-ENOENT);
+ }
+
+ plat->no_autorepeat = of_property_read_bool(np, "linux,no-autorepeat");
+ plat->enable_wakeup = of_property_read_bool(np, "linux,wakeup");
+
+ /* The custom delay format is ms/16 */
+ of_property_read_u32(np, "debounce-delay-ms", &debounce_ms);
+ if (debounce_ms)
+ plat->debounce_period = debounce_ms * 16;
+ else
+ plat->debounce_period = TC_KPD_DEBOUNCE_PERIOD;
+
+ plat->settle_time = TC_KPD_SETTLE_TIME;
+ /* FIXME: should be property of the IRQ resource? */
+ plat->irqtype = IRQF_TRIGGER_FALLING;
+
+ return plat;
+}
+#else
+static inline const struct tc3589x_keypad_platform_data *
+tc3589x_keypad_of_probe(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
+
static int tc3589x_keypad_probe(struct platform_device *pdev)
{
struct tc3589x *tc3589x = dev_get_drvdata(pdev->dev.parent);
@@ -307,8 +366,11 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
plat = tc3589x->pdata->keypad;
if (!plat) {
- dev_err(&pdev->dev, "invalid keypad platform data\n");
- return -EINVAL;
+ plat = tc3589x_keypad_of_probe(&pdev->dev);
+ if (IS_ERR(plat)) {
+ dev_err(&pdev->dev, "invalid keypad platform data\n");
+ return PTR_ERR(plat);
+ }
}
irq = platform_get_irq(pdev, 0);
--
1.8.3.1
^ permalink raw reply related
* [PATCH] input: ti_am33x_tsc: make the documentation for the ti,wire-config parameter clear
From: Sebastian Andrzej Siewior @ 2013-11-12 16:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Felipe Balbi, Grant Likely, Rob Herring, devicetree,
Sebastian Andrzej Siewior
The document says "first four bits" and means the upper nibble. Most
people would probably agree that the first four bits are bits 0…3 and
that is the lower nibble.
This patch updates the documentation so it is clear what is meant.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b..0fcd430 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -17,8 +17,8 @@
remaining 4 can be used by the ADC.
ti,wire-config: Different boards could have a different order for
connecting wires on touchscreen. We need to provide an
- 8 bit number where in the 1st four bits represent the
- analog lines and the next 4 bits represent positive/
+ 8 bit number where the upper nibble represent the
+ analog lines and the lower nibble represent positive/
negative terminal on that input line. Notations to
represent the input lines and terminals resoectively
is as follows:
--
1.8.4.2
--
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 related
* Re: [PATCH] input: ti_am33x_tsc: make the documentation for the ti,wire-config parameter clear
From: Kumar Gala @ 2013-11-12 16:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Dmitry Torokhov, linux-input, Felipe Balbi, Grant Likely,
Rob Herring, devicetree
In-Reply-To: <1384273323-15329-1-git-send-email-bigeasy@linutronix.de>
On Nov 12, 2013, at 10:22 AM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> The document says "first four bits" and means the upper nibble. Most
> people would probably agree that the first four bits are bits 0…3 and
> that is the lower nibble.
> This patch updates the documentation so it is clear what is meant.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> index 491c97b..0fcd430 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> @@ -17,8 +17,8 @@
> remaining 4 can be used by the ADC.
> ti,wire-config: Different boards could have a different order for
> connecting wires on touchscreen. We need to provide an
> - 8 bit number where in the 1st four bits represent the
> - analog lines and the next 4 bits represent positive/
> + 8 bit number where the upper nibble represent the
> + analog lines and the lower nibble represent positive/
> negative terminal on that input line. Notations to
> represent the input lines and terminals resoectively
> is as follows:
Is it possible to give an example because that might help with the confusion.
- k
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] input: ti_am33x_tsc: make the documentation for the ti,wire-config parameter clear
From: Andrey Moiseev @ 2013-11-12 16:35 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1384273323-15329-1-git-send-email-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Maybe "most/least significant" is more clear. Everyone got used to
little-endian, anyway.
On Tue, Nov 12, 2013 at 8:22 PM, Sebastian Andrzej Siewior
<bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> wrote:
> The document says "first four bits" and means the upper nibble. Most
> people would probably agree that the first four bits are bits 0…3 and
> that is the lower nibble.
> This patch updates the documentation so it is clear what is meant.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> index 491c97b..0fcd430 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
> @@ -17,8 +17,8 @@
> remaining 4 can be used by the ADC.
> ti,wire-config: Different boards could have a different order for
> connecting wires on touchscreen. We need to provide an
> - 8 bit number where in the 1st four bits represent the
> - analog lines and the next 4 bits represent positive/
> + 8 bit number where the upper nibble represent the
> + analog lines and the lower nibble represent positive/
> negative terminal on that input line. Notations to
> represent the input lines and terminals resoectively
> is as follows:
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Fwd: [PATCH v2 2/2] Input: wacom - add support for three new Intuos devices
From: Ping Cheng @ 2013-11-12 17:29 UTC (permalink / raw)
To: linux-input
In-Reply-To: <CAF8JNhJb8oT9ZKD+QL1sYpJWGC9=JMMogxnK5cToWD9KK9MVdg@mail.gmail.com>
On Monday, November 11, 2013, Chris Bagwell wrote:
>
> On Fri, Nov 8, 2013 at 1:13 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> > On Thu, Nov 7, 2013 at 6:25 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> >> On Thu, Oct 10, 2013 at 4:17 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> >>> This series of models added a hardware switch to turn touch
> >>> data on/off. To report the state of the switch, SW_TOUCH
> >>> is added in include/uapi/linux/input.h.
> >>
> >> So I guess the big point is this patch can't go in until a SW_TOUCH
> >> goes in first.
> >>
> >> Since the 1/2 or this 2/2 series has already gone in, would you mind
> >> breaking this
> >> remaining patch up into the basic support for new Intuos (without the
> >> SW_TOUCH) and
> >> then a separate patch to add SW_TOUCH support on top of that? Then
> >> the basic support can go in ASAP.
> >
> > Chris, thank you for pushing the process forward.
> >
> > SW_TOUCH is truly part of the basic support for the new series. The
> > main new feature of this series is touch switch. If we do not report
> > its status in the same patch, it means we are not reporting a complete
> > set of data.
> >
> >> I only have comments on this patch related to the SW_TOUCH part... things like:
> >>
> >> * should the SW_TOUCH be reported against the wireless interface or
> >> the touch interface... userland apps may have an opinion on which is
> >> best.
> >
> > We can not report SW_TOUCH status from touch interface since once
> > touch is turned off (by end users), no events can go on touch
> > interface. Plus, we do not know when a user may switch touch on.
> > That's why SW_TOUCH are regularly updated and reported through
> > wireless interface for wireless connection.
>
> I think I made wrong assumption of HW. Does HW stop sending touch
> events when switch is toggled or is switch an indication to ignore
> touch events in either driver or userland?
Yes, tablet stops sending touch events when user turns touch off by
the hardware. It's a hardware switch, as stated in commit comments,
which is controlled by end users. Drivers can not do much about it
except reporting its status.
> I was thinking it was for later case. When userland has to ignore, it
> is not easy to know switch value on /dev/input/foo really means what
> to do related to events on /dev/input/bar. So thats were my thoughts
> were about moving it to input that needs to be disabled. In former
> case, it just status so not so important to decide which input to
> report over.
It is the former case.
> >> * the part with updating SW_TOUCH from unrelated interfaces could use
> >
> > It is not unrelated interface. It is how it works.
> >
> >> a review by someone like Dmitry for possible issues.
>
> I meant any issues with parsing data in context of /dev/input/foo but
> doing an input_sync(/dev/input/bar) in that same context. Probably no
> issue but I don't know kernel internals to be sure.
Anyway, I'll split the patch for you. Thank you for reviewing it.
Ping
> >> * It would be better if you didn't add that EV_SW for HW that will
> >> not report the SW_TOUCH.
> >
> > I can consider that in the next version.
> >
> >> If you break the patch into 2, you can add my line for the basic
> >
> > I'd like to know your opinion about my comments before updating the
> > patch. IMO, using two patches to process one set of raw data
> > complicates the support.
>
> Assuming SW_TOUCH for this device is only for status reporting, I
> don't have much opinion. If it because a request to disable touch
> events in userland then I think it should move to device its related
> to.
>
> Chris
>
> >
> > Ping
> >
> >> support without SW_TOUCH:
> >>
> >> Reviewed-by: Chris Bagwell <chris@cnpbagwell.com>
> >>
> >> Chris
> >>
> >>>
> >>> The driver is also updated to process wireless devices that do
> >>> not support touch interface.
> >>>
> >>> Tested-by: Jason Gerecke <killertofu@gmail.com>
> >>> Signed-off-by: Ping Cheng <pingc@wacom.com>
> >>> ---
> >>> v2: Change SW_TOUCH_ENABLED to SW_TOUCH and clear BTN_TOUCH bit
> >>> for button only interfaces as suggested by Peter Hutterer.
> >>> ---
> >>> drivers/input/tablet/wacom_sys.c | 16 +++++++-
> >>> drivers/input/tablet/wacom_wac.c | 87 ++++++++++++++++++++++++++++++++--------
> >>> drivers/input/tablet/wacom_wac.h | 7 ++++
> >>> include/uapi/linux/input.h | 1 +
> >>> 4 files changed, 93 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
> >>> index 7bdb5e9..efd9729 100644
> >>> --- a/drivers/input/tablet/wacom_sys.c
> >>> +++ b/drivers/input/tablet/wacom_sys.c
> >>> @@ -1190,12 +1190,15 @@ static void wacom_wireless_work(struct work_struct *work)
> >>> wacom_wac1->features.device_type = BTN_TOOL_PEN;
> >>> snprintf(wacom_wac1->name, WACOM_NAME_MAX, "%s (WL) Pen",
> >>> wacom_wac1->features.name);
> >>> + wacom_wac1->shared->touch_max = wacom_wac1->features.touch_max;
> >>> + wacom_wac1->shared->type = wacom_wac1->features.type;
> >>> error = wacom_register_input(wacom1);
> >>> if (error)
> >>> goto fail;
> >>>
> >>> /* Touch interface */
> >>> - if (wacom_wac1->features.touch_max) {
> >>> + if (wacom_wac1->features.touch_max ||
> >>> + wacom_wac1->features.type == INTUOS_HT) {
> >>> wacom_wac2->features =
> >>> *((struct wacom_features *)id->driver_info);
> >>> wacom_wac2->features.pktlen = WACOM_PKGLEN_BBTOUCH3;
> >>> @@ -1210,6 +1213,10 @@ static void wacom_wireless_work(struct work_struct *work)
> >>> error = wacom_register_input(wacom2);
> >>> if (error)
> >>> goto fail;
> >>> +
> >>> + if (wacom_wac1->features.type == INTUOS_HT &&
> >>> + wacom_wac1->features.touch_max)
> >>> + wacom_wac->shared->touch_input = wacom_wac2->input;
> >>> }
> >>>
> >>> error = wacom_initialize_battery(wacom);
> >>> @@ -1318,7 +1325,7 @@ static int wac
^ permalink raw reply
* [PATCH v2] input: ti_am33x_tsc: make the documentation for the ti,wire-config parameter clear
From: Sebastian Andrzej Siewior @ 2013-11-12 17:40 UTC (permalink / raw)
To: Kumar Gala
Cc: Dmitry Torokhov, linux-input, Felipe Balbi, Grant Likely,
Rob Herring, devicetree, o2g.org.ru
In-Reply-To: <5C68A2CC-A8C8-4B56-A414-B9EBE438F767@codeaurora.org>
The document says "first four bits" and means the upper nibble. Most
people would probably agree that the first four bits are bits 0…3 and
that is the lower nibble.
This patch updates the documentation so it is clear what is meant.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
v1…v2:
- use most/least significant instead of upper/ lower nibble
- add an example.
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b..b25a2fe 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -17,13 +17,16 @@
remaining 4 can be used by the ADC.
ti,wire-config: Different boards could have a different order for
connecting wires on touchscreen. We need to provide an
- 8 bit number where in the 1st four bits represent the
- analog lines and the next 4 bits represent positive/
- negative terminal on that input line. Notations to
- represent the input lines and terminals resoectively
- is as follows:
+ 8 bit number where the most significant nibble represent
+ the analog lines and the least significant nibble
+ represent positive/ negative terminal on that input
+ line. Notations to represent the input lines and
+ terminals resoectively is as follows:
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
XP = 0, XN = 1, YP = 2, YN = 3.
+
+ Example: ti,wire-config = <0x71>;
+ => line AIN7, configuration XN
- child "adc"
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
--
1.8.4.2
--
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 related
* Re: [PATCH v2] input: ti_am33x_tsc: make the documentation for the ti,wire-config parameter clear
From: Kumar Gala @ 2013-11-12 18:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Dmitry Torokhov, linux-input, Felipe Balbi, Grant Likely,
Rob Herring, devicetree, o2g.org.ru
In-Reply-To: <20131112174001.GA21881@linutronix.de>
On Nov 12, 2013, at 11:40 AM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> The document says "first four bits" and means the upper nibble. Most
> people would probably agree that the first four bits are bits 0…3 and
> that is the lower nibble.
> This patch updates the documentation so it is clear what is meant.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> v1…v2:
> - use most/least significant instead of upper/ lower nibble
> - add an example.
>
> .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
Thanks
Acked-by: Kumar Gala <galak@codeaurora.org>
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Input: Add new driver for GPIO beeper
From: Stephen Warren @ 2013-11-12 19:23 UTC (permalink / raw)
To: Mark Rutland, Alexander Shiyan
Cc: linux-input@vger.kernel.org, Dmitry Torokhov,
devicetree@vger.kernel.org, rob.herring@calxeda.com, Pawel Moll,
Ian Campbell
In-Reply-To: <20131112105930.GE2976@e106331-lin.cambridge.arm.com>
On 11/12/2013 03:59 AM, Mark Rutland wrote:
> On Tue, Nov 12, 2013 at 10:47:57AM +0000, Alexander Shiyan wrote:
>> Hello.
>>
>>> On Tue, Nov 12, 2013 at 10:07:13AM +0000, Alexander Shiyan wrote:
>>>> This patch adds a new driver for the beeper controlled via GPIO pin.
>>>> The driver does not depend on the architecture and is positioned as
>>>> a replacement for the specific drivers that are used for this function.
>>>>
>>>> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
>> ...
>>>> diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
>> ...
>>>> +Example:
>>>> +
>>>> +beeper: input@0 {
>>>> + compatible = "gpio-beeper";
>>>> + reg = <0>;
>>>> + gpios = <&gpio3 23 0>;
>>>> +};
>>>
>>> What are the reg / unit-address for?
>>
>> Just an example from "simple-bus" container.
>
> If they have no meaning, they should go. They're unnecessary and make
> things more confusing.
>
> I'd expect the example to be:
>
> beeper: beeper {
> compatible = "gpio-beeper";
> gpios - <&gpio3 23 0>;
> };
>
> And if we have multiple beepers, something like:
>
> beeper0: beeper0 { ... };
> beeper1: beeper1 { ... };
DT node names aren't meant to encode identity though. What we've done in
the past for nodes without a reg where multiple instances were desired
is to put them into simple-bus and add a reg, so:
beeper0: beeper@0 { reg = <0>; ... };
beeper1: beeper@1 { reg = <1>; ... };
Of course, if there's only one of them, then it could just be "beeper"
with no reg. The binding and example should probably reflect that simple
case.
^ permalink raw reply
* Re: [PATCH v2 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-11-12 23:32 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linus Walleij,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart, Vinod Koul,
linux-sh-u79uwXL29TY76Z2rM5mHXA, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Mark Brown,
xfoundat@
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Hello,
On Tuesday 29 October 2013 23:37:35 Laurent Pinchart wrote:
> Hello,
>
> This patch series, based on v3.12-rc7, prepares various Renesas drivers
> for migration to multiplatform kernels by enabling their compilation or
> otherwise fixing them on all ARM platforms. The patches are pretty
> straightforward and are described in their commit message.
>
> Changes since v1:
>
> - The drivers can also be selected when COMPILE_TEST is enabled, regardless
> of the architecture. This should provide a good compromise between wide
> build test coverage and not clobbering configuration with drivers useless
> on non-SuperH, non-ARM platforms.
>
> - DMA configuration is now unconditional in patch 08/19
>
> I'd like to get all these patches merged in v3.14. As they will need to go
> through their respective subsystems' trees, I would appreciate if all
> maintainers involved could notify me when they merge patches from this
> series in their tree to help me tracking the merge status. I don't plan to
> send pull requests individually for these patches, and I will repost
> patches individually if changes are requested during review.
>
> If you believe the issue should be solved in a different way please reply to
> the cover letter to let other maintainers chime in.
This patch series was a prerequisite for a larger rework of Renesas platforms.
However, we've decided to go with an alternative approach that renames Kconfig
symbols to avoid touching all the drivers. There is thus no urgency to apply
this series anymore.
I still plan to enable COMPILE_TEST on Renesas drivers. I will send a v3 of
these patches based on the feedback received on v2. Patches from v2 that have
already been applied can be dropped, but there's no need to revert them rebase
trees as they're not invalid per-se. I will make sure to address the situation
in v3. I'm sorry for the inconvenience.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: input question: ambient light sensor button
From: Jiri Kosina @ 2013-11-13 10:47 UTC (permalink / raw)
To: Pali Rohár; +Cc: linux-kernel, linux-input, Dmitry Torokhov
In-Reply-To: <201309151553.34000@pali>
On Sun, 15 Sep 2013, Pali Rohár wrote:
> I do not know where to ask this question, but I think that kernel
> developers could help me.
>
> I have notebook with one special button on keyboard which is
> designed for turning ambient light sensor on and off. By default
> pressing button do nothing (I can turn ambient light sensor on/off
> via sysfs platform wmi module). Button press is reported by
> kernel input device AT Translated Set 2 keyboard and reports it
> as button "touchpad off".
>
> Of course "touchpad off" is incorrect and I'd like to ask which
> kernel key or button from /usr/include/linux/input.h should be
> mapped for my ambient light sensor button? Is there already some?
> And what is strategy for allocating KEY_* and BTN_* numbers?
This is maintained by Dmitry, so he's the one to answer this. I am adding
him to CC.
> I'd like to know this, so udev could have correct DMI keymap
> hooks and other userspace programs can understand ambient light
> sensor button correctly.
--
Jiri Kosina
SUSE Labs
--
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
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