* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Benjamin Tissoires @ 2014-08-06 21:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Ping Cheng, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <20140806210401.GB22889@core.coreip.homeip.net>
On Aug 06 2014 or thereabouts, Dmitry Torokhov wrote:
> On Wed, Aug 06, 2014 at 04:44:08PM -0400, Benjamin Tissoires wrote:
> > On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> > > On Tue, Aug 5, 2014 at 2:34 PM, Benjamin Tissoires
> > > <benjamin.tissoires@redhat.com> wrote:
> > > > Hi Ping,
> > > >
> > > > On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> > > >> Thank you Benjamin for updating the ABI docs. My comments are inline.
> > > >>
> > > >> With those lines updated, this patch is:
> > > >>
> > > >> Reviewed-by: Ping Cheng <pingc@wacom.com>
> > > >
> > > > Thanks!
> > > >
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Ping
> > > >>
> > > >> On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
> > > >> <benjamin.tissoires@redhat.com> wrote:
> > > >> > Now the devices show up under hid no matter the connection. So update the
> > > >> > sysfs path to the shortest and common one.
> > > >> > The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> > > >> > only 1-bit images instead of 4.
> > > >> >
> > > >> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > >> > ---
> > > >> >
> > > >> > Guys,
> > > >> >
> > > >> > by updating this and working on the g-s-d client side for OLEDs, I think now
> > > >> > that we should also keep the oled*_img for Bluetooth and implement this file
> > > >> > for USB too. The user space code gets messy quite fast due to the need to
> > > >> > support old and new kernels, whereas if we handle the scrambling in the kernel,
> > > >> > it should be quite straightforward.
> > > >> > Of course, we have to keep the current button<n>_rawimg for backward
> > > >> > compatibility.
> > > >> >
> > > >> > Any thoughts?
> > > >> >
> > > >> > Cheers,
> > > >> > Benjamin
> > > >> >
> > > >> > Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
> > > >> > 1 file changed, 20 insertions(+), 36 deletions(-)
> > > >> >
> > > >> > diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
> > > >> > index 7fc7810..c75ed4c 100644
> > > >> > --- a/Documentation/ABI/testing/sysfs-driver-wacom
> > > >> > +++ b/Documentation/ABI/testing/sysfs-driver-wacom
> > > >> > @@ -1,47 +1,26 @@
> > > >> > -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
> > > >> > -Date: June 2012
> > > >> > -Contact: linux-bluetooth@vger.kernel.org
> > > >> > -Description:
> > > >> > - The /sys/class/hidraw/hidraw*/device/oled*_img files control
> > > >> > - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
> > > >> > - has to contain 256 bytes (64x32 px 1 bit colour). The format
> > > >> > - is the same as PBM image 62x32px without header (64 bits per
> > > >> > - horizontal line, 32 lines). An example of setting OLED No. 0:
> > > >> > - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
> > > >> > - The attribute is read only and no local copy of the image is
> > > >> > - stored.
> > > >> > -
> > > >> > -What: /sys/class/hidraw/hidraw*/device/speed
> > > >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
> > > >> > Date: April 2010
> > > >>
> > > >> Should the Date be updated?
> > > >
> > > > I don't think that this one should. The ABI is the same since April
> > > > 2010, and the "new" path works also for older kernels. So basically,
> > > > here, for Bluetooth, there has been no changes.
> > >
> > > Oh, I see your point. But, don't we consider path part of the interface?
> > >
> >
> > Well, in this case, both the path /sys/class/hidraw/hidraw*/device/speed
> > and /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed refers to the same
> > device, even in April 2010.
> >
> > /sys/class/hidraw/hidraw*/device is IMO not accurate because you have to
> > check all the hidraw devices to find the right one.
> > /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed gives you the correct
> > at first sight. This is just a fix to have a more reliable path in the
> > documentation, not a change.
>
> Can we document this in changelog?
>
Hmm, yes. I guess I'll have to send a new version with this
documentation in the commit message and the update of the other dates.
I should be offline for the next 3 to 4 hours, so it will have to wait
tonight or tomorrow morning.
BTW, thanks for merging the rest of the series (and the various
patches). Greatly appreciated.
Cheers,
Benjamin
^ permalink raw reply
* Re: TSC2004 driver
From: Dmitry Torokhov @ 2014-08-06 21:16 UTC (permalink / raw)
To: Joachim Eastwood
Cc: Michael Welling, linux-omap, linux-input, Hiremath, Vaibhav
In-Reply-To: <CAGhQ9Vy7AhWkAR3ZMxoWnbZ_zpOPvqcL93fqQ=YkpuULO3MVzQ@mail.gmail.com>
On Wed, Aug 06, 2014 at 10:33:18PM +0200, Joachim Eastwood wrote:
> On 6 August 2014 21:37, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > Hi Michael,
> >
> > On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote:
> >> The TSC2004 driver has yet to appear in the mainline kernel. We have
> >> been using the driver referenced here as provided by TI:
> >>
> >> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html
> >>
> >> Are there any plans of supporting this device in the mainline kernel?
> >
> > I still believe that support for TSC2004 should be added 5to tsc2007, they are
> > too much alike to be separate drivers.
>
> I tried to add tsc2004 support to the tsc2007 driver but I didn't
> really get it to work properly because the tsc2007 interrupt handling
> differs from what tsc2004 needs.
OK.
>
> I think it would be better to add tsc2004 support to the tsc2005
> driver. They only difference between those two chips is the interface
> (i2c vs spi). If regmap was added to tsc2005 I think it should be easy
> to support tsc2004.
That would also be acceptable.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Dmitry Torokhov @ 2014-08-06 21:04 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Ping Cheng, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <20140806204408.GC15018@mail.corp.redhat.com>
On Wed, Aug 06, 2014 at 04:44:08PM -0400, Benjamin Tissoires wrote:
> On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> > On Tue, Aug 5, 2014 at 2:34 PM, Benjamin Tissoires
> > <benjamin.tissoires@redhat.com> wrote:
> > > Hi Ping,
> > >
> > > On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> > >> Thank you Benjamin for updating the ABI docs. My comments are inline.
> > >>
> > >> With those lines updated, this patch is:
> > >>
> > >> Reviewed-by: Ping Cheng <pingc@wacom.com>
> > >
> > > Thanks!
> > >
> > >>
> > >> Cheers,
> > >>
> > >> Ping
> > >>
> > >> On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
> > >> <benjamin.tissoires@redhat.com> wrote:
> > >> > Now the devices show up under hid no matter the connection. So update the
> > >> > sysfs path to the shortest and common one.
> > >> > The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> > >> > only 1-bit images instead of 4.
> > >> >
> > >> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > >> > ---
> > >> >
> > >> > Guys,
> > >> >
> > >> > by updating this and working on the g-s-d client side for OLEDs, I think now
> > >> > that we should also keep the oled*_img for Bluetooth and implement this file
> > >> > for USB too. The user space code gets messy quite fast due to the need to
> > >> > support old and new kernels, whereas if we handle the scrambling in the kernel,
> > >> > it should be quite straightforward.
> > >> > Of course, we have to keep the current button<n>_rawimg for backward
> > >> > compatibility.
> > >> >
> > >> > Any thoughts?
> > >> >
> > >> > Cheers,
> > >> > Benjamin
> > >> >
> > >> > Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
> > >> > 1 file changed, 20 insertions(+), 36 deletions(-)
> > >> >
> > >> > diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
> > >> > index 7fc7810..c75ed4c 100644
> > >> > --- a/Documentation/ABI/testing/sysfs-driver-wacom
> > >> > +++ b/Documentation/ABI/testing/sysfs-driver-wacom
> > >> > @@ -1,47 +1,26 @@
> > >> > -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
> > >> > -Date: June 2012
> > >> > -Contact: linux-bluetooth@vger.kernel.org
> > >> > -Description:
> > >> > - The /sys/class/hidraw/hidraw*/device/oled*_img files control
> > >> > - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
> > >> > - has to contain 256 bytes (64x32 px 1 bit colour). The format
> > >> > - is the same as PBM image 62x32px without header (64 bits per
> > >> > - horizontal line, 32 lines). An example of setting OLED No. 0:
> > >> > - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
> > >> > - The attribute is read only and no local copy of the image is
> > >> > - stored.
> > >> > -
> > >> > -What: /sys/class/hidraw/hidraw*/device/speed
> > >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
> > >> > Date: April 2010
> > >>
> > >> Should the Date be updated?
> > >
> > > I don't think that this one should. The ABI is the same since April
> > > 2010, and the "new" path works also for older kernels. So basically,
> > > here, for Bluetooth, there has been no changes.
> >
> > Oh, I see your point. But, don't we consider path part of the interface?
> >
>
> Well, in this case, both the path /sys/class/hidraw/hidraw*/device/speed
> and /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed refers to the same
> device, even in April 2010.
>
> /sys/class/hidraw/hidraw*/device is IMO not accurate because you have to
> check all the hidraw devices to find the right one.
> /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed gives you the correct
> at first sight. This is just a fix to have a more reliable path in the
> documentation, not a change.
Can we document this in changelog?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: rmi: print an error if F11 is not found instead of stopping the device
From: Andrew Duggan @ 2014-08-06 20:37 UTC (permalink / raw)
To: linux-input, linux-kernel; +Cc: Andrew Duggan, Jiri Kosina, Benjamin Tissoires
Currently rmi_probe will return -EIO if the device doesn't report that it has F11.
This would indicate that something happened and the device is in the bootloader.
We can recover the device using a userspace firmware update tool, but it needs
access to the device through the hidraw device file. If the probe returns -EIO
the hidraw device won't be created. So instead of failing the probe, just print
an error message, but leave the device accessible from userspace.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
---
drivers/hid/hid-rmi.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 0dc2514..8389e81 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -909,10 +909,15 @@ static int rmi_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
- if (!test_bit(RMI_STARTED, &data->flags)) {
- hid_hw_stop(hdev);
- return -EIO;
- }
+ if (!test_bit(RMI_STARTED, &data->flags))
+ /*
+ * The device maybe in the bootloader if rmi_input_configured
+ * failed to find F11 in the PDT. Print an error, but don't
+ * return an error from rmi_probe so that hidraw will be
+ * accessible from userspace. That way a userspace tool
+ * can be used to reload working firmware on the touchpad.
+ */
+ hid_err(hdev, "Device failed to be properly configured\n");
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Benjamin Tissoires @ 2014-08-06 20:44 UTC (permalink / raw)
To: Ping Cheng
Cc: Dmitry Torokhov, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <CAF8JNhKR8uDB4AS5B00y-m7MCH6H8CHGegRb+W8ahS+gdtveNg@mail.gmail.com>
On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> On Tue, Aug 5, 2014 at 2:34 PM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > Hi Ping,
> >
> > On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> >> Thank you Benjamin for updating the ABI docs. My comments are inline.
> >>
> >> With those lines updated, this patch is:
> >>
> >> Reviewed-by: Ping Cheng <pingc@wacom.com>
> >
> > Thanks!
> >
> >>
> >> Cheers,
> >>
> >> Ping
> >>
> >> On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
> >> <benjamin.tissoires@redhat.com> wrote:
> >> > Now the devices show up under hid no matter the connection. So update the
> >> > sysfs path to the shortest and common one.
> >> > The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> >> > only 1-bit images instead of 4.
> >> >
> >> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >> > ---
> >> >
> >> > Guys,
> >> >
> >> > by updating this and working on the g-s-d client side for OLEDs, I think now
> >> > that we should also keep the oled*_img for Bluetooth and implement this file
> >> > for USB too. The user space code gets messy quite fast due to the need to
> >> > support old and new kernels, whereas if we handle the scrambling in the kernel,
> >> > it should be quite straightforward.
> >> > Of course, we have to keep the current button<n>_rawimg for backward
> >> > compatibility.
> >> >
> >> > Any thoughts?
> >> >
> >> > Cheers,
> >> > Benjamin
> >> >
> >> > Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
> >> > 1 file changed, 20 insertions(+), 36 deletions(-)
> >> >
> >> > diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
> >> > index 7fc7810..c75ed4c 100644
> >> > --- a/Documentation/ABI/testing/sysfs-driver-wacom
> >> > +++ b/Documentation/ABI/testing/sysfs-driver-wacom
> >> > @@ -1,47 +1,26 @@
> >> > -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
> >> > -Date: June 2012
> >> > -Contact: linux-bluetooth@vger.kernel.org
> >> > -Description:
> >> > - The /sys/class/hidraw/hidraw*/device/oled*_img files control
> >> > - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
> >> > - has to contain 256 bytes (64x32 px 1 bit colour). The format
> >> > - is the same as PBM image 62x32px without header (64 bits per
> >> > - horizontal line, 32 lines). An example of setting OLED No. 0:
> >> > - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
> >> > - The attribute is read only and no local copy of the image is
> >> > - stored.
> >> > -
> >> > -What: /sys/class/hidraw/hidraw*/device/speed
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
> >> > Date: April 2010
> >>
> >> Should the Date be updated?
> >
> > I don't think that this one should. The ABI is the same since April
> > 2010, and the "new" path works also for older kernels. So basically,
> > here, for Bluetooth, there has been no changes.
>
> Oh, I see your point. But, don't we consider path part of the interface?
>
Well, in this case, both the path /sys/class/hidraw/hidraw*/device/speed
and /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed refers to the same
device, even in April 2010.
/sys/class/hidraw/hidraw*/device is IMO not accurate because you have to
check all the hidraw devices to find the right one.
/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed gives you the correct
at first sight. This is just a fix to have a more reliable path in the
documentation, not a change.
Cheers,
Benjamin
>
> >>
> >> > Kernel Version: 2.6.35
> >>
> >> This patch is planned for 3.16, right?
> >
> > Same comment than before (about not touching it).
> > This will be planned for 3.17, 3.16 has been out last Sunday.
> >
> >>
> >> > Contact: linux-bluetooth@vger.kernel.org
> >> > Description:
> >> > - The /sys/class/hidraw/hidraw*/device/speed file controls
> >> > - reporting speed of Wacom bluetooth tablet. Reading from
> >> > - this file returns 1 if tablet reports in high speed mode
> >> > + The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
> >> > + controls reporting speed of Wacom bluetooth tablet. Reading
> >> > + from this file returns 1 if tablet reports in high speed mode
> >> > or 0 otherwise. Writing to this file one of these values
> >> > switches reporting speed.
> >> >
> >> > -What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
> >> > -Date: May 2012
> >> > -Kernel Version: 3.5
> >> > -Contact: linux-bluetooth@vger.kernel.org
> >> > -Description:
> >> > - LED selector for Intuos4 WL. There are 4 leds, but only one LED
> >> > - can be lit at a time. Max brightness is 127.
> >> > -
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
> >> > Date: August 2011
> >>
> >> Same here and other 6 dates below
> >
> > We can probably update these dates. I let them untouched because the
> > ABI did not changed but only the path did.
> >
> >>
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > Attribute group for control of the status LEDs and the OLEDs.
> >> > This attribute group is only available for Intuos 4 M, L,
> >> > - and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
> >> > - 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
> >> > - implicitly signifies the presence of said LEDs and OLEDs on the
> >> > - tablet device.
> >> > + and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
> >> > + Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
> >> > + (LEDs only). Therefore its presence implicitly signifies the
> >> > + presence of said LEDs and OLEDs on the tablet device.
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
> >> > Date: August 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > @@ -50,7 +29,7 @@ Description:
> >> > button is pressed on the stylus. This luminance level is
> >> > normally lower than the level when a button is pressed.
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
> >> > Date: August 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > @@ -58,7 +37,7 @@ Description:
> >> > when the stylus touches the tablet surface, or any button is
> >> > pressed on the stylus.
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
> >> > Date: August 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > @@ -67,7 +46,7 @@ Description:
> >> > 24HD) status LEDs is active (0..3). The other three LEDs on the
> >> > same side are always inactive.
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
> >> > Date: September 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > @@ -75,14 +54,14 @@ Description:
> >> > and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
> >> > the left are always inactive.
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
> >> > Date: August 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > Writing to this file sets the overall luminance level (0..15)
> >>
> >> We need to specify that this ABI is only for Intuos 4 (USB and Bluetooth).
> >
> > Yep. We can carry this fix too in this patch.
> >
> > Cheers,
> > Benjamin
> >
> >>
> >> > of all eight button OLED displays.)
> >> >
> >> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
> >> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
> >> > Date: August 2011
> >> > Contact: linux-input@vger.kernel.org
> >> > Description:
> >> > @@ -93,3 +72,8 @@ Description:
> >> > byte chunk encodes the image data for two consecutive lines on
> >> > the display. The low nibble of each byte contains the first
> >> > line, and the high nibble contains the second line.
> >> > + When the Wacom Intuos 4 is connected over Bluetooth, the
> >> > + image has to contain 256 bytes (64x32 px 1 bit colour).
> >> > + The format is also scrambled, like in the USB mode, and it can
> >> > + be summarized by converting 76543210 into GECA6420.
> >> > + HGFEDCBA HFDB7531
> >> > --
> >> > 2.0.4
> >> >
^ permalink raw reply
* Re: [PATCH] Input: hyperv-keyboard: register as a wakeup source
From: Dmitry Torokhov @ 2014-08-06 20:33 UTC (permalink / raw)
To: Dexuan Cui
Cc: gregkh, linux-input, linux-kernel, driverdev-devel, olaf, apw,
jasowang, kys, haiyangz
In-Reply-To: <1406903304-7256-1-git-send-email-decui@microsoft.com>
On Fri, Aug 01, 2014 at 07:28:24AM -0700, Dexuan Cui wrote:
> With this patch, we can press a key to wake up the VM after the VM executes
> "echo freeze > /sys/power/state".
>
> This addresses part of https://bugzilla.redhat.com/show_bug.cgi?id=1086100
I am sorry but this bug is not open to the public. Please avoid
mentioning such bugs in changelogs. Otherwise I'll apply it.
>
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> ---
> drivers/input/serio/hyperv-keyboard.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/input/serio/hyperv-keyboard.c b/drivers/input/serio/hyperv-keyboard.c
> index 6132619..e74e5d6 100644
> --- a/drivers/input/serio/hyperv-keyboard.c
> +++ b/drivers/input/serio/hyperv-keyboard.c
> @@ -170,6 +170,15 @@ static void hv_kbd_on_receive(struct hv_device *hv_dev,
> serio_interrupt(kbd_dev->hv_serio, scan_code, 0);
> }
> spin_unlock_irqrestore(&kbd_dev->lock, flags);
> +
> + /*
> + * Only trigger a wakeup on key down, otherwise
> + * "echo freeze > /sys/power/state" can't really enter the
> + * state because the Enter-UP can trigger a wakeup at once.
> + */
> + if (!(info & IS_BREAK))
> + pm_wakeup_event(&hv_dev->device, 0);
> +
> break;
>
> default:
> @@ -376,6 +385,9 @@ static int hv_kbd_probe(struct hv_device *hv_dev,
> goto err_close_vmbus;
>
> serio_register_port(kbd_dev->hv_serio);
> +
> + device_init_wakeup(&hv_dev->device, true);
> +
> return 0;
>
> err_close_vmbus:
> @@ -390,6 +402,7 @@ static int hv_kbd_remove(struct hv_device *hv_dev)
> {
> struct hv_kbd_dev *kbd_dev = hv_get_drvdata(hv_dev);
>
> + device_init_wakeup(&hv_dev->device, false);
> serio_unregister_port(kbd_dev->hv_serio);
> vmbus_close(hv_dev->channel);
> kfree(kbd_dev);
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: TSC2004 driver
From: Joachim Eastwood @ 2014-08-06 20:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Michael Welling, linux-omap, linux-input, Hiremath, Vaibhav
In-Reply-To: <20140806193727.GB24718@core.coreip.homeip.net>
On 6 August 2014 21:37, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Michael,
>
> On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote:
>> The TSC2004 driver has yet to appear in the mainline kernel. We have
>> been using the driver referenced here as provided by TI:
>>
>> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html
>>
>> Are there any plans of supporting this device in the mainline kernel?
>
> I still believe that support for TSC2004 should be added 5to tsc2007, they are
> too much alike to be separate drivers.
I tried to add tsc2004 support to the tsc2007 driver but I didn't
really get it to work properly because the tsc2007 interrupt handling
differs from what tsc2004 needs.
I think it would be better to add tsc2004 support to the tsc2005
driver. They only difference between those two chips is the interface
(i2c vs spi). If regmap was added to tsc2005 I think it should be easy
to support tsc2004.
>>
>> Mysteriously a device tree entry was found in the following file:
>> arch/arm/boot/dts/omap4-var-som-om44.dtsi
>>
>> This is obviously pointing to an out of tree driver that is not easily
>> obtained.
I have patches that add tsc2004 support to the tsc2007 driver, but I
really can't recommend them. The interrupt handling is broken so for
each touch event the chip needs to be software reset...
The driver you posted a link to above also has flaw btw.
regards
Joachim Eastwood
>> Suggestions?
>
> Thanks.
>
> --
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 v5] input: drv260x: Add TI drv260x haptics driver
From: Murphy, Dan @ 2014-08-06 19:47 UTC (permalink / raw)
To: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
mark.rutland@arm.com, madcatxster@devoid-pointer.net,
simon@mungewell.org, elias.vds@gmail.com,
dmitry.torokhov@gmail.com
In-Reply-To: <1406834089-15095-1-git-send-email-dmurphy@ti.com>
Bump
On 07/31/2014 02:14 PM, Murphy, Dan wrote:
> Add the TI drv260x haptics/vibrator driver.
> This device uses the input force feedback
> to produce a wave form to driver an
> ERM or LRA actuator device.
>
> The initial driver supports the devices
> real time playback mode. But the device
> has additional wave patterns in ROM.
>
> This functionality will be added in
> future patchsets.
>
> Product data sheet is located here:
> http://www.ti.com/product/drv2605
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v5 - Move register defines to c file and rm header file, error check
> init in probe, fixed identation, remove empty labels in probe
> and just return on fail and removed the remove callback and function.
> Did not factor out the suspend into a stop function. - https://patchwork.kernel.org/patch/4649631/
> v4 - Convert regulator to devm, added error checking where required,
> updated bindings doc, moved dt parsing to separate call and made platform
> data the first data point, moved vibrator enable and mode programming from
> play entry to worker thread, added user check and input mutex in suspend/resume
> calls, moved platform data to individual file and into include platform-data directory,
> removed file names from file headers - https://patchwork.kernel.org/patch/4642221/
> v3 - Updated binding doc, changed to memless device, updated input alloc to
> devm, removed mutex locking, add sanity checks for mode and library - https://patchwork.kernel.org/patch/4635421/
> v2 - Fixed binding doc and patch headline - https://patchwork.kernel.org/patch/4619641/
>
>
> .../devicetree/bindings/input/ti,drv260x.txt | 50 ++
> drivers/input/misc/Kconfig | 9 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/drv260x.c | 697 ++++++++++++++++++++
> include/dt-bindings/input/ti-drv260x.h | 35 +
> include/linux/platform_data/drv260x-pdata.h | 29 +
> 6 files changed, 821 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
> create mode 100644 drivers/input/misc/drv260x.c
> create mode 100644 include/dt-bindings/input/ti-drv260x.h
> create mode 100644 include/linux/platform_data/drv260x-pdata.h
>
> diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt
> new file mode 100644
> index 0000000..8e6970d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
> @@ -0,0 +1,50 @@
> +Texas Instruments - drv260x Haptics driver family
> +
> +The drv260x family serial control bus communicates through I2C protocols
> +
> +Required properties:
> + - compatible - One of:
> + "ti,drv2604" - DRV2604
> + "ti,drv2605" - DRV2605
> + "ti,drv2605l" - DRV2605L
> + - reg - I2C slave address
> + - supply- Required supply regulators are:
> + "vbat" - battery voltage
> + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h)
> + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric)
> + DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration
> + sequence during init. And the device is configured for real
> + time playback mode (RTP mode).
> + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator)
> + - library-sel - These are ROM based waveforms pre-programmed into the IC.
> + This should be set to set the library to use at power up.
> + (defined in include/dt-bindings/input/ti-drv260x.h)
> + DRV260X_LIB_A - Pre-programmed Library
> + DRV260X_LIB_B - Pre-programmed Library
> + DRV260X_LIB_C - Pre-programmed Library
> + DRV260X_LIB_D - Pre-programmed Library
> + DRV260X_LIB_E - Pre-programmed Library
> + DRV260X_LIB_F - Pre-programmed Library
> +
> +Optional properties:
> + - enable-gpio - gpio pin to enable/disable the device.
> + - vib_rated_voltage - The rated voltage of the actuator in millivolts.
> + If this is not set then the value will be defaulted to
> + 3.2 v.
> + - vib_overdrive_voltage - The overdrive voltage of the actuator in millivolts.
> + If this is not set then the value will be defaulted to
> + 3.2 v.
> +Example:
> +
> +drv2605l: drv2605l@5a {
> + compatible = "ti,drv2605l";
> + reg = <0x5a>;
> + enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> + mode = <DRV260X_LRA_MODE>;
> + library-sel = <DRV260X_LIB_SEL_DEFAULT>;
> + vib-rated-voltage = <3200>;
> + vib-overdriver-voltage = <3200>;
> +};
> +
> +For more product information please see the link below:
> +http://www.ti.com/product/drv2605
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 2ff4425..99f6762 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
> To compile this driver as a module, choose M here: the
> module will be called soc_button_array.
>
> +config INPUT_DRV260X_HAPTICS
> + tristate "TI DRV260X haptics support"
> + depends on INPUT && I2C
> + help
> + Say Y to enable support for the TI DRV260X haptics driver.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called drv260x-haptics.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 4955ad3..d8ef3c7 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -64,3 +64,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
> obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
> obj-$(CONFIG_INPUT_YEALINK) += yealink.o
> obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
> +obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
> diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
> new file mode 100644
> index 0000000..6ccdeff
> --- /dev/null
> +++ b/drivers/input/misc/drv260x.c
> @@ -0,0 +1,697 @@
> +/*
> + * DRV260X haptics driver family
> + *
> + * Author: Dan Murphy <dmurphy@ti.com>
> + *
> + * Copyright: (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <dt-bindings/input/ti-drv260x.h>
> +#include <linux/platform_data/drv260x-pdata.h>
> +
> +#define DRV260X_STATUS 0x0
> +#define DRV260X_MODE 0x1
> +#define DRV260X_RT_PB_IN 0x2
> +#define DRV260X_LIB_SEL 0x3
> +#define DRV260X_WV_SEQ_1 0x4
> +#define DRV260X_WV_SEQ_2 0x5
> +#define DRV260X_WV_SEQ_3 0x6
> +#define DRV260X_WV_SEQ_4 0x7
> +#define DRV260X_WV_SEQ_5 0x8
> +#define DRV260X_WV_SEQ_6 0x9
> +#define DRV260X_WV_SEQ_7 0xa
> +#define DRV260X_WV_SEQ_8 0xb
> +#define DRV260X_GO 0xc
> +#define DRV260X_OVERDRIVE_OFF 0xd
> +#define DRV260X_SUSTAIN_P_OFF 0xe
> +#define DRV260X_SUSTAIN_N_OFF 0xf
> +#define DRV260X_BRAKE_OFF 0x10
> +#define DRV260X_A_TO_V_CTRL 0x11
> +#define DRV260X_A_TO_V_MIN_INPUT 0x12
> +#define DRV260X_A_TO_V_MAX_INPUT 0x13
> +#define DRV260X_A_TO_V_MIN_OUT 0x14
> +#define DRV260X_A_TO_V_MAX_OUT 0x15
> +#define DRV260X_RATED_VOLT 0x16
> +#define DRV260X_OD_CLAMP_VOLT 0x17
> +#define DRV260X_CAL_COMP 0x18
> +#define DRV260X_CAL_BACK_EMF 0x19
> +#define DRV260X_FEEDBACK_CTRL 0x1a
> +#define DRV260X_CTRL1 0x1b
> +#define DRV260X_CTRL2 0x1c
> +#define DRV260X_CTRL3 0x1d
> +#define DRV260X_CTRL4 0x1e
> +#define DRV260X_CTRL5 0x1f
> +#define DRV260X_LRA_LOOP_PERIOD 0x20
> +#define DRV260X_VBAT_MON 0x21
> +#define DRV260X_LRA_RES_PERIOD 0x22
> +#define DRV260X_MAX_REG 0x23
> +
> +#define DRV260X_ALLOWED_R_BYTES 25
> +#define DRV260X_ALLOWED_W_BYTES 2
> +#define DRV260X_MAX_RW_RETRIES 5
> +#define DRV260X_I2C_RETRY_DELAY 10
> +
> +#define DRV260X_GO_BIT 0x01
> +
> +/* Library Selection */
> +#define DRV260X_LIB_SEL_MASK 0x07
> +#define DRV260X_LIB_SEL_RAM 0x0
> +#define DRV260X_LIB_SEL_OD 0x1
> +#define DRV260X_LIB_SEL_40_60 0x2
> +#define DRV260X_LIB_SEL_60_80 0x3
> +#define DRV260X_LIB_SEL_100_140 0x4
> +#define DRV260X_LIB_SEL_140_PLUS 0x5
> +
> +#define DRV260X_LIB_SEL_HIZ_MASK 0x10
> +#define DRV260X_LIB_SEL_HIZ_EN 0x01
> +#define DRV260X_LIB_SEL_HIZ_DIS 0
> +
> +/* Mode register */
> +#define DRV260X_STANDBY (1 << 6)
> +#define DRV260X_STANDBY_MASK 0x40
> +#define DRV260X_INTERNAL_TRIGGER 0x00
> +#define DRV260X_EXT_TRIGGER_EDGE 0x01
> +#define DRV260X_EXT_TRIGGER_LEVEL 0x02
> +#define DRV260X_PWM_ANALOG_IN 0x03
> +#define DRV260X_AUDIOHAPTIC 0x04
> +#define DRV260X_RT_PLAYBACK 0x05
> +#define DRV260X_DIAGNOSTICS 0x06
> +#define DRV260X_AUTO_CAL 0x07
> +
> +/* Audio to Haptics Control */
> +#define DRV260X_AUDIO_HAPTICS_PEAK_10MS (0 << 2)
> +#define DRV260X_AUDIO_HAPTICS_PEAK_20MS (1 << 2)
> +#define DRV260X_AUDIO_HAPTICS_PEAK_30MS (2 << 2)
> +#define DRV260X_AUDIO_HAPTICS_PEAK_40MS (3 << 2)
> +
> +#define DRV260X_AUDIO_HAPTICS_FILTER_100HZ 0x00
> +#define DRV260X_AUDIO_HAPTICS_FILTER_125HZ 0x01
> +#define DRV260X_AUDIO_HAPTICS_FILTER_150HZ 0x02
> +#define DRV260X_AUDIO_HAPTICS_FILTER_200HZ 0x03
> +
> +/* Min/Max Input/Output Voltages */
> +#define DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT 0x19
> +#define DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT 0x64
> +#define DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT 0x19
> +#define DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT 0xFF
> +
> +/* Feedback register */
> +#define DRV260X_FB_REG_ERM_MODE 0x7f
> +#define DRV260X_FB_REG_LRA_MODE (1 << 7)
> +
> +#define DRV260X_BRAKE_FACTOR_MASK 0x1f
> +#define DRV260X_BRAKE_FACTOR_2X (1 << 0)
> +#define DRV260X_BRAKE_FACTOR_3X (2 << 4)
> +#define DRV260X_BRAKE_FACTOR_4X (3 << 4)
> +#define DRV260X_BRAKE_FACTOR_6X (4 << 4)
> +#define DRV260X_BRAKE_FACTOR_8X (5 << 4)
> +#define DRV260X_BRAKE_FACTOR_16 (6 << 4)
> +#define DRV260X_BRAKE_FACTOR_DIS (7 << 4)
> +
> +#define DRV260X_LOOP_GAIN_LOW 0xf3
> +#define DRV260X_LOOP_GAIN_MED (1 << 2)
> +#define DRV260X_LOOP_GAIN_HIGH (2 << 2)
> +#define DRV260X_LOOP_GAIN_VERY_HIGH (3 << 2)
> +
> +#define DRV260X_BEMF_GAIN_0 0xfc
> +#define DRV260X_BEMF_GAIN_1 (1 << 0)
> +#define DRV260X_BEMF_GAIN_2 (2 << 0)
> +#define DRV260X_BEMF_GAIN_3 (3 << 0)
> +
> +/* Control 1 register */
> +#define DRV260X_AC_CPLE_EN (1 << 5)
> +#define DRV260X_STARTUP_BOOST (1 << 7)
> +
> +/* Control 2 register */
> +
> +#define DRV260X_IDISS_TIME_45 0
> +#define DRV260X_IDISS_TIME_75 (1 << 0)
> +#define DRV260X_IDISS_TIME_150 (1 << 1)
> +#define DRV260X_IDISS_TIME_225 0x03
> +
> +#define DRV260X_BLANK_TIME_45 (0 << 2)
> +#define DRV260X_BLANK_TIME_75 (1 << 2)
> +#define DRV260X_BLANK_TIME_150 (2 << 2)
> +#define DRV260X_BLANK_TIME_225 (3 << 2)
> +
> +#define DRV260X_SAMP_TIME_150 (0 << 4)
> +#define DRV260X_SAMP_TIME_200 (1 << 4)
> +#define DRV260X_SAMP_TIME_250 (2 << 4)
> +#define DRV260X_SAMP_TIME_300 (3 << 4)
> +
> +#define DRV260X_BRAKE_STABILIZER (1 << 6)
> +#define DRV260X_UNIDIR_IN (0 << 7)
> +#define DRV260X_BIDIR_IN (1 << 7)
> +
> +/* Control 3 Register */
> +#define DRV260X_LRA_OPEN_LOOP (1 << 0)
> +#define DRV260X_ANANLOG_IN (1 << 1)
> +#define DRV260X_LRA_DRV_MODE (1 << 2)
> +#define DRV260X_RTP_UNSIGNED_DATA (1 << 3)
> +#define DRV260X_SUPPLY_COMP_DIS (1 << 4)
> +#define DRV260X_ERM_OPEN_LOOP (1 << 5)
> +#define DRV260X_NG_THRESH_0 (0 << 6)
> +#define DRV260X_NG_THRESH_2 (1 << 6)
> +#define DRV260X_NG_THRESH_4 (2 << 6)
> +#define DRV260X_NG_THRESH_8 (3 << 6)
> +
> +/* Control 4 Register */
> +#define DRV260X_AUTOCAL_TIME_150MS (0 << 4)
> +#define DRV260X_AUTOCAL_TIME_250MS (1 << 4)
> +#define DRV260X_AUTOCAL_TIME_500MS (2 << 4)
> +#define DRV260X_AUTOCAL_TIME_1000MS (3 << 4)
> +
> +/**
> + * struct drv260x_data -
> + * @input_dev - Pointer to the input device
> + * @client - Pointer to the I2C client
> + * @regmap - Register map of the device
> + * @work - Work item used to off load the enable/disable of the vibration
> + * @enable_gpio - Pointer to the gpio used for enable/disabling
> + * @regulator - Pointer to the regulator for the IC
> + * @magnitude - Magnitude of the vibration event
> + * @mode - The operating mode of the IC (LRA_NO_CAL, ERM or LRA)
> + * @library - The vibration library to be used
> + * @rated_voltage - The rated_voltage of the actuator
> + * @overdriver_voltage - The over drive voltage of the actuator
> +**/
> +struct drv260x_data {
> + struct input_dev *input_dev;
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct work_struct work;
> + struct gpio_desc *enable_gpio;
> + struct regulator *regulator;
> + u32 magnitude;
> + u32 mode;
> + u32 library;
> + int rated_voltage;
> + int overdrive_voltage;
> +};
> +
> +static struct reg_default drv260x_reg_defs[] = {
> + { DRV260X_STATUS, 0xe0 },
> + { DRV260X_MODE, 0x40 },
> + { DRV260X_RT_PB_IN, 0x00},
> + { DRV260X_LIB_SEL, 0x00},
> + { DRV260X_WV_SEQ_1, 0x01},
> + { DRV260X_WV_SEQ_2, 0x00},
> + { DRV260X_WV_SEQ_3, 0x00},
> + { DRV260X_WV_SEQ_4, 0x00},
> + { DRV260X_WV_SEQ_5, 0x00},
> + { DRV260X_WV_SEQ_6, 0x00},
> + { DRV260X_WV_SEQ_7, 0x00},
> + { DRV260X_WV_SEQ_8, 0x00},
> + { DRV260X_GO, 0x00},
> + { DRV260X_OVERDRIVE_OFF, 0x00},
> + { DRV260X_SUSTAIN_P_OFF, 0x00},
> + { DRV260X_SUSTAIN_N_OFF, 0x00},
> + { DRV260X_BRAKE_OFF , 0x00},
> + { DRV260X_A_TO_V_CTRL , 0x05},
> + { DRV260X_A_TO_V_MIN_INPUT, 0x19},
> + { DRV260X_A_TO_V_MAX_INPUT, 0xff},
> + { DRV260X_A_TO_V_MIN_OUT, 0x19},
> + { DRV260X_A_TO_V_MAX_OUT, 0xff},
> + { DRV260X_RATED_VOLT, 0x3e},
> + { DRV260X_OD_CLAMP_VOLT, 0x8c},
> + { DRV260X_CAL_COMP, 0x0c},
> + { DRV260X_CAL_BACK_EMF, 0x6c},
> + { DRV260X_FEEDBACK_CTRL, 0x36},
> + { DRV260X_CTRL1, 0x93},
> + { DRV260X_CTRL2, 0xfa},
> + { DRV260X_CTRL3, 0xa0},
> + { DRV260X_CTRL4, 0x20},
> + { DRV260X_CTRL5, 0x80},
> + { DRV260X_LRA_LOOP_PERIOD, 0x33},
> + { DRV260X_VBAT_MON, 0x00},
> + { DRV260X_LRA_RES_PERIOD, 0x00},
> +};
> +
> +/**
> + * Rated and Overdriver Voltages:
> + * Calculated using the formula r = v * 255 / 5.6
> + * where r is what will be written to the register
> + * and v is the rated or overdriver voltage of the actuator
> + **/
> +#define DRV260X_DEF_RATED_VOLT 0x90
> +#define DRV260X_DEF_OD_CLAMP_VOLT 0x90
> +
> +static int drv260x_calculate_voltage(int voltage)
> +{
> + return (voltage * 255 / 5600);
> +}
> +
> +static void drv260x_worker(struct work_struct *work)
> +{
> + struct drv260x_data *haptics = container_of(work, struct drv260x_data, work);
> + int ret;
> +
> + gpiod_set_value(haptics->enable_gpio, 1);
> + /* Data sheet says to wait 250us before trying to communicate */
> + udelay(250);
> +
> + ret = regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_RT_PLAYBACK);
> + if (ret != 0) {
> + dev_err(&haptics->client->dev,
> + "Failed to write set mode: %d\n", ret);
> + return;
> + }
> +
> + ret = regmap_write(haptics->regmap, DRV260X_RT_PB_IN, haptics->magnitude);
> + if (ret != 0) {
> + dev_err(&haptics->client->dev,
> + "Failed to set magnitude: %d\n", ret);
> + }
> +}
> +
> +static int drv260x_haptics_play(struct input_dev *input, void *data,
> + struct ff_effect *effect)
> +{
> + struct drv260x_data *haptics = input_get_drvdata(input);
> +
> + haptics->mode = DRV260X_LRA_NO_CAL_MODE;
> + haptics->magnitude = 0;
> +
> + if (effect->u.rumble.strong_magnitude ||
> + effect->u.rumble.weak_magnitude) {
> + if (effect->u.rumble.strong_magnitude > 0)
> + haptics->magnitude = effect->u.rumble.strong_magnitude;
> + else if (effect->u.rumble.weak_magnitude > 0)
> + haptics->magnitude = effect->u.rumble.weak_magnitude;
> + }
> +
> + schedule_work(&haptics->work);
> +
> + return 0;
> +}
> +
> +static void drv260x_close(struct input_dev *input)
> +{
> + struct drv260x_data *haptics = input_get_drvdata(input);
> + int ret;
> +
> + cancel_work_sync(&haptics->work);
> +
> + ret = regmap_write(haptics->regmap, DRV260X_MODE, DRV260X_STANDBY);
> + if (ret != 0) {
> + dev_err(&haptics->client->dev,
> + "Failed to write standby mode: %d\n", ret);
> + }
> +
> + gpiod_set_value(haptics->enable_gpio, 0);
> +}
> +
> +static const struct reg_default drv260x_lra_cal_regs[] = {
> + { DRV260X_MODE, DRV260X_AUTO_CAL },
> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2},
> + { DRV260X_FEEDBACK_CTRL, DRV260X_FB_REG_LRA_MODE | DRV260X_BRAKE_FACTOR_4X | DRV260X_LOOP_GAIN_HIGH },
> +};
> +
> +static const struct reg_default drv260x_lra_init_regs[] = {
> + { DRV260X_MODE, DRV260X_RT_PLAYBACK},
> + { DRV260X_A_TO_V_CTRL, DRV260X_AUDIO_HAPTICS_PEAK_20MS | DRV260X_AUDIO_HAPTICS_FILTER_125HZ},
> + { DRV260X_A_TO_V_MIN_INPUT, DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT },
> + { DRV260X_A_TO_V_MAX_INPUT, DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT },
> + { DRV260X_A_TO_V_MIN_OUT, DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT },
> + { DRV260X_A_TO_V_MAX_OUT, DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT },
> + { DRV260X_FEEDBACK_CTRL, DRV260X_FB_REG_LRA_MODE | DRV260X_BRAKE_FACTOR_2X | DRV260X_LOOP_GAIN_MED | DRV260X_BEMF_GAIN_3 },
> + { DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
> + { DRV260X_CTRL2, DRV260X_SAMP_TIME_250 },
> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ANANLOG_IN },
> + { DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
> +};
> +
> +static const struct reg_default drv260x_erm_cal_regs[] = {
> + { DRV260X_MODE, DRV260X_AUTO_CAL },
> + { DRV260X_A_TO_V_MIN_INPUT, DRV260X_AUDIO_HAPTICS_MIN_IN_VOLT },
> + { DRV260X_A_TO_V_MAX_INPUT, DRV260X_AUDIO_HAPTICS_MAX_IN_VOLT },
> + { DRV260X_A_TO_V_MIN_OUT, DRV260X_AUDIO_HAPTICS_MIN_OUT_VOLT },
> + { DRV260X_A_TO_V_MAX_OUT, DRV260X_AUDIO_HAPTICS_MAX_OUT_VOLT },
> + { DRV260X_FEEDBACK_CTRL, DRV260X_BRAKE_FACTOR_3X | DRV260X_LOOP_GAIN_MED | DRV260X_BEMF_GAIN_2 },
> + { DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
> + { DRV260X_CTRL2, DRV260X_SAMP_TIME_250 | DRV260X_BLANK_TIME_75 | DRV260X_SAMP_TIME_250 | DRV260X_IDISS_TIME_75 },
> + { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ERM_OPEN_LOOP },
> + { DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
> +};
> +
> +static int drv260x_init(struct drv260x_data *haptics)
> +{
> + int ret;
> + unsigned int cal_buf;
> +
> + ret = regmap_write(haptics->regmap,
> + DRV260X_RATED_VOLT, haptics->rated_voltage);
> + if (ret != 0)
> + goto write_failure;
> +
> + ret = regmap_write(haptics->regmap,
> + DRV260X_OD_CLAMP_VOLT, haptics->overdrive_voltage);
> + if (ret != 0)
> + goto write_failure;
> +
> + switch(haptics->mode) {
> + case DRV260X_LRA_MODE:
> + ret = regmap_register_patch(haptics->regmap,
> + drv260x_lra_cal_regs,
> + ARRAY_SIZE(drv260x_lra_cal_regs));
> + if (ret != 0)
> + goto write_failure;
> + break;
> + case DRV260X_ERM_MODE:
> + ret = regmap_register_patch(haptics->regmap,
> + drv260x_erm_cal_regs,
> + ARRAY_SIZE(drv260x_erm_cal_regs));
> + if (ret != 0)
> + goto write_failure;
> +
> + ret = regmap_update_bits(haptics->regmap, DRV260X_LIB_SEL,
> + DRV260X_LIB_SEL_MASK,
> + haptics->library);
> + if (ret != 0)
> + goto write_failure;
> + break;
> + default:
> + ret = regmap_register_patch(haptics->regmap,
> + drv260x_lra_init_regs,
> + ARRAY_SIZE(drv260x_lra_init_regs));
> + if (ret != 0)
> + goto write_failure;
> +
> + ret = regmap_update_bits(haptics->regmap, DRV260X_LIB_SEL,
> + DRV260X_LIB_SEL_MASK,
> + haptics->library);
> + if (ret != 0)
> + goto write_failure;
> +
> + goto skip_go_bit;
> + break;
> + }
> +
> + if (ret != 0) {
> + dev_err(&haptics->client->dev,
> + "Failed to write init registers: %d\n",
> + ret);
> + goto write_failure;
> + }
> +
> + ret = regmap_write(haptics->regmap, DRV260X_GO, DRV260X_GO_BIT);
> + if (ret != 0)
> + goto write_failure;
> +
> + do {
> + ret = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
> + if (ret != 0)
> + goto write_failure;
> + } while (cal_buf == DRV260X_GO_BIT || ret != 0);
> +
> + return ret;
> +
> +write_failure:
> + dev_err(&haptics->client->dev,
> + "Failed to write init registers: %d\n",
> + ret);
> +skip_go_bit:
> + return ret;
> +}
> +
> +static const struct regmap_config drv260x_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = DRV260X_MAX_REG,
> + .reg_defaults = drv260x_reg_defs,
> + .num_reg_defaults = ARRAY_SIZE(drv260x_reg_defs),
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +#ifdef CONFIG_OF
> +static int drv260x_parse_dt(struct device_node *dev_node,
> + struct drv260x_data *haptics,
> + struct device *dev)
> +{
> + int ret;
> + int voltage;
> +
> + ret = of_property_read_u32(dev_node, "mode", &haptics->mode);
> + if (ret < 0) {
> + dev_err(dev, "%s: No entry for mode\n", __func__);
> +
> + return ret;
> + }
> + ret = of_property_read_u32(dev_node, "library-sel",
> + &haptics->library);
> + if (ret < 0) {
> + dev_err(dev, "%s: No entry for library selection\n",
> + __func__);
> +
> + return ret;
> + }
> + ret = of_property_read_u32(dev_node, "vib-rated-voltage",
> + &voltage);
> + if (!ret)
> + haptics->rated_voltage = drv260x_calculate_voltage(voltage);
> +
> +
> + ret = of_property_read_u32(dev_node, "vib-overdrive-voltage",
> + &voltage);
> + if (!ret)
> + haptics->overdrive_voltage = drv260x_calculate_voltage(voltage);
> +
> + return ret;
> +
> +}
> +#else
> +static inline int drv260x_parse_dt(struct device *dev)
> +{
> + dev_err(dev, "no platform data defined\n");
> +
> + return -EINVAL;
> +}
> +#endif
> +static int drv260x_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct drv260x_data *haptics;
> + struct device_node *np = client->dev.of_node;
> + struct drv260x_platform_data *pdata = dev_get_platdata(&client->dev);
> + int ret;
> +
> + haptics = devm_kzalloc(&client->dev, sizeof(*haptics), GFP_KERNEL);
> + if (!haptics)
> + return -ENOMEM;
> +
> + haptics->rated_voltage = DRV260X_DEF_OD_CLAMP_VOLT;
> + haptics->rated_voltage = DRV260X_DEF_RATED_VOLT;
> +
> + if (pdata) {
> + haptics->mode = pdata->mode;
> + haptics->library = pdata->library_selection;
> + if (pdata->vib_overdrive_voltage)
> + haptics->overdrive_voltage = drv260x_calculate_voltage(pdata->vib_overdrive_voltage);
> + if (pdata->vib_rated_voltage)
> + haptics->rated_voltage = drv260x_calculate_voltage(pdata->vib_rated_voltage);
> + } else if (np) {
> + ret = drv260x_parse_dt(np, haptics, &client->dev);
> + if (ret)
> + return ret;
> + } else {
> + dev_err(&client->dev, "Platform data not set\n");
> + return -ENODEV;
> + }
> +
> +
> + if (haptics->mode < DRV260X_LRA_MODE ||
> + haptics->mode > DRV260X_ERM_MODE) {
> + dev_err(&client->dev,
> + "Vibrator mode is invalid: %i\n",
> + haptics->mode);
> + return -EINVAL;
> + }
> +
> + if (haptics->library < DRV260X_LIB_SEL_DEFAULT ||
> + haptics->library > DRV260X_LIB_F) {
> + dev_err(&client->dev,
> + "Library value is invalid: %i\n", haptics->library);
> + return -EINVAL;
> + }
> +
> + haptics->regulator = devm_regulator_get(&client->dev, "vbat");
> + if (IS_ERR(haptics->regulator)) {
> + ret = PTR_ERR(haptics->regulator);
> + dev_err(&client->dev,
> + "unable to get regulator, error: %d\n", ret);
> + return ret;
> + }
> +
> + haptics->enable_gpio = devm_gpiod_get(&client->dev, "enable");
> + if (IS_ERR(haptics->enable_gpio)) {
> + ret = PTR_ERR(haptics->enable_gpio);
> + if (ret != -ENOENT && ret != -ENOSYS)
> + return ret;
> + haptics->enable_gpio = NULL;
> + } else {
> + gpiod_direction_output(haptics->enable_gpio, 1);
> + }
> +
> + haptics->input_dev = devm_input_allocate_device(&client->dev);
> + if (haptics->input_dev == NULL) {
> + dev_err(&client->dev, "Failed to allocate input device\n");
> + ret = -ENOMEM;
> + return ret;
> + }
> +
> + haptics->input_dev->name = "drv260x:haptics";
> + haptics->input_dev->dev.parent = client->dev.parent;
> + haptics->input_dev->close = drv260x_close;
> + input_set_drvdata(haptics->input_dev, haptics);
> + input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
> +
> + ret = input_ff_create_memless(haptics->input_dev, NULL,
> + drv260x_haptics_play);
> + if (ret < 0) {
> + dev_err(&client->dev, "input_ff_create() failed: %d\n",
> + ret);
> + return ret;
> + }
> +
> + INIT_WORK(&haptics->work, drv260x_worker);
> +
> + haptics->client = client;
> + i2c_set_clientdata(client, haptics);
> +
> + haptics->regmap = devm_regmap_init_i2c(client, &drv260x_regmap_config);
> + if (IS_ERR(haptics->regmap)) {
> + ret = PTR_ERR(haptics->regmap);
> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = drv260x_init(haptics);
> + if (ret < 0) {
> + dev_err(&client->dev, "Device init failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = input_register_device(haptics->input_dev);
> + if (ret < 0) {
> + dev_err(&client->dev, "couldn't register input device: %d\n",
> + ret);
> + return ret;
> + }
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int drv260x_suspend(struct device *dev)
> +{
> + struct drv260x_data *haptics = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + mutex_lock(&haptics->input_dev->mutex);
> +
> + if (haptics->input_dev->users) {
> + ret = regmap_update_bits(haptics->regmap,
> + DRV260X_MODE,
> + DRV260X_STANDBY_MASK,
> + DRV260X_STANDBY);
> + if (ret) {
> + dev_err(dev, "Failed to set standby mode\n");
> + goto out;
> + }
> +
> + gpiod_set_value(haptics->enable_gpio, 0);
> +
> + ret = regulator_disable(haptics->regulator);
> + if (ret)
> + dev_err(dev, "Failed to disable regulator\n");
> + }
> +out:
> + mutex_unlock(&haptics->input_dev->mutex);
> + return ret;
> +}
> +
> +static int drv260x_resume(struct device *dev)
> +{
> + struct drv260x_data *haptics = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + mutex_lock(&haptics->input_dev->mutex);
> +
> + if (haptics->input_dev->users) {
> + ret = regulator_enable(haptics->regulator);
> + if (ret) {
> + dev_err(dev, "Failed to enable regulator\n");
> + goto out;
> + }
> + ret = regmap_update_bits(haptics->regmap,
> + DRV260X_MODE,
> + DRV260X_STANDBY_MASK, 0);
> + if (ret) {
> + dev_err(dev, "Failed to unset standby mode\n");
> + goto out;
> + }
> +
> + gpiod_set_value(haptics->enable_gpio, 1);
> + }
> +
> +out:
> + mutex_unlock(&haptics->input_dev->mutex);
> + return ret;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(drv260x_pm_ops, drv260x_suspend, drv260x_resume);
> +
> +static const struct i2c_device_id drv260x_id[] = {
> + { "drv2605l", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, drv260x_id);
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id drv260x_of_match[] = {
> + { .compatible = "ti,drv2604", },
> + { .compatible = "ti,drv2604l", },
> + { .compatible = "ti,drv2605", },
> + { .compatible = "ti,drv2605l", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, drv260x_of_match);
> +#endif
> +
> +static struct i2c_driver drv260x_driver = {
> + .probe = drv260x_probe,
> + .driver = {
> + .name = "drv260x-haptics",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(drv260x_of_match),
> + .pm = &drv260x_pm_ops,
> + },
> + .id_table = drv260x_id,
> +};
> +module_i2c_driver(drv260x_driver);
> +
> +MODULE_ALIAS("platform:drv260x-haptics");
> +MODULE_DESCRIPTION("TI DRV260x haptics driver");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
> diff --git a/include/dt-bindings/input/ti-drv260x.h b/include/dt-bindings/input/ti-drv260x.h
> new file mode 100644
> index 0000000..be7f245
> --- /dev/null
> +++ b/include/dt-bindings/input/ti-drv260x.h
> @@ -0,0 +1,35 @@
> +/*
> + * DRV260X haptics driver family
> + *
> + * Author: Dan Murphy <dmurphy@ti.com>
> + *
> + * Copyright: (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _DT_BINDINGS_TI_DRV260X_H
> +#define _DT_BINDINGS_TI_DRV260X_H
> +
> +/* Calibration Types */
> +#define DRV260X_LRA_MODE 0x00
> +#define DRV260X_LRA_NO_CAL_MODE 0x01
> +#define DRV260X_ERM_MODE 0x02
> +
> +/* Library Selection */
> +#define DRV260X_LIB_SEL_DEFAULT 0x00
> +#define DRV260X_LIB_A 0x01
> +#define DRV260X_LIB_B 0x02
> +#define DRV260X_LIB_C 0x03
> +#define DRV260X_LIB_D 0x04
> +#define DRV260X_LIB_E 0x05
> +#define DRV260X_LIB_F 0x06
> +
> +#endif
> diff --git a/include/linux/platform_data/drv260x-pdata.h b/include/linux/platform_data/drv260x-pdata.h
> new file mode 100644
> index 0000000..4091a9b
> --- /dev/null
> +++ b/include/linux/platform_data/drv260x-pdata.h
> @@ -0,0 +1,29 @@
> +/*
> + * Platform data for DRV260X haptics driver family
> + *
> + * Author: Dan Murphy <dmurphy@ti.com>
> + *
> + * Copyright: (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef _LINUX_DRV260X_PDATA_H
> +#define _LINUX_DRV260X_PDATA_H
> +
> +struct drv260x_platform_data {
> + int enable_gpio;
> + u32 library_selection;
> + u32 mode;
> + u32 vib_rated_voltage;
> + u32 vib_overdrive_voltage;
> +};
> +
> +#endif
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: TSC2004 driver
From: Dmitry Torokhov @ 2014-08-06 19:37 UTC (permalink / raw)
To: Michael Welling; +Cc: linux-omap, linux-input, hvaibhav
In-Reply-To: <20140805170640.GA8830@sysresccd>
Hi Michael,
On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote:
> The TSC2004 driver has yet to appear in the mainline kernel. We have
> been using the driver referenced here as provided by TI:
>
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html
>
> Are there any plans of supporting this device in the mainline kernel?
I still believe that support for TSC2004 should be added 5to tsc2007, they are
too much alike to be separate drivers.
>
> Mysteriously a device tree entry was found in the following file:
> arch/arm/boot/dts/omap4-var-som-om44.dtsi
>
> This is obviously pointing to an out of tree driver that is not easily
> obtained.
>
> Suggestions?
Thanks.
--
Dmitry
^ permalink raw reply
* Hi
From: KM @ 2014-08-06 5:19 UTC (permalink / raw)
To: linux-input
Can I talk to you, I will be very glad if you permit me to talk to you for an important deal.
Regards,
KM.
^ permalink raw reply
* Re: [RFC RESEND 5/5] Input: evdev - add new EVIOCGABSRANGE ioctl
From: Peter Hutterer @ 2014-08-06 1:35 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-input, Dmitry Torokhov, Dmitry Torokhov
In-Reply-To: <1405775445-4454-6-git-send-email-dh.herrmann@gmail.com>
sorry for the late comments, not sure how that slipped through but it hadn't
shown up in my inbox unil Benjamin poked me.
On Sat, Jul 19, 2014 at 03:10:45PM +0200, David Herrmann wrote:
> When we introduced the slotted MT ABS extensions, we didn't take care to
> make SYN_DROPPED recoverable. Imagine a client recevies a SYN_DROPPED and
> syncs its current state via EVIOCGABS. It has to call this ioctl for each
> and every ABS code separately. Besides being horribly slow, this series
> of ioctl-calls is not atomic. The kernel might queue new ABS events while
> the client fetches the data.
>
> Now for normal ABS codes this is negligible as ABS values provide absolute
> data. That is, there is usually no need to resync ABS codes as we don't
> need previous values to interpret the next ABS code. Furthermore, most ABS
> codes are also sent pretty frequently so a refresh is usually useless.
>
> However, with the introduction of slotted ABS axes we added a relative
> component: ABS_MT_SLOT. If a client syncs all ABS codes via EVIOCGABS
> while the kernel has ABS-events and an ABS_MT_SLOT event queued, the
> client will think any read ABS-event is for the retrieved SLOT, however,
> this is not true as all events until the next ABS_MT_SLOT event are for
> the previously active slot:
>
> Kernel queue is: { ABS_DROPPED,
shouldn't this be SYN_DROPPED?
> ABS_MT_POSITION_X(slot: 0),
> ABS_MT_SLOT(slot: 1),
> ABS_MT_POSITION_X(slot: 1) }
> Client reads ABS_DROPPED from queue.
here too
> Client syncs all ABS values:
> As part of that, client syncs ABS_MT_SLOT, which is 1 in the current
> view of the kernel.
> Client reads ABS_MT_POSITION_X and attributes it to slot 1 instead of
> slot 0, as the slot-value is not explicit.
>
> This is just a simple example how the relative information provided by the
> ABS_MT_SLOT axis can be problematic to clients.
>
> Now there are many ways to fix this:
> * Make ABS_MT_SLOT a per-evdev-client attribute. On each
> EVIOCGABS(ABS_MT_SLOT) we can add fake ABS_MT_SLOT events to the queue.
> => Ugly and overkill
> * Flush all ABS events when clients read ABS_MT_SLOT.
> => Ugly hack and client might loose important ABS_MT_* events
> * Provide atomic EVIOCGABS API.
> => Sounds good!
>
> This patch introduces EVIOCGABSRANGE. Unlike EVIOCGABS, this ioctl only
> fetches ABS values, rather than the whole "struct input_absinfo" set.
> However, the new ioctl can fetch a range of ABS axes atomically and will
> flush matching events from the client's receive queue. Moreover, you can
> fetch all axes for *all* slots with a single call.
>
> This way, a client can simply run EVIOCGABSRANGE(0, ABS_CNT) and it will
> receive a consistent view of the whole ABS state, while the kernel flushes
> the receive-buffer for a consistent view.
> While most clients probably only need
> EVIOCGABSRANGE(ABS_MT_SLOT, ABS_MT_TOOL_y - ABS_MT_SLOT + 1), the ioctl
> allows to receive an arbitrary range of axes.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> drivers/input/evdev.c | 180 ++++++++++++++++++++++++++++++++++++++++++++-
> include/uapi/linux/input.h | 44 ++++++++++-
> 2 files changed, 219 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 6386882..7a25a7a 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -175,8 +175,9 @@ static bool __evdev_is_filtered(struct evdev_client *client,
> return mask && !test_bit(code, mask);
> }
>
> -/* flush queued events of type @type, caller must hold client->buffer_lock */
> -static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
> +/* flush queued, matching events, caller must hold client->buffer_lock */
> +static void __evdev_flush_queue(struct evdev_client *client, unsigned int type,
> + unsigned int code_first, unsigned int code_last)
> {
> unsigned int i, head, num;
> unsigned int mask = client->bufsize - 1;
> @@ -195,7 +196,9 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
> ev = &client->buffer[i];
> is_report = ev->type == EV_SYN && ev->code == SYN_REPORT;
>
> - if (ev->type == type) {
> + if (ev->type == type &&
> + ev->code >= code_first &&
> + ev->code <= code_last) {
> /* drop matched entry */
> continue;
> } else if (is_report && !num) {
> @@ -786,6 +789,172 @@ static int handle_eviocgbit(struct input_dev *dev,
> return bits_to_user(bits, len, size, p, compat_mode);
> }
>
> +static inline void free_absrange(s32 **pages, size_t page_cnt)
> +{
> + if (page_cnt > 1) {
> + while (page_cnt > 0) {
> + if (!pages[--page_cnt])
> + break;
> + __free_page(virt_to_page(pages[page_cnt]));
> + }
> + kfree(pages);
> + } else if (page_cnt == 1) {
> + kfree(pages);
> + }
> +}
> +
> +static inline s32 *absrange_ptr(s32 **pages, size_t page_cnt, size_t slots,
> + size_t i_code, size_t j_slot)
> +{
> + size_t idx, off;
> +
> + idx = (i_code * slots + j_slot) / (PAGE_SIZE / sizeof(s32));
> + off = (i_code * slots + j_slot) % (PAGE_SIZE / sizeof(s32));
> +
> + if (page_cnt == 1)
> + return &((s32*)pages)[off];
> + else
> + return &pages[idx][off];
> +}
> +
> +static inline ssize_t fetch_absrange(struct evdev_client *client,
> + struct input_dev *dev, size_t start,
> + size_t count, size_t slots, s32 ***out)
> +{
> + size_t size, page_cnt, i, j;
> + unsigned long flags;
> + s32 **pages;
> +
> + /*
> + * Fetch data atomically from the device and flush buffers. We need to
> + * allocate a temporary buffer as copy_to_user() is not allowed while
> + * holding spinlocks. However, to-be-copied data might be huge and
> + * high-order allocations should be avoided. Therefore, do the
> + * page-allocation manually.
> + */
> +
> + BUILD_BUG_ON(PAGE_SIZE % sizeof(s32) != 0);
> +
> + size = sizeof(s32) * count * slots;
> + page_cnt = DIV_ROUND_UP(size, PAGE_SIZE);
> + if (page_cnt < 1) {
> + return 0;
> + } else if (page_cnt == 1) {
> + pages = kzalloc(size, GFP_TEMPORARY);
> + if (!pages)
> + return -ENOMEM;
> + } else {
> + pages = kzalloc(sizeof(*pages) * page_cnt, GFP_TEMPORARY);
> + if (!pages)
> + return -ENOMEM;
> +
> + for (i = 0; i < page_cnt; ++i) {
> + pages[i] = (void*)get_zeroed_page(GFP_TEMPORARY);
> + if (!pages[i]) {
> + free_absrange(pages, page_cnt);
> + return -ENOMEM;
> + }
> + }
> + }
> +
> + spin_lock_irqsave(&dev->event_lock, flags);
> + spin_lock(&client->buffer_lock);
> +
> + for (i = 0; i < count; ++i) {
> + __u16 code;
> + bool is_mt;
> +
> + code = start + i;
> + is_mt = input_is_mt_value(code);
> + if (is_mt && !dev->mt)
> + continue;
> +
> + for (j = 0; j < slots; ++j) {
> + __s32 v;
> +
> + if (is_mt)
> + v = input_mt_get_value(&dev->mt->slots[j],
> + code);
> + else
> + v = dev->absinfo[code].value;
> +
> + *absrange_ptr(pages, page_cnt, slots, i, j) = v;
> +
> + if (!is_mt)
> + break;
> + }
> + }
> +
> + spin_unlock(&client->buffer_lock);
> + __evdev_flush_queue(client, EV_ABS, start, start + count - 1);
> + spin_unlock_irqrestore(&dev->event_lock, flags);
> +
> + *out = pages;
> + return page_cnt;
> +}
> +
> +static int evdev_handle_get_absrange(struct evdev_client *client,
> + struct input_dev *dev,
> + struct input_absrange __user *p)
> +{
> + size_t slots, code, count, i, j;
> + struct input_absrange absbuf;
> + s32 **vals = NULL;
> + ssize_t val_cnt;
> + s32 __user *b;
> + int retval;
> +
> + if (!dev->absinfo)
> + return -EINVAL;
> + if (copy_from_user(&absbuf, p, sizeof(absbuf)))
> + return -EFAULT;
> +
> + slots = min_t(size_t, dev->mt ? dev->mt->num_slots : 1, absbuf.slots);
> + code = min_t(size_t, absbuf.code, ABS_CNT);
> + count = min_t(size_t, absbuf.count, ABS_CNT);
> +
> + /* first fetch data atomically from device */
> +
> + if (code + count > ABS_CNT)
> + count = ABS_CNT - code;
> +
> + if (!slots || !count) {
> + val_cnt = 0;
> + } else {
> + val_cnt = fetch_absrange(client, dev, code, count,
> + slots, &vals);
> + if (val_cnt < 0)
> + return val_cnt;
> + }
> +
> + /* now copy data to user-space */
> +
> + b = (void __user*)(unsigned long)absbuf.buffer;
> + for (i = 0; i < absbuf.count; ++i) {
> + for (j = 0; j < absbuf.slots; ++j, ++b) {
> + s32 v;
> +
> + if (i >= count || j >= slots)
> + v = 0;
> + else
> + v = *absrange_ptr(vals, val_cnt, slots, i, j);
> +
> + if (put_user(v, b)) {
> + retval = -EFAULT;
> + goto out;
> + }
> + }
> + }
> +
> + retval = 0;
> +
> +out:
> + free_absrange(vals, val_cnt);
> + if (retval < 0)
> + evdev_queue_syn_dropped(client);
> + return retval;
> +}
> +
> static int evdev_handle_get_keycode(struct input_dev *dev, void __user *p)
> {
> struct input_keymap_entry ke = {
> @@ -889,7 +1058,7 @@ static int evdev_handle_get_val(struct evdev_client *client,
>
> spin_unlock(&dev->event_lock);
>
> - __evdev_flush_queue(client, type);
> + __evdev_flush_queue(client, type, 0, UINT_MAX);
>
> spin_unlock_irq(&client->buffer_lock);
>
> @@ -1006,6 +1175,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
> else
> return evdev_revoke(evdev, client, file);
>
> + case EVIOCGABSRANGE:
> + return evdev_handle_get_absrange(client, dev, p);
> +
> case EVIOCGMASK:
> if (copy_from_user(&mask, p, sizeof(mask)))
> return -EFAULT;
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index f6ace0e..9f851d4 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -32,7 +32,7 @@ struct input_event {
> * Protocol version.
> */
>
> -#define EV_VERSION 0x010001
> +#define EV_VERSION 0x010002
>
> /*
> * IOCTLs (0x00 - 0x7f)
> @@ -210,6 +210,48 @@ struct input_mask {
> */
> #define EVIOCSMASK _IOW('E', 0x93, struct input_mask) /* Set event-masks */
>
> +struct input_absrange {
> + __u16 slots;
> + __u16 code;
> + __u32 count;
> + __u64 buffer;
> +};
> +
> +/**
> + * EVIOCGABSRANGE - Fetch range of ABS values
> + *
> + * This fetches the current values of a range of ABS codes atomically. The range
> + * of codes to fetch and the buffer-types are passed as "struct input_absrange",
> + * which has the following fields:
> + * slots: Number of MT slots to fetch data for.
> + * code: First ABS axis to query.
> + * count: Number of ABS axes to query starting at @code.
> + * buffer: Pointer to a receive buffer where to store the fetched ABS
> + * values. This buffer must be an array of __s32 with at least
> + * (@slots * @code) elements. The buffer is interpreted as two
> + * dimensional __s32 array, declared as: __s32[slots][codes]
tbh this seems more complicated than necessary. Have you thought about
just dumping the events into the client buffer as if they came fresh in from
the device? So to sync, the client calls the ioctl with a buffer and a
buffer size, and the kernel simply writes a series of struct input_events
into that buffer, with ABS_MT_SLOT as required for all slots, (optionally?)
followed by a SYN_DROPPED. So the buffer afterwards could look like this:
EV_ABS ABS_X 30
EV_ABS ABS_X 1202
EV_ABS ABS_MT_SLOT 0
EV_ABS ABS_MT_POSITION_X 30
EV_ABS ABS_MT_POSITION_Y 1202
EV_ABS ABS_MT_SLOT 1
EV_ABS ABS_MT_POSITION_X 80
EV_ABS ABS_MT_POSITION_Y 1800
EV_SYN SYN_REPORT 0
the client can then go through and just process the events on-by-one as it
would otherwise with real events.
This approach could be even extended to include EV_KEY, etc. providing a
single ioctl to sync the whole state of the device atomically.
comments?
> + *
> + * Compared to EVIOCGABS this ioctl allows to retrieve a range of ABS codes
> + * atomically regarding any concurrent buffer modifications. Furthermore, any
> + * pending events for codes that were retrived via this call are flushed from
typo: retrieved
Cheers,
Peter
> + * the client's receive buffer. But unlike EVIOCGABS, this ioctl only returns
> + * the current value of an axis, rather than the whole "struct input_absinfo"
> + * set. All fields of "struct input_absinfo" except for the value are constant,
> + * though.
> + *
> + * The kernel's current view of the ABS axes is copied into the provided buffer.
> + * If an ABS axis is not enabled on the device, its value will be zero. Also, if
> + * an axis is not a slotted MT-axis, values for all but the first slot will be
> + * 0. If @slots is greater than the actual number of slots provided by the
> + * device, values for all slots higher than that will be 0.
> + *
> + * This call may fail with -EINVAL if the kernel doesn't support this call or
> + * the arguments are invalid, with -ENODEV if access was revoked, -ENOMEM if the
> + * kernel couldn't allocate temporary buffers for data-copy or -EFAULT if the
> + * passed pointer was invalid.
> + */
> +#define EVIOCGABSRANGE _IOR('E', 0x94, struct input_absrange)
> +
> #define EVIOCSCLOCKID _IOW('E', 0xa0, int) /* Set clockid to be used for timestamps */
>
> /*
> --
> 2.0.2
>
^ permalink raw reply
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Ping Cheng @ 2014-08-05 22:57 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <20140805213436.GC29591@mail.corp.redhat.com>
On Tue, Aug 5, 2014 at 2:34 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> Hi Ping,
>
> On Aug 05 2014 or thereabouts, Ping Cheng wrote:
>> Thank you Benjamin for updating the ABI docs. My comments are inline.
>>
>> With those lines updated, this patch is:
>>
>> Reviewed-by: Ping Cheng <pingc@wacom.com>
>
> Thanks!
>
>>
>> Cheers,
>>
>> Ping
>>
>> On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
>> <benjamin.tissoires@redhat.com> wrote:
>> > Now the devices show up under hid no matter the connection. So update the
>> > sysfs path to the shortest and common one.
>> > The ABI has also been unified regarding the OLEDs, but Bluetooth handle
>> > only 1-bit images instead of 4.
>> >
>> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> > ---
>> >
>> > Guys,
>> >
>> > by updating this and working on the g-s-d client side for OLEDs, I think now
>> > that we should also keep the oled*_img for Bluetooth and implement this file
>> > for USB too. The user space code gets messy quite fast due to the need to
>> > support old and new kernels, whereas if we handle the scrambling in the kernel,
>> > it should be quite straightforward.
>> > Of course, we have to keep the current button<n>_rawimg for backward
>> > compatibility.
>> >
>> > Any thoughts?
>> >
>> > Cheers,
>> > Benjamin
>> >
>> > Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
>> > 1 file changed, 20 insertions(+), 36 deletions(-)
>> >
>> > diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
>> > index 7fc7810..c75ed4c 100644
>> > --- a/Documentation/ABI/testing/sysfs-driver-wacom
>> > +++ b/Documentation/ABI/testing/sysfs-driver-wacom
>> > @@ -1,47 +1,26 @@
>> > -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
>> > -Date: June 2012
>> > -Contact: linux-bluetooth@vger.kernel.org
>> > -Description:
>> > - The /sys/class/hidraw/hidraw*/device/oled*_img files control
>> > - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
>> > - has to contain 256 bytes (64x32 px 1 bit colour). The format
>> > - is the same as PBM image 62x32px without header (64 bits per
>> > - horizontal line, 32 lines). An example of setting OLED No. 0:
>> > - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
>> > - The attribute is read only and no local copy of the image is
>> > - stored.
>> > -
>> > -What: /sys/class/hidraw/hidraw*/device/speed
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
>> > Date: April 2010
>>
>> Should the Date be updated?
>
> I don't think that this one should. The ABI is the same since April
> 2010, and the "new" path works also for older kernels. So basically,
> here, for Bluetooth, there has been no changes.
Oh, I see your point. But, don't we consider path part of the interface?
Cheers,
Ping
>>
>> > Kernel Version: 2.6.35
>>
>> This patch is planned for 3.16, right?
>
> Same comment than before (about not touching it).
> This will be planned for 3.17, 3.16 has been out last Sunday.
>
>>
>> > Contact: linux-bluetooth@vger.kernel.org
>> > Description:
>> > - The /sys/class/hidraw/hidraw*/device/speed file controls
>> > - reporting speed of Wacom bluetooth tablet. Reading from
>> > - this file returns 1 if tablet reports in high speed mode
>> > + The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
>> > + controls reporting speed of Wacom bluetooth tablet. Reading
>> > + from this file returns 1 if tablet reports in high speed mode
>> > or 0 otherwise. Writing to this file one of these values
>> > switches reporting speed.
>> >
>> > -What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
>> > -Date: May 2012
>> > -Kernel Version: 3.5
>> > -Contact: linux-bluetooth@vger.kernel.org
>> > -Description:
>> > - LED selector for Intuos4 WL. There are 4 leds, but only one LED
>> > - can be lit at a time. Max brightness is 127.
>> > -
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
>> > Date: August 2011
>>
>> Same here and other 6 dates below
>
> We can probably update these dates. I let them untouched because the
> ABI did not changed but only the path did.
>
>>
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > Attribute group for control of the status LEDs and the OLEDs.
>> > This attribute group is only available for Intuos 4 M, L,
>> > - and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
>> > - 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
>> > - implicitly signifies the presence of said LEDs and OLEDs on the
>> > - tablet device.
>> > + and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
>> > + Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
>> > + (LEDs only). Therefore its presence implicitly signifies the
>> > + presence of said LEDs and OLEDs on the tablet device.
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
>> > Date: August 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > @@ -50,7 +29,7 @@ Description:
>> > button is pressed on the stylus. This luminance level is
>> > normally lower than the level when a button is pressed.
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
>> > Date: August 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > @@ -58,7 +37,7 @@ Description:
>> > when the stylus touches the tablet surface, or any button is
>> > pressed on the stylus.
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
>> > Date: August 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > @@ -67,7 +46,7 @@ Description:
>> > 24HD) status LEDs is active (0..3). The other three LEDs on the
>> > same side are always inactive.
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
>> > Date: September 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > @@ -75,14 +54,14 @@ Description:
>> > and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
>> > the left are always inactive.
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
>> > Date: August 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > Writing to this file sets the overall luminance level (0..15)
>>
>> We need to specify that this ABI is only for Intuos 4 (USB and Bluetooth).
>
> Yep. We can carry this fix too in this patch.
>
> Cheers,
> Benjamin
>
>>
>> > of all eight button OLED displays.)
>> >
>> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
>> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
>> > Date: August 2011
>> > Contact: linux-input@vger.kernel.org
>> > Description:
>> > @@ -93,3 +72,8 @@ Description:
>> > byte chunk encodes the image data for two consecutive lines on
>> > the display. The low nibble of each byte contains the first
>> > line, and the high nibble contains the second line.
>> > + When the Wacom Intuos 4 is connected over Bluetooth, the
>> > + image has to contain 256 bytes (64x32 px 1 bit colour).
>> > + The format is also scrambled, like in the USB mode, and it can
>> > + be summarized by converting 76543210 into GECA6420.
>> > + HGFEDCBA HFDB7531
>> > --
>> > 2.0.4
>> >
^ permalink raw reply
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Benjamin Tissoires @ 2014-08-05 21:34 UTC (permalink / raw)
To: Ping Cheng
Cc: Dmitry Torokhov, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <CAF8JNhKQAZz_a-=5qyqS4rgdv-8Lr=i=uKJMwz_iR4c7cq-cvg@mail.gmail.com>
Hi Ping,
On Aug 05 2014 or thereabouts, Ping Cheng wrote:
> Thank you Benjamin for updating the ABI docs. My comments are inline.
>
> With those lines updated, this patch is:
>
> Reviewed-by: Ping Cheng <pingc@wacom.com>
Thanks!
>
> Cheers,
>
> Ping
>
> On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > Now the devices show up under hid no matter the connection. So update the
> > sysfs path to the shortest and common one.
> > The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> > only 1-bit images instead of 4.
> >
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >
> > Guys,
> >
> > by updating this and working on the g-s-d client side for OLEDs, I think now
> > that we should also keep the oled*_img for Bluetooth and implement this file
> > for USB too. The user space code gets messy quite fast due to the need to
> > support old and new kernels, whereas if we handle the scrambling in the kernel,
> > it should be quite straightforward.
> > Of course, we have to keep the current button<n>_rawimg for backward
> > compatibility.
> >
> > Any thoughts?
> >
> > Cheers,
> > Benjamin
> >
> > Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
> > 1 file changed, 20 insertions(+), 36 deletions(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
> > index 7fc7810..c75ed4c 100644
> > --- a/Documentation/ABI/testing/sysfs-driver-wacom
> > +++ b/Documentation/ABI/testing/sysfs-driver-wacom
> > @@ -1,47 +1,26 @@
> > -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
> > -Date: June 2012
> > -Contact: linux-bluetooth@vger.kernel.org
> > -Description:
> > - The /sys/class/hidraw/hidraw*/device/oled*_img files control
> > - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
> > - has to contain 256 bytes (64x32 px 1 bit colour). The format
> > - is the same as PBM image 62x32px without header (64 bits per
> > - horizontal line, 32 lines). An example of setting OLED No. 0:
> > - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
> > - The attribute is read only and no local copy of the image is
> > - stored.
> > -
> > -What: /sys/class/hidraw/hidraw*/device/speed
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
> > Date: April 2010
>
> Should the Date be updated?
I don't think that this one should. The ABI is the same since April
2010, and the "new" path works also for older kernels. So basically,
here, for Bluetooth, there has been no changes.
>
> > Kernel Version: 2.6.35
>
> This patch is planned for 3.16, right?
Same comment than before (about not touching it).
This will be planned for 3.17, 3.16 has been out last Sunday.
>
> > Contact: linux-bluetooth@vger.kernel.org
> > Description:
> > - The /sys/class/hidraw/hidraw*/device/speed file controls
> > - reporting speed of Wacom bluetooth tablet. Reading from
> > - this file returns 1 if tablet reports in high speed mode
> > + The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
> > + controls reporting speed of Wacom bluetooth tablet. Reading
> > + from this file returns 1 if tablet reports in high speed mode
> > or 0 otherwise. Writing to this file one of these values
> > switches reporting speed.
> >
> > -What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
> > -Date: May 2012
> > -Kernel Version: 3.5
> > -Contact: linux-bluetooth@vger.kernel.org
> > -Description:
> > - LED selector for Intuos4 WL. There are 4 leds, but only one LED
> > - can be lit at a time. Max brightness is 127.
> > -
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
> > Date: August 2011
>
> Same here and other 6 dates below
We can probably update these dates. I let them untouched because the
ABI did not changed but only the path did.
>
> > Contact: linux-input@vger.kernel.org
> > Description:
> > Attribute group for control of the status LEDs and the OLEDs.
> > This attribute group is only available for Intuos 4 M, L,
> > - and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
> > - 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
> > - implicitly signifies the presence of said LEDs and OLEDs on the
> > - tablet device.
> > + and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
> > + Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
> > + (LEDs only). Therefore its presence implicitly signifies the
> > + presence of said LEDs and OLEDs on the tablet device.
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
> > Date: August 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > @@ -50,7 +29,7 @@ Description:
> > button is pressed on the stylus. This luminance level is
> > normally lower than the level when a button is pressed.
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
> > Date: August 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > @@ -58,7 +37,7 @@ Description:
> > when the stylus touches the tablet surface, or any button is
> > pressed on the stylus.
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
> > Date: August 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > @@ -67,7 +46,7 @@ Description:
> > 24HD) status LEDs is active (0..3). The other three LEDs on the
> > same side are always inactive.
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
> > Date: September 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > @@ -75,14 +54,14 @@ Description:
> > and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
> > the left are always inactive.
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
> > Date: August 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > Writing to this file sets the overall luminance level (0..15)
>
> We need to specify that this ABI is only for Intuos 4 (USB and Bluetooth).
Yep. We can carry this fix too in this patch.
Cheers,
Benjamin
>
> > of all eight button OLED displays.)
> >
> > -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
> > +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
> > Date: August 2011
> > Contact: linux-input@vger.kernel.org
> > Description:
> > @@ -93,3 +72,8 @@ Description:
> > byte chunk encodes the image data for two consecutive lines on
> > the display. The low nibble of each byte contains the first
> > line, and the high nibble contains the second line.
> > + When the Wacom Intuos 4 is connected over Bluetooth, the
> > + image has to contain 256 bytes (64x32 px 1 bit colour).
> > + The format is also scrambled, like in the USB mode, and it can
> > + be summarized by converting 76543210 into GECA6420.
> > + HGFEDCBA HFDB7531
> > --
> > 2.0.4
> >
^ permalink raw reply
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Ping Cheng @ 2014-08-05 21:18 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Jason Gerecke, Przemo Firszt,
linux-kernel@vger.kernel.org, linux-input
In-Reply-To: <1407252899-10293-1-git-send-email-benjamin.tissoires@redhat.com>
Thank you Benjamin for updating the ABI docs. My comments are inline.
With those lines updated, this patch is:
Reviewed-by: Ping Cheng <pingc@wacom.com>
Cheers,
Ping
On Tue, Aug 5, 2014 at 8:34 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> Now the devices show up under hid no matter the connection. So update the
> sysfs path to the shortest and common one.
> The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> only 1-bit images instead of 4.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Guys,
>
> by updating this and working on the g-s-d client side for OLEDs, I think now
> that we should also keep the oled*_img for Bluetooth and implement this file
> for USB too. The user space code gets messy quite fast due to the need to
> support old and new kernels, whereas if we handle the scrambling in the kernel,
> it should be quite straightforward.
> Of course, we have to keep the current button<n>_rawimg for backward
> compatibility.
>
> Any thoughts?
>
> Cheers,
> Benjamin
>
> Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
> 1 file changed, 20 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
> index 7fc7810..c75ed4c 100644
> --- a/Documentation/ABI/testing/sysfs-driver-wacom
> +++ b/Documentation/ABI/testing/sysfs-driver-wacom
> @@ -1,47 +1,26 @@
> -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
> -Date: June 2012
> -Contact: linux-bluetooth@vger.kernel.org
> -Description:
> - The /sys/class/hidraw/hidraw*/device/oled*_img files control
> - OLED mocro displays on Intuos4 Wireless tablet. Accepted image
> - has to contain 256 bytes (64x32 px 1 bit colour). The format
> - is the same as PBM image 62x32px without header (64 bits per
> - horizontal line, 32 lines). An example of setting OLED No. 0:
> - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
> - The attribute is read only and no local copy of the image is
> - stored.
> -
> -What: /sys/class/hidraw/hidraw*/device/speed
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
> Date: April 2010
Should the Date be updated?
> Kernel Version: 2.6.35
This patch is planned for 3.16, right?
> Contact: linux-bluetooth@vger.kernel.org
> Description:
> - The /sys/class/hidraw/hidraw*/device/speed file controls
> - reporting speed of Wacom bluetooth tablet. Reading from
> - this file returns 1 if tablet reports in high speed mode
> + The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
> + controls reporting speed of Wacom bluetooth tablet. Reading
> + from this file returns 1 if tablet reports in high speed mode
> or 0 otherwise. Writing to this file one of these values
> switches reporting speed.
>
> -What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
> -Date: May 2012
> -Kernel Version: 3.5
> -Contact: linux-bluetooth@vger.kernel.org
> -Description:
> - LED selector for Intuos4 WL. There are 4 leds, but only one LED
> - can be lit at a time. Max brightness is 127.
> -
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
> Date: August 2011
Same here and other 6 dates below
> Contact: linux-input@vger.kernel.org
> Description:
> Attribute group for control of the status LEDs and the OLEDs.
> This attribute group is only available for Intuos 4 M, L,
> - and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
> - 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
> - implicitly signifies the presence of said LEDs and OLEDs on the
> - tablet device.
> + and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
> + Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
> + (LEDs only). Therefore its presence implicitly signifies the
> + presence of said LEDs and OLEDs on the tablet device.
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
> Date: August 2011
> Contact: linux-input@vger.kernel.org
> Description:
> @@ -50,7 +29,7 @@ Description:
> button is pressed on the stylus. This luminance level is
> normally lower than the level when a button is pressed.
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
> Date: August 2011
> Contact: linux-input@vger.kernel.org
> Description:
> @@ -58,7 +37,7 @@ Description:
> when the stylus touches the tablet surface, or any button is
> pressed on the stylus.
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
> Date: August 2011
> Contact: linux-input@vger.kernel.org
> Description:
> @@ -67,7 +46,7 @@ Description:
> 24HD) status LEDs is active (0..3). The other three LEDs on the
> same side are always inactive.
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
> Date: September 2011
> Contact: linux-input@vger.kernel.org
> Description:
> @@ -75,14 +54,14 @@ Description:
> and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
> the left are always inactive.
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
> Date: August 2011
> Contact: linux-input@vger.kernel.org
> Description:
> Writing to this file sets the overall luminance level (0..15)
We need to specify that this ABI is only for Intuos 4 (USB and Bluetooth).
> of all eight button OLED displays.)
>
> -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
> +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
> Date: August 2011
> Contact: linux-input@vger.kernel.org
> Description:
> @@ -93,3 +72,8 @@ Description:
> byte chunk encodes the image data for two consecutive lines on
> the display. The low nibble of each byte contains the first
> line, and the high nibble contains the second line.
> + When the Wacom Intuos 4 is connected over Bluetooth, the
> + image has to contain 256 bytes (64x32 px 1 bit colour).
> + The format is also scrambled, like in the USB mode, and it can
> + be summarized by converting 76543210 into GECA6420.
> + HGFEDCBA HFDB7531
> --
> 2.0.4
>
^ permalink raw reply
* TSC2004 driver
From: Michael Welling @ 2014-08-05 17:06 UTC (permalink / raw)
To: linux-omap, linux-input, hvaibhav
The TSC2004 driver has yet to appear in the mainline kernel. We have
been using the driver referenced here as provided by TI:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html
Are there any plans of supporting this device in the mainline kernel?
Mysteriously a device tree entry was found in the following file:
arch/arm/boot/dts/omap4-var-som-om44.dtsi
This is obviously pointing to an out of tree driver that is not easily
obtained.
Suggestions?
^ permalink raw reply
* Re: [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Przemo Firszt @ 2014-08-05 15:53 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
linux-kernel, linux-input
In-Reply-To: <1407252899-10293-1-git-send-email-benjamin.tissoires@redhat.com>
Quoting Benjamin Tissoires <benjamin.tissoires@redhat.com>:
> Now the devices show up under hid no matter the connection. So update the
> sysfs path to the shortest and common one.
> The ABI has also been unified regarding the OLEDs, but Bluetooth handle
> only 1-bit images instead of 4.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Guys,
>
> by updating this and working on the g-s-d client side for OLEDs, I think now
> that we should also keep the oled*_img for Bluetooth and implement this file
> for USB too. The user space code gets messy quite fast due to the need to
> support old and new kernels, whereas if we handle the scrambling in
> the kernel,
> it should be quite straightforward.
> Of course, we have to keep the current button<n>_rawimg for backward
> compatibility.
[..]
Hi Benjamin,
For whatever it's worth, you have my vote for scrambling for usb/bt in
the kernel.
I'm not sure about requirement for backward compatibility (the user space will
be broken anyway).
I proposed it a while ago [1]
[1] http://www.gossamer-threads.com/lists/linux/kernel/1593583
Regards,
Przemo Firszt
^ permalink raw reply
* [PATCH] Input - wacom: update the ABI doc according to latest changes
From: Benjamin Tissoires @ 2014-08-05 15:34 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
Przemo Firszt
Cc: linux-kernel, linux-input
Now the devices show up under hid no matter the connection. So update the
sysfs path to the shortest and common one.
The ABI has also been unified regarding the OLEDs, but Bluetooth handle
only 1-bit images instead of 4.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Guys,
by updating this and working on the g-s-d client side for OLEDs, I think now
that we should also keep the oled*_img for Bluetooth and implement this file
for USB too. The user space code gets messy quite fast due to the need to
support old and new kernels, whereas if we handle the scrambling in the kernel,
it should be quite straightforward.
Of course, we have to keep the current button<n>_rawimg for backward
compatibility.
Any thoughts?
Cheers,
Benjamin
Documentation/ABI/testing/sysfs-driver-wacom | 56 ++++++++++------------------
1 file changed, 20 insertions(+), 36 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
index 7fc7810..c75ed4c 100644
--- a/Documentation/ABI/testing/sysfs-driver-wacom
+++ b/Documentation/ABI/testing/sysfs-driver-wacom
@@ -1,47 +1,26 @@
-WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
-Date: June 2012
-Contact: linux-bluetooth@vger.kernel.org
-Description:
- The /sys/class/hidraw/hidraw*/device/oled*_img files control
- OLED mocro displays on Intuos4 Wireless tablet. Accepted image
- has to contain 256 bytes (64x32 px 1 bit colour). The format
- is the same as PBM image 62x32px without header (64 bits per
- horizontal line, 32 lines). An example of setting OLED No. 0:
- dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
- The attribute is read only and no local copy of the image is
- stored.
-
-What: /sys/class/hidraw/hidraw*/device/speed
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
Date: April 2010
Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org
Description:
- The /sys/class/hidraw/hidraw*/device/speed file controls
- reporting speed of Wacom bluetooth tablet. Reading from
- this file returns 1 if tablet reports in high speed mode
+ The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
+ controls reporting speed of Wacom bluetooth tablet. Reading
+ from this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values
switches reporting speed.
-What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
-Date: May 2012
-Kernel Version: 3.5
-Contact: linux-bluetooth@vger.kernel.org
-Description:
- LED selector for Intuos4 WL. There are 4 leds, but only one LED
- can be lit at a time. Max brightness is 127.
-
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L,
- and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
- 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
- implicitly signifies the presence of said LEDs and OLEDs on the
- tablet device.
+ and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
+ Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
+ (LEDs only). Therefore its presence implicitly signifies the
+ presence of said LEDs and OLEDs on the tablet device.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
@@ -50,7 +29,7 @@ Description:
button is pressed on the stylus. This luminance level is
normally lower than the level when a button is pressed.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
@@ -58,7 +37,7 @@ Description:
when the stylus touches the tablet surface, or any button is
pressed on the stylus.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
@@ -67,7 +46,7 @@ Description:
24HD) status LEDs is active (0..3). The other three LEDs on the
same side are always inactive.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
Date: September 2011
Contact: linux-input@vger.kernel.org
Description:
@@ -75,14 +54,14 @@ Description:
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the overall luminance level (0..15)
of all eight button OLED displays.
-What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
+What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
@@ -93,3 +72,8 @@ Description:
byte chunk encodes the image data for two consecutive lines on
the display. The low nibble of each byte contains the first
line, and the high nibble contains the second line.
+ When the Wacom Intuos 4 is connected over Bluetooth, the
+ image has to contain 256 bytes (64x32 px 1 bit colour).
+ The format is also scrambled, like in the USB mode, and it can
+ be summarized by converting 76543210 into GECA6420.
+ HGFEDCBA HFDB7531
--
2.0.4
^ permalink raw reply related
* [PATCH] Input - wacom: only register once the MODULE_* macros
From: Benjamin Tissoires @ 2014-08-05 15:08 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
Przemo Firszt
Cc: linux-kernel, linux-input
Putting the various MODULE_* makes them appear several times in modinfo
because wacom.h is used both in wacom_sys.c and wacom_wac.h.
Having the macros near the module declaration makes them appear only once.
Add also MODULE_VERSION(DRIVER_VERSION) to export the current version
number.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Dmitry,
I guess this one could sneak on top of your pull request too.
If not, then I'll push Jiri to take it in one of the future rc :)
Cheers,
Benjamin
drivers/hid/wacom.h | 4 ----
drivers/hid/wacom_sys.c | 5 +++++
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/wacom.h b/drivers/hid/wacom.h
index 8cc4406..64bc1b2 100644
--- a/drivers/hid/wacom.h
+++ b/drivers/hid/wacom.h
@@ -101,10 +101,6 @@
#define DRIVER_DESC "USB Wacom tablet driver"
#define DRIVER_LICENSE "GPL"
-MODULE_AUTHOR(DRIVER_AUTHOR);
-MODULE_DESCRIPTION(DRIVER_DESC);
-MODULE_LICENSE(DRIVER_LICENSE);
-
#define USB_VENDOR_ID_WACOM 0x056a
#define USB_VENDOR_ID_LENOVO 0x17ef
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 6e0c191..ff4ec50 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1437,6 +1437,11 @@ static int wacom_reset_resume(struct hid_device *hdev)
return wacom_resume(hdev);
}
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE(DRIVER_LICENSE);
+
static struct hid_driver wacom_driver = {
.name = "wacom",
.id_table = wacom_ids,
--
2.0.4
^ permalink raw reply related
* [PATCH v4] Input - wacom: add copyright note and bump version to 2.0
From: Benjamin Tissoires @ 2014-08-05 15:05 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Ping Cheng, Jason Gerecke,
Przemo Firszt
Cc: linux-kernel, linux-input
In-Reply-To: <1406659385-3256-7-git-send-email-benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Tested-by: Przemo Firszt <przemo@firszt.eu>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
changes in v4:
- also update the DRIVER_VERSION macro
Hi Dmitry,
if you could replace the v3 of this patch by this v4 in your pull request
to Linus, that would be better. Ping notified me about this last Friday, so I
kept her Rev-by.
Cheers,
Benjamin
drivers/hid/wacom.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom.h b/drivers/hid/wacom.h
index 0b89ee7..8cc4406 100644
--- a/drivers/hid/wacom.h
+++ b/drivers/hid/wacom.h
@@ -12,6 +12,7 @@
* Copyright (c) 2001 Frederic Lepied <flepied@mandrakesoft.com>
* Copyright (c) 2004 Panagiotis Issaris <panagiotis.issaris@mech.kuleuven.ac.be>
* Copyright (c) 2002-2011 Ping Cheng <pingc@wacom.com>
+ * Copyright (c) 2014 Benjamin Tissoires <benjamin.tissoires@redhat.com>
*
* ChangeLog:
* v0.1 (vp) - Initial release
@@ -72,6 +73,8 @@
* v1.52 (pc) - Query Wacom data upon system resume
* - add defines for features->type
* - add new devices (0x9F, 0xE2, and 0XE3)
+ * v2.00 (bt) - conversion to a HID driver
+ * - integration of the Bluetooth devices
*/
/*
@@ -93,7 +96,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v1.53"
+#define DRIVER_VERSION "v2.00"
#define DRIVER_AUTHOR "Vojtech Pavlik <vojtech@ucw.cz>"
#define DRIVER_DESC "USB Wacom tablet driver"
#define DRIVER_LICENSE "GPL"
--
2.0.4
^ permalink raw reply related
* [PATCH v2] input: Add ROHM BU21023/24 Dual touch support resistive touchscreens
From: Yoichi Yuasa @ 2014-08-04 11:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: yuasa, linux-input
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
---
drivers/input/touchscreen/Kconfig | 11 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/rohm_bu21023.c | 929 ++++++++++++++++++++++++++++++
drivers/input/touchscreen/rohm_bu21023.h | 258 +++++++++
4 files changed, 1199 insertions(+)
create mode 100644 drivers/input/touchscreen/rohm_bu21023.c
create mode 100644 drivers/input/touchscreen/rohm_bu21023.h
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 6bb9a7d..9ae5c88 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -950,4 +950,15 @@ config TOUCHSCREEN_ZFORCE
To compile this driver as a module, choose M here: the
module will be called zforce_ts.
+config TOUCHSCREEN_ROHM_BU21023
+ tristate "ROHM BU21023/24 Dual touch support resistive touchscreens"
+ depends on I2C
+ help
+ Say Y here if you have a touchscreen using ROHM BU21023/24.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bu21023_ts.
+
endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 4be94fc..af766d0 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) += usbtouchscreen.o
obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
+obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023) += rohm_bu21023.o
obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
obj-$(CONFIG_TOUCHSCREEN_STMPE) += stmpe-ts.o
diff --git a/drivers/input/touchscreen/rohm_bu21023.c b/drivers/input/touchscreen/rohm_bu21023.c
new file mode 100644
index 0000000..660b839
--- /dev/null
+++ b/drivers/input/touchscreen/rohm_bu21023.c
@@ -0,0 +1,929 @@
+/*
+ * ROHM BU21023/24 Dual touch support resistive touch screen driver
+ * Copyright (C) 2012 ROHM CO.,LTD.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/delay.h>
+#include <linux/firmware.h>
+#include <linux/hrtimer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include "rohm_bu21023.h"
+
+struct rohm_ts_data {
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+
+ bool initialized;
+
+ unsigned int untouch_count;
+ unsigned int single_touch_count;
+ unsigned int dual_touch_count;
+ unsigned int prev_touch_report;
+};
+
+/*
+ * rohm_i2c_burst_read - execute combined I2C message for ROHM BU21023/24
+ * @adap: Handle to I2C bus
+ * @msgs: combined messages to execute
+ * @num: Number of messages to be executed.
+ *
+ * Returns negative errno, else the number of messages executed.
+ *
+ * Note
+ * In BU21023/24 burst read, stop condition is needed after "address write".
+ * Therefore, transmission is performed in 2 steps.
+ */
+static inline int rohm_i2c_burst_read(struct i2c_adapter *adap,
+ struct i2c_msg *msgs, int num)
+{
+ int ret, i;
+
+ if (!adap->algo->master_xfer) {
+ dev_err(&adap->dev, "I2C level transfers not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ i2c_lock_adapter(adap);
+
+ for (i = 0; i < num; i++) {
+ ret = __i2c_transfer(adap, &msgs[i], 1);
+ if (ret < 0)
+ break;
+
+ ret = i;
+ }
+
+ i2c_unlock_adapter(adap);
+
+ return ret;
+}
+
+static int rohm_ts_manual_calibration(struct rohm_ts_data *ts)
+{
+ struct i2c_client *client = ts->client;
+ struct device *dev = &client->dev;
+ struct i2c_msg msg[2];
+ u8 buf[33];
+ u8 addr_buf; /* burst read start address */
+
+ int retry;
+ bool success = false;
+ bool first_time = true;
+ bool calibration_done;
+
+ u8 reg1, reg2, reg3;
+ s32 reg1_orig, reg2_orig, reg3_orig;
+ s32 val;
+
+ int calib_x = 0, calib_y = 0;
+ int reg_x, reg_y;
+ int err_x, err_y;
+
+ int err = 0, ret;
+ int i;
+
+ addr_buf = PRM1_X_H;
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = &addr_buf;
+
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = sizeof(buf);
+ msg[1].buf = buf;
+
+#define READ_CALIB_BUF(reg) ((u16)buf[((reg) - PRM1_X_H)])
+
+ reg1_orig = i2c_smbus_read_byte_data(client, CALIBRATION_REG1);
+ if (reg1_orig < 0)
+ return reg1_orig;
+
+ reg2_orig = i2c_smbus_read_byte_data(client, CALIBRATION_REG2);
+ if (reg2_orig < 0)
+ return reg2_orig;
+
+ reg3_orig = i2c_smbus_read_byte_data(client, CALIBRATION_REG3);
+ if (reg3_orig < 0)
+ return reg3_orig;
+
+ ret = i2c_smbus_write_byte_data(client, INT_MASK,
+ COORD_UPDATE | SLEEP_IN | SLEEP_OUT |
+ PROGRAM_LOAD_DONE);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, TEST1, DUALTOUCH_STABILIZE_ON);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ for (retry = 0; retry < CALIBRATION_RETRY_MAX; retry++) {
+ /* wait 2 sampling for update */
+ mdelay(2 * SAMPLING_DELAY);
+
+ ret = rohm_i2c_burst_read(client->adapter, msg, 2);
+ if (ret < 0) {
+ err = ret;
+ goto err_exit;
+ }
+
+ if (READ_CALIB_BUF(TOUCH) & TOUCH_DETECT)
+ continue;
+
+ if (first_time) {
+ /* generate calibration parameter */
+ calib_x =
+ (READ_CALIB_BUF(PRM1_X_H) << 2 |
+ READ_CALIB_BUF(PRM1_X_L)) - AXIS_OFFSET;
+ calib_y =
+ (READ_CALIB_BUF(PRM1_Y_H) << 2 |
+ READ_CALIB_BUF(PRM1_Y_L)) - AXIS_OFFSET;
+
+ ret = i2c_smbus_write_byte_data(client, TEST1,
+ DUALTOUCH_STABILIZE_ON |
+ DUALTOUCH_REG_ON);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ first_time = false;
+ } else {
+ /* generate adjustment parameter */
+ err_x = READ_CALIB_BUF(PRM1_X_H) << 2 |
+ READ_CALIB_BUF(PRM1_X_L);
+ err_y = READ_CALIB_BUF(PRM1_Y_H) << 2 |
+ READ_CALIB_BUF(PRM1_Y_L);
+
+ /* X axis ajust */
+ if (err_x <= 4)
+ calib_x -= AXIS_ADJUST;
+ else if (err_x >= 60)
+ calib_x += AXIS_ADJUST;
+
+ /* Y axis ajust */
+ if (err_y <= 4)
+ calib_y -= AXIS_ADJUST;
+ else if (err_y >= 60)
+ calib_y += AXIS_ADJUST;
+ }
+
+ /* generate calibration setting value */
+ reg_x = calib_x + ((calib_x & 0x200) << 1);
+ reg_y = calib_y + ((calib_y & 0x200) << 1);
+
+ /* convert for register format */
+ reg1 = reg_x >> 3;
+ reg2 = (reg_y & 0x7) << 4 | (reg_x & 0x7);
+ reg3 = reg_y >> 3;
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG1, reg1);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG2, reg2);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG3, reg3);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ /*
+ * force calibration sequcence
+ */
+ ret = i2c_smbus_write_byte_data(client, FORCE_CALIBRATION,
+ FORCE_CALIBRATION_OFF);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, FORCE_CALIBRATION,
+ FORCE_CALIBRATION_ON);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ /* clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ /*
+ * Wait for the status change of calibration, max 10 sampling
+ */
+ calibration_done = false;
+
+ for (i = 0; i < 10; i++) {
+ mdelay(SAMPLING_DELAY);
+
+ val = i2c_smbus_read_byte_data(client, TOUCH_GESTURE);
+ if (!(val & CALIBRATION_MASK)) {
+ calibration_done = true;
+ break;
+ } else if (val < 0) {
+ err = val;
+ goto err_exit;
+ }
+ }
+
+ if (calibration_done) {
+ val = i2c_smbus_read_byte_data(client, INT_STATUS);
+ if (val == CALIBRATION_DONE) {
+ success = true;
+ break;
+ } else if (val < 0) {
+ err = val;
+ goto err_exit;
+ }
+ } else
+ dev_warn(dev, "Calibration timeout\n");
+ }
+
+ if (!success) {
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG1,
+ reg1_orig);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG2,
+ reg2_orig);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG3,
+ reg3_orig);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ /* calibration data enable */
+ ret = i2c_smbus_write_byte_data(client, TEST1,
+ DUALTOUCH_STABILIZE_ON |
+ DUALTOUCH_REG_ON);
+ if (ret) {
+ err = ret;
+ goto err_exit;
+ }
+
+ /* wait 10 sampling */
+ mdelay(10 * SAMPLING_DELAY);
+
+ err = -EBUSY;
+ }
+
+err_exit:
+ ret = i2c_smbus_write_byte_data(client, INT_MASK, INT_ALL);
+ if (!ret)
+ /* Clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+
+ if (!err && ret)
+ err = ret;
+
+ return err;
+}
+
+static unsigned long inactive_polling_interval[2] = { 1, 0 };
+static unsigned long active_polling_interval[2] = { 0, 10000000 };
+
+module_param_array(inactive_polling_interval, ulong, NULL, S_IRUGO | S_IWUSR);
+module_param_array(active_polling_interval, ulong, NULL, S_IRUGO | S_IWUSR);
+
+MODULE_PARM_DESC(inactive_polling_interval,
+ "Polling interval for un-touch detection");
+MODULE_PARM_DESC(active_polling_interval,
+ "Polling interval for touch detection");
+
+#define INACTIVE_POLLING_INTERVAL_KTIME \
+ ktime_set(inactive_polling_interval[0], inactive_polling_interval[1])
+#define ACTIVE_POLLING_INTERVAL_KTIME \
+ ktime_set(active_polling_interval[0], active_polling_interval[1])
+
+static unsigned int untouch_threshold[3] = { 0, 1, 5 };
+static unsigned int single_touch_threshold[3] = { 0, 0, 4 };
+static unsigned int dual_touch_threshold[3] = { 10, 8, 0 };
+
+module_param_array(untouch_threshold, uint, NULL, S_IRUGO | S_IWUSR);
+module_param_array(single_touch_threshold, uint, NULL, S_IRUGO | S_IWUSR);
+module_param_array(dual_touch_threshold, uint, NULL, S_IRUGO | S_IWUSR);
+
+MODULE_PARM_DESC(untouch_threshold, "Thresholds for un-touch detection");
+MODULE_PARM_DESC(single_touch_threshold,
+ "Thresholds for single touch detection");
+MODULE_PARM_DESC(dual_touch_threshold, "Thresholds for dual touch detection");
+
+static irqreturn_t rohm_ts_soft_irq(int irq, void *dev_id)
+{
+ struct rohm_ts_data *ts = dev_id;
+ struct i2c_client *client = ts->client;
+ struct input_dev *input_dev = ts->input_dev;
+ struct device *dev = &client->dev;
+
+ struct i2c_msg msg[2];
+ u16 addr = client->addr;
+ u8 addr_buf;
+ u8 buf[10]; /* for 0x20-0x29 */
+
+ struct input_mt_pos pos[BU21023_MAX_SLOTS];
+ int slots[BU21023_MAX_SLOTS];
+ u8 touch_flags;
+ unsigned int threshold;
+ int touch_report = -1;
+ unsigned int prev_touch_report = ts->prev_touch_report;
+
+ s32 status;
+ int i, ret;
+
+ status = i2c_smbus_read_byte_data(client, INT_STATUS);
+ if (!status)
+ return IRQ_NONE;
+
+ if (status < 0)
+ return IRQ_HANDLED;
+
+ ret = i2c_smbus_write_byte_data(client, INT_MASK, INT_ALL);
+ if (ret)
+ return IRQ_HANDLED;
+
+ /* Clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+ if (ret)
+ return IRQ_HANDLED;
+
+ addr_buf = POS_X1_H;
+ msg[0].addr = addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = &addr_buf;
+
+ msg[1].addr = addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = sizeof(buf);
+ msg[1].buf = buf;
+
+#define READ_POS_BUF(reg) ((u16)buf[((reg) - POS_X1_H)])
+
+ ret = rohm_i2c_burst_read(client->adapter, msg, 2);
+ if (ret < 0)
+ return IRQ_HANDLED;
+
+ touch_flags = READ_POS_BUF(TOUCH_GESTURE) & TOUCH_MASK;
+ if (touch_flags) {
+ /* generate coordinates */
+ pos[0].x = (READ_POS_BUF(POS_X1_H) << 2) |
+ READ_POS_BUF(POS_X1_L);
+ pos[0].y = (READ_POS_BUF(POS_Y1_H) << 2) |
+ READ_POS_BUF(POS_Y1_L);
+ pos[1].x = (READ_POS_BUF(POS_X2_H) << 2) |
+ READ_POS_BUF(POS_X2_L);
+ pos[1].y = (READ_POS_BUF(POS_Y2_H) << 2) |
+ READ_POS_BUF(POS_Y2_L);
+
+ switch (touch_flags) {
+ case SINGLE_TOUCH:
+ ts->untouch_count = 0;
+ ts->single_touch_count++;
+ ts->dual_touch_count = 0;
+
+ threshold = single_touch_threshold[prev_touch_report];
+ if (ts->single_touch_count > threshold)
+ touch_report = 1;
+
+ if (touch_report == 1) {
+ if (pos[1].x != 0 && pos[1].y != 0) {
+ pos[0].x = pos[1].x;
+ pos[0].y = pos[1].y;
+ pos[1].x = 0;
+ pos[1].y = 0;
+ }
+ }
+ break;
+ case DUAL_TOUCH:
+ ts->untouch_count = 0;
+ ts->single_touch_count = 0;
+ ts->dual_touch_count++;
+
+ threshold = dual_touch_threshold[prev_touch_report];
+ if (ts->dual_touch_count > threshold)
+ touch_report = 2;
+ break;
+ default:
+ dev_err(dev,
+ "Three or more touches are not supported\n");
+ return IRQ_HANDLED;
+ break;
+ }
+ } else {
+ ts->untouch_count++;
+
+ threshold = untouch_threshold[prev_touch_report];
+ if (ts->untouch_count > threshold) {
+ ts->untouch_count = 0;
+ ts->single_touch_count = 0;
+ ts->dual_touch_count = 0;
+
+ touch_report = 0;
+ }
+ }
+
+ input_mt_assign_slots(input_dev, slots, pos, touch_report);
+
+ for (i = 0; i < touch_report; i++) {
+ input_mt_slot(input_dev, slots[i]);
+ input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, true);
+ input_report_abs(input_dev, ABS_MT_POSITION_X, pos[i].x);
+ input_report_abs(input_dev, ABS_MT_POSITION_Y, pos[i].y);
+ }
+
+ input_mt_sync_frame(input_dev);
+ input_mt_report_pointer_emulation(input_dev, true);
+ input_sync(input_dev);
+
+ if (READ_POS_BUF(TOUCH_GESTURE) & CALIBRATION_REQUEST) {
+ if (rohm_ts_manual_calibration(ts) < 0)
+ dev_warn(dev, "Failed to manual calibration\n");
+ }
+
+
+ i2c_smbus_write_byte_data(client, INT_MASK,
+ CALIBRATION_DONE | SLEEP_OUT | SLEEP_IN |
+ PROGRAM_LOAD_DONE);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t rohm_ts_hard_irq(int irq, void *dev_id)
+{
+ return IRQ_WAKE_THREAD;
+}
+
+static int rohm_ts_load_firmware(struct i2c_client *client,
+ const char *firmware_name)
+{
+ struct device *dev = &client->dev;
+ const struct firmware *firmware = NULL;
+ s32 status;
+ int blocks, remainder, retry = 0, offset;
+ int err = 0, ret;
+ int i;
+
+ ret = request_firmware(&firmware, firmware_name, dev);
+ if (ret) {
+ dev_err(dev, "Unable to open firmware %s\n", firmware_name);
+ return ret;
+ }
+
+ blocks = firmware->size / FIRMWARE_BLOCK_SIZE;
+ remainder = firmware->size % FIRMWARE_BLOCK_SIZE;
+
+ ret = i2c_smbus_write_byte_data(client, INT_MASK,
+ COORD_UPDATE | CALIBRATION_DONE |
+ SLEEP_IN | SLEEP_OUT);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ while (retry < FIRMWARE_RETRY_MAX) {
+ ret = i2c_smbus_write_byte_data(client, COMMON_SETUP1,
+ COMMON_SETUP1_DEFAULT);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, EX_ADDR_H, 0);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ ret = i2c_smbus_write_byte_data(client, EX_ADDR_L, 0);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ offset = 0;
+
+ /* firmware load to the device */
+ for (i = 0; i < blocks; i++) {
+ ret = i2c_smbus_write_i2c_block_data(client, EX_WDAT,
+ FIRMWARE_BLOCK_SIZE, &firmware->data[offset]);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ offset += FIRMWARE_BLOCK_SIZE;
+ }
+
+ if (remainder) {
+ ret = i2c_smbus_write_i2c_block_data(client, EX_WDAT,
+ remainder, &firmware->data[offset]);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+ }
+
+ /* check formware load result */
+ status = i2c_smbus_read_byte_data(client, INT_STATUS);
+ if (status < 0) {
+ err = status;
+ goto err_int_mask_exit;
+ }
+
+ /* clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ if (status == PROGRAM_LOAD_DONE)
+ break;
+
+ /* settings for retry */
+ ret = i2c_smbus_write_byte_data(client, EX_WDAT, 0);
+ if (ret) {
+ err = ret;
+ goto err_int_mask_exit;
+ }
+
+ retry++;
+ dev_warn(dev, "Retry firmware load\n");
+ }
+
+err_int_mask_exit:
+ ret = i2c_smbus_write_byte_data(client, INT_MASK, INT_ALL);
+ if (ret)
+ err = ret;
+
+ release_firmware(firmware);
+
+ if (retry >= FIRMWARE_RETRY_MAX)
+ return -EBUSY;
+
+ return err;
+}
+
+static bool swap_xy;
+module_param(swap_xy, bool, S_IRUGO);
+MODULE_PARM_DESC(swap_xy, "Swap X-axis and Y-axis");
+
+static bool inv_x;
+module_param(inv_x, bool, S_IRUGO);
+MODULE_PARM_DESC(inv_x, "Invert X-axis");
+
+static bool inv_y;
+module_param(inv_y, bool, S_IRUGO);
+MODULE_PARM_DESC(inv_y, "Invert Y-axis");
+
+static int rohm_ts_device_init(struct rohm_ts_data *ts)
+{
+ struct i2c_client *client = ts->client;
+ struct device *dev = &client->dev;
+ u8 val;
+ int ret;
+
+ /*
+ * Wait 200usec for reset
+ */
+ udelay(200);
+
+ /* Release analog reset */
+ ret = i2c_smbus_write_byte_data(client, SYSTEM, ANALOG_POWER_ON);
+ if (ret)
+ return ret;
+
+ /* Waiting for the analog warm-up, max. 200usec */
+ udelay(200);
+
+ /* clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+ if (ret)
+ return ret;
+
+ val = MAF_1SAMPLE;
+ if (swap_xy)
+ val |= SWAP_XY;
+ if (inv_x)
+ val |= INV_X;
+ if (inv_y)
+ val |= INV_Y;
+
+ ret = i2c_smbus_write_byte_data(client, EX_WDAT, 0);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, COMMON_SETUP1, 0);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, COMMON_SETUP2, val);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, COMMON_SETUP3,
+ SEL_TBL_DEFAULT | EN_MULTI);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, THRESHOLD_GESTURE,
+ THRESHOLD_GESTURE_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, INTERVAL_TIME,
+ INTERVAL_TIME_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, CPU_FREQ, CPU_FREQ_10MHZ);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, PRM_SWOFF_TIME,
+ PRM_SWOFF_TIME_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, ADC_CTRL, ADC_DIV_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, ADC_WAIT, ADC_WAIT_DEFAULT);
+ if (ret)
+ return ret;
+
+ /*
+ * Panel setup, these values change with the panel.
+ */
+ ret = i2c_smbus_write_byte_data(client, STEP_X, STEP_X_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, STEP_Y, STEP_Y_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OFFSET_X, OFFSET_X_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, OFFSET_Y, OFFSET_Y_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, THRESHOLD_TOUCH,
+ THRESHOLD_TOUCH_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, EVR_XY, EVR_XY_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, EVR_X, EVR_X_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, EVR_Y, EVR_Y_DEFAULT);
+ if (ret)
+ return ret;
+
+ /* Fixed value settings */
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_ADJUST,
+ CALIBRATION_ADJUST_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, SWCONT, SWCONT_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, TEST1,
+ DUALTOUCH_STABILIZE_ON |
+ DUALTOUCH_REG_ON);
+ if (ret)
+ return ret;
+
+ ret = rohm_ts_load_firmware(client, BU21023_FIRMWARE_NAME);
+ if (ret) {
+ dev_err(dev, "Failed to firmware load\n");
+ return ret;
+ }
+
+ /*
+ * Manual calibration results are not changed in same environment.
+ * If the force calibration is performed,
+ * the controller will not require calibration request interrupt
+ * when the typical values are set to the calibration registers.
+ */
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG1,
+ CALIBRATION_REG1_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG2,
+ CALIBRATION_REG2_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, CALIBRATION_REG3,
+ CALIBRATION_REG3_DEFAULT);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, FORCE_CALIBRATION,
+ FORCE_CALIBRATION_OFF);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, FORCE_CALIBRATION,
+ FORCE_CALIBRATION_ON);
+ if (ret)
+ return ret;
+
+ /* Clear all interrupts */
+ ret = i2c_smbus_write_byte_data(client, INT_CLEAR, 0xff);
+ if (ret)
+ return ret;
+
+ ret = devm_request_threaded_irq(dev, client->irq, rohm_ts_hard_irq,
+ rohm_ts_soft_irq, IRQF_TRIGGER_FALLING,
+ client->name, ts);
+ if (ret) {
+ dev_err(dev, "Unable to request IRQ\n");
+ return ret;
+ }
+
+ /* Enable coordinates update interrupt */
+ ret = i2c_smbus_write_byte_data(client, INT_MASK,
+ CALIBRATION_DONE |
+ SLEEP_OUT | SLEEP_IN |
+ PROGRAM_LOAD_DONE);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, ERR_MASK,
+ PROGRAM_LOAD_ERR | CPU_TIMEOUT |
+ ADC_TIMEOUT);
+ if (ret)
+ return ret;
+
+ /* controller CPU power on */
+ ret = i2c_smbus_write_byte_data(client, SYSTEM,
+ CPU_POWER_ON | ANALOG_POWER_ON);
+
+ return ret;
+}
+
+static int rohm_ts_open(struct input_dev *input_dev)
+{
+ struct rohm_ts_data *ts = input_get_drvdata(input_dev);
+ struct i2c_client *client = ts->client;
+ int ret;
+
+ if (!ts->initialized) {
+ ret = rohm_ts_device_init(ts);
+ if (ret) {
+ dev_err(&client->dev,
+ "Failed to device initialization\n");
+ return ret;
+ }
+
+ ts->initialized = true;
+ }
+
+ return 0;
+}
+
+static int rohm_bu21023_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct rohm_ts_data *ts;
+ struct device *dev = &client->dev;
+ struct input_dev *input_dev;
+ int ret;
+
+ if (!client->irq) {
+ dev_err(dev, "IRQ is not assigned\n");
+ return -EBUSY;
+ }
+
+ ts = devm_kzalloc(dev, sizeof(struct rohm_ts_data), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ ts->client = client;
+ i2c_set_clientdata(client, ts);
+
+ input_dev = devm_input_allocate_device(dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ input_dev->name = BU21023_NAME;
+ input_dev->id.bustype = BUS_I2C;
+ input_dev->open = rohm_ts_open;
+
+ ts->input_dev = input_dev;
+ input_set_drvdata(input_dev, ts);
+
+ set_bit(EV_SYN, input_dev->evbit);
+ set_bit(EV_KEY, input_dev->evbit);
+ set_bit(EV_ABS, input_dev->evbit);
+
+ set_bit(BTN_TOUCH, input_dev->evbit);
+
+ input_set_abs_params(input_dev, ABS_MT_POSITION_X,
+ ROHM_TS_ABS_X_MIN, ROHM_TS_ABS_X_MAX, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
+ ROHM_TS_ABS_Y_MIN, ROHM_TS_ABS_Y_MAX, 0, 0);
+
+ input_set_abs_params(input_dev, ABS_X,
+ ROHM_TS_ABS_X_MIN, ROHM_TS_ABS_X_MAX, 0, 0);
+ input_set_abs_params(input_dev, ABS_Y,
+ ROHM_TS_ABS_Y_MIN, ROHM_TS_ABS_Y_MAX, 0, 0);
+
+ ret = input_register_device(input_dev);
+ if (ret)
+ dev_err(dev, "Unable to register input device\n");
+
+ return ret;
+}
+
+static int rohm_bu21023_i2c_remove(struct i2c_client *client)
+{
+ struct rohm_ts_data *ts = i2c_get_clientdata(client);
+ int ret;
+
+ input_unregister_device(ts->input_dev);
+
+ ret = i2c_smbus_write_byte_data(client, SYSTEM,
+ ANALOG_POWER_ON | CPU_POWER_OFF);
+ if (ret)
+ return ret;
+
+ ret = i2c_smbus_write_byte_data(client, SYSTEM,
+ ANALOG_POWER_OFF | CPU_POWER_OFF);
+
+ return ret;
+}
+
+static const struct i2c_device_id rohm_bu21023_i2c_id[] = {
+ {BU21023_NAME, 0},
+ {},
+};
+
+MODULE_DEVICE_TABLE(i2c, rohm_bu21023_i2c_id);
+
+static struct i2c_driver rohm_bu21023_i2c_driver = {
+ .driver = {
+ .name = BU21023_NAME,
+ },
+ .probe = rohm_bu21023_i2c_probe,
+ .remove = rohm_bu21023_i2c_remove,
+ .id_table = rohm_bu21023_i2c_id,
+};
+
+module_i2c_driver(rohm_bu21023_i2c_driver);
+
+MODULE_DESCRIPTION("ROHM BU21023/24 Touchscreen driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("ROHM Co., Ltd.");
diff --git a/drivers/input/touchscreen/rohm_bu21023.h b/drivers/input/touchscreen/rohm_bu21023.h
new file mode 100644
index 0000000..302581b
--- /dev/null
+++ b/drivers/input/touchscreen/rohm_bu21023.h
@@ -0,0 +1,258 @@
+/*
+ * ROHM BU21023/24 Dual touch support resistive touch screen driver
+ * Copyright (C) 2012 ROHM CO.,LTD.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef _BU21023_TS_H
+#define _BU21023_TS_H
+
+#define BU21023_NAME "bu21023_ts"
+#define BU21023_FIRMWARE_NAME "bu21023.bin"
+
+#define BU21023_MAX_SLOTS 2
+
+#define AXIS_ADJUST 4
+#define AXIS_OFFSET 8
+
+#define FIRMWARE_BLOCK_SIZE 32
+#define FIRMWARE_RETRY_MAX 4
+
+#define SAMPLING_DELAY 12 /* msec */
+
+#define CALIBRATION_RETRY_MAX 6
+
+#define ROHM_TS_ABS_X_MIN 40
+#define ROHM_TS_ABS_X_MAX 990
+#define ROHM_TS_ABS_Y_MIN 160
+#define ROHM_TS_ABS_Y_MAX 920
+
+/*
+ * BU21023GUL/BU21023MUV/BU21024FV-M registers map
+ */
+#define VADOUT_YP_H 0x00
+#define VADOUT_YP_L 0x01
+#define VADOUT_XP_H 0x02
+#define VADOUT_XP_L 0x03
+#define VADOUT_YN_H 0x04
+#define VADOUT_YN_L 0x05
+#define VADOUT_XN_H 0x06
+#define VADOUT_XN_L 0x07
+
+#define PRM1_X_H 0x08
+#define PRM1_X_L 0x09
+#define PRM1_Y_H 0x0a
+#define PRM1_Y_L 0x0b
+#define PRM2_X_H 0x0c
+#define PRM2_X_L 0x0d
+#define PRM2_Y_H 0x0e
+#define PRM2_Y_L 0x0f
+
+#define MLT_PRM_MONI_X 0x10
+#define MLT_PRM_MONI_Y 0x11
+
+#define DEBUG_MONI_1 0x12
+#define DEBUG_MONI_2 0x13
+
+#define VADOUT_ZX_H 0x14
+#define VADOUT_ZX_L 0x15
+#define VADOUT_ZY_H 0x16
+#define VADOUT_ZY_L 0x17
+
+#define Z_PARAM_H 0x18
+#define Z_PARAM_L 0x19
+
+/*
+ * Value for VADOUT_*_L
+ */
+#define VADOUT_L_MASK 0x01
+
+/*
+ * Value for PRM*_*_L
+ */
+#define PRM_L_MASK 0x01
+
+#define POS_X1_H 0x20
+#define POS_X1_L 0x21
+#define POS_Y1_H 0x22
+#define POS_Y1_L 0x23
+#define POS_X2_H 0x24
+#define POS_X2_L 0x25
+#define POS_Y2_H 0x26
+#define POS_Y2_L 0x27
+
+/*
+ * Value for POS_*_L
+ */
+#define POS_L_MASK 0x01
+
+#define TOUCH 0x28
+#define TOUCH_DETECT 0x01
+
+#define TOUCH_GESTURE 0x29
+#define SINGLE_TOUCH 0x01
+#define DUAL_TOUCH 0x03
+#define TOUCH_MASK 0x03
+#define CALIBRATION_REQUEST 0x04
+#define CALIBRATION_STATUS 0x08
+#define CALIBRATION_MASK 0x0c
+#define GESTURE_SPREAD 0x10
+#define GESTURE_PINCH 0x20
+#define GESTURE_ROTATE_R 0x40
+#define GESTURE_ROTATE_L 0x80
+
+#define INT_STATUS 0x2a
+#define INT_MASK 0x3d
+#define INT_CLEAR 0x3e
+
+/*
+ * Values for INT_*
+ */
+#define COORD_UPDATE 0x01
+#define CALIBRATION_DONE 0x02
+#define SLEEP_IN 0x04
+#define SLEEP_OUT 0x08
+#define PROGRAM_LOAD_DONE 0x10
+#define ERROR 0x80
+#define INT_ALL 0x9f
+
+#define ERR_STATUS 0x2b
+#define ERR_MASK 0x3f
+
+/*
+ * Values for ERR_*
+ */
+#define ADC_TIMEOUT 0x01
+#define CPU_TIMEOUT 0x02
+#define CALIBRATION_ERR 0x04
+#define PROGRAM_LOAD_ERR 0x10
+
+#define COMMON_SETUP1 0x30
+#define PROGRAM_LOAD_HOST 0x02
+#define PROGRAM_LOAD_EEPROM 0x03
+#define CENSOR_4PORT 0x04
+#define CENSOR_8PORT 0x00 /* Not supported by BU21023 */
+#define CALIBRATION_TYPE_DEFAULT 0x08
+#define CALIBRATION_TYPE_SPECIAL 0x00
+#define INT_ACTIVE_HIGH 0x10
+#define INT_ACTIVE_LOW 0x00
+#define AUTO_CALIBRATION 0x40
+#define MANUAL_CALIBRATION 0x00
+#define COMMON_SETUP1_DEFAULT 0x4e
+
+#define COMMON_SETUP2 0x31
+#define MAF_NONE 0x00
+#define MAF_1SAMPLE 0x01
+#define MAF_3SAMPLES 0x02
+#define MAF_5SAMPLES 0x03
+#define INV_Y 0x04
+#define INV_X 0x08
+#define SWAP_XY 0x10
+
+#define COMMON_SETUP3 0x32
+#define EN_SLEEP 0x01
+#define EN_MULTI 0x02
+#define EN_GESTURE 0x04
+#define EN_INTVL 0x08
+#define SEL_STEP 0x10
+#define SEL_MULTI 0x20
+#define SEL_TBL_DEFAULT 0x40
+
+#define INTERVAL_TIME 0x33
+#define INTERVAL_TIME_DEFAULT 0x10
+
+#define STEP_X 0x34
+#define STEP_X_DEFAULT 0x41
+
+#define STEP_Y 0x35
+#define STEP_Y_DEFAULT 0x8d
+
+#define OFFSET_X 0x38
+#define OFFSET_X_DEFAULT 0x0c
+
+#define OFFSET_Y 0x39
+#define OFFSET_Y_DEFAULT 0x0c
+
+#define THRESHOLD_TOUCH 0x3a
+#define THRESHOLD_TOUCH_DEFAULT 0xa0
+
+#define THRESHOLD_GESTURE 0x3b
+#define THRESHOLD_GESTURE_DEFAULT 0x17
+
+#define SYSTEM 0x40
+#define ANALOG_POWER_ON 0x01
+#define ANALOG_POWER_OFF 0x00
+#define CPU_POWER_ON 0x02
+#define CPU_POWER_OFF 0x00
+
+#define FORCE_CALIBRATION 0x42
+#define FORCE_CALIBRATION_ON 0x01
+#define FORCE_CALIBRATION_OFF 0x00
+
+#define CPU_FREQ 0x50 /* 10 / (reg + 1) MHz */
+#define CPU_FREQ_10MHZ 0x00
+#define CPU_FREQ_5MHZ 0x01
+#define CPU_FREQ_1MHZ 0x09
+
+#define EEPROM_ADDR 0x51
+
+#define CALIBRATION_ADJUST 0x52
+#define CALIBRATION_ADJUST_DEFAULT 0x00
+
+#define THRESHOLD_SLEEP_IN 0x53
+
+#define EVR_XY 0x56
+#define EVR_XY_DEFAULT 0x10
+
+#define PRM_SWOFF_TIME 0x57
+#define PRM_SWOFF_TIME_DEFAULT 0x04
+
+#define PROGRAM_VERSION 0x5f
+
+#define ADC_CTRL 0x60
+#define ADC_DIV_MASK 0x1f /* The minimum value is 4 */
+#define ADC_DIV_DEFAULT 0x08
+
+#define ADC_WAIT 0x61
+#define ADC_WAIT_DEFAULT 0x0a
+
+#define SWCONT 0x62
+#define SWCONT_DEFAULT 0x0f
+
+#define EVR_X 0x63
+#define EVR_X_DEFAULT 0x86
+
+#define EVR_Y 0x64
+#define EVR_Y_DEFAULT 0x64
+
+#define TEST1 0x65
+#define DUALTOUCH_STABILIZE_ON 0x01
+#define DUALTOUCH_STABILIZE_OFF 0x00
+#define DUALTOUCH_REG_ON 0x20
+#define DUALTOUCH_REG_OFF 0x00
+
+#define CALIBRATION_REG1 0x68
+#define CALIBRATION_REG1_DEFAULT 0xd9
+
+#define CALIBRATION_REG2 0x69
+#define CALIBRATION_REG2_DEFAULT 0x36
+
+#define CALIBRATION_REG3 0x6a
+#define CALIBRATION_REG3_DEFAULT 0x32
+
+#define EX_ADDR_H 0x70
+#define EX_ADDR_L 0x71
+#define EX_WDAT 0x72
+#define EX_RDAT 0x73
+#define EX_CHK_SUM1 0x74
+#define EX_CHK_SUM2 0x75
+#define EX_CHK_SUM3 0x76
+
+#endif /* _BU21023_TS_H */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] HID: hyperv: register as a wakeup source
From: Jiri Kosina @ 2014-08-04 9:23 UTC (permalink / raw)
To: Dexuan Cui
Cc: gregkh, linux-input, linux-kernel, driverdev-devel, olaf, apw,
jasowang, kys, haiyangz
In-Reply-To: <1406903201-7210-1-git-send-email-decui@microsoft.com>
On Fri, 1 Aug 2014, Dexuan Cui wrote:
> With this patch, we can move the mouse to wake up the VM after the VM executes
> "echo freeze > /sys/power/state".
>
> This addresses part of https://bugzilla.redhat.com/show_bug.cgi?id=1086100
>
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
Applied, thanks.
> ---
> drivers/hid/hid-hyperv.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
> index f52dbcb..31fad64 100644
> --- a/drivers/hid/hid-hyperv.c
> +++ b/drivers/hid/hid-hyperv.c
> @@ -308,6 +308,9 @@ static void mousevsc_on_receive(struct hv_device *device,
> memcpy(input_dev->input_buf, input_report->buffer, len);
> hid_input_report(input_dev->hid_device, HID_INPUT_REPORT,
> input_dev->input_buf, len, 1);
> +
> + pm_wakeup_event(&input_dev->device->device, 0);
> +
> break;
> default:
> pr_err("unsupported hid msg type - type %d len %d",
> @@ -549,6 +552,8 @@ static int mousevsc_probe(struct hv_device *device,
> goto probe_err2;
> }
>
> + device_init_wakeup(&device->device, true);
> +
> input_dev->connected = true;
> input_dev->init_complete = true;
>
> @@ -571,6 +576,7 @@ static int mousevsc_remove(struct hv_device *dev)
> {
> struct mousevsc_dev *input_dev = hv_get_drvdata(dev);
>
> + device_init_wakeup(&dev->device, false);
> vmbus_close(dev->channel);
> hid_hw_stop(input_dev->hid_device);
> hid_destroy_device(input_dev->hid_device);
> --
> 1.9.1
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] How to get instance of struct evdev in some driver ?
From: Aniroop Mathur @ 2014-08-03 6:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <20140803064238.GA897@core.coreip.homeip.net>
Hi Mr. Torokhov,
Thank you for your quick reply and clearing my doubt. :)
On Sun, Aug 3, 2014 at 12:12 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Aniroop,
>
> On Sun, Aug 03, 2014 at 12:05:11PM +0530, Aniroop Mathur wrote:
>> Dear Mr. Torokhov and Linux-Input Community,
>> Greetings of the day !! :)
>>
>> I am stuck at one point and could not find the solution over internet.
>> Can you please help in answering my query below:
>>
>> As you know, struct evdev is defined in evdev.c and not in some header file.
>> So, Is it possible to get instance of struct evdev in some input
>> peripheral driver ?
>> If possible, then how can we get it ?
>>
>> In the input peripheral driver,
>> we can get instance struct input_dev by including input.h file
>> and then calling input_allocate_device().
>> struct input_dev = input_allocate_device();
>>
>> May be evdev is embedded somewhere in input_dev.
>> So, can we get the instance of evdev using input_dev ?
>
> Not really. Technically speaking the evdev cam be compiled as a module and it
> will not be bound to the input device until later.
>
> Input devices should be ignorant of the input handlers bound to them, they
> should just supply event stream and not care about anything else. Also evdev
> internal structure is exactly that - internal - and the rest of the kernel
> should not try to poke into it.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] How to get instance of struct evdev in some driver ?
From: Dmitry Torokhov @ 2014-08-03 6:42 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu30-RSdvCmtyn0NmZ4weDsgqhcieV86s9+7OTVJOQEQiSpA@mail.gmail.com>
Hi Aniroop,
On Sun, Aug 03, 2014 at 12:05:11PM +0530, Aniroop Mathur wrote:
> Dear Mr. Torokhov and Linux-Input Community,
> Greetings of the day !! :)
>
> I am stuck at one point and could not find the solution over internet.
> Can you please help in answering my query below:
>
> As you know, struct evdev is defined in evdev.c and not in some header file.
> So, Is it possible to get instance of struct evdev in some input
> peripheral driver ?
> If possible, then how can we get it ?
>
> In the input peripheral driver,
> we can get instance struct input_dev by including input.h file
> and then calling input_allocate_device().
> struct input_dev = input_allocate_device();
>
> May be evdev is embedded somewhere in input_dev.
> So, can we get the instance of evdev using input_dev ?
Not really. Technically speaking the evdev cam be compiled as a module and it
will not be bound to the input device until later.
Input devices should be ignorant of the input handlers bound to them, they
should just supply event stream and not care about anything else. Also evdev
internal structure is exactly that - internal - and the rest of the kernel
should not try to poke into it.
Thanks.
--
Dmitry
^ permalink raw reply
* [Question: Drivers/input/evdev.c] How to get instance of struct evdev in some driver ?
From: Aniroop Mathur @ 2014-08-03 6:35 UTC (permalink / raw)
To: Dmitry Torokhov, dtor, linux-input@vger.kernel.org
Dear Mr. Torokhov and Linux-Input Community,
Greetings of the day !! :)
I am stuck at one point and could not find the solution over internet.
Can you please help in answering my query below:
As you know, struct evdev is defined in evdev.c and not in some header file.
So, Is it possible to get instance of struct evdev in some input
peripheral driver ?
If possible, then how can we get it ?
In the input peripheral driver,
we can get instance struct input_dev by including input.h file
and then calling input_allocate_device().
struct input_dev = input_allocate_device();
May be evdev is embedded somewhere in input_dev.
So, can we get the instance of evdev using input_dev ?
Thanks in Advance !
-- Aniroop Mathur
^ permalink raw reply
* Re: [PATCH 2/7] i2c: i2c-cros-ec-tunnel: Set retries to 3
From: Javier Martinez Canillas @ 2014-08-01 18:05 UTC (permalink / raw)
To: Wolfram Sang
Cc: Lee Jones, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, linux-i2c, linux-input, linux-samsung-soc
In-Reply-To: <20140801175912.GF3277@katana>
Hello Wolfram,
On 08/01/2014 07:59 PM, Wolfram Sang wrote:
>>
>> +#define I2C_MAX_RETRIES 3
>
> I think a define for this is overkill, yet I don't really mind.
>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
>
Thanks a lot.
> I assume this goes via MFD, let me know if I should take it.
>
Yes, if possible I prefer if all the series are picked by Lee Jones to avoid any
dependencies.
Best regards,
Javier
^ 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