* Re: [PATCH 06/10] input: touchscreen: edt-ft5x06: fix driver autoprobing
From: Dmitry Torokhov @ 2014-11-18 18:38 UTC (permalink / raw)
To: Felipe Balbi
Cc: Tony Lindgren, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, Lothar Waßmann, Rob Herring,
devicetree, linux-input, stable
In-Reply-To: <1416334028-7766-6-git-send-email-balbi@ti.com>
Hi Felipe,
On Tue, Nov 18, 2014 at 12:07:04PM -0600, Felipe Balbi wrote:
> i2c devices match against struct i2c_device_id
> even for CONFIG_OF case, so adding a struct of_device_id
> doesn't change anything. As a result, currently, edt-ft5x06
> will not autoprobe if built as a module.
Why doe snot it autoprobe? We properly declare MODULE_DEVICE_TABLE for
OF, is it because we are missing some data in device uevent?
>
> To fix the issue and still maintain backwards compatibility
> with all DTS files currently in tree, we're just moving
> all ids from of_device_id to i2c_device_id while also
> adding the following specific ids which should be used
> from now on:
>
> { "edt-ft5206", 0, }
> { "edt-ft5306", 0, }
> { "edt-ft5406", 0, }
Is this a tee-wide change? Link to the discussion?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 06/10] input: touchscreen: edt-ft5x06: fix driver autoprobing
From: Felipe Balbi @ 2014-11-18 18:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linux OMAP Mailing List, Linux ARM Kernel Mailing List,
Felipe Balbi, Lothar Waßmann, Rob Herring, Dmitry Torokhov,
devicetree, linux-input, stable
In-Reply-To: <1416334028-7766-1-git-send-email-balbi@ti.com>
i2c devices match against struct i2c_device_id
even for CONFIG_OF case, so adding a struct of_device_id
doesn't change anything. As a result, currently, edt-ft5x06
will not autoprobe if built as a module.
To fix the issue and still maintain backwards compatibility
with all DTS files currently in tree, we're just moving
all ids from of_device_id to i2c_device_id while also
adding the following specific ids which should be used
from now on:
{ "edt-ft5206", 0, }
{ "edt-ft5306", 0, }
{ "edt-ft5406", 0, }
Cc: Lothar Waßmann <lw@karo-electronics.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: <devicetree@vger.kernel.org>
Cc: <linux-input@vger.kernel.org>
Cc: <stable@vger.kernel.org> # v3.15+
Fixes: dac90dc2 (Input: edt-ft5x06 - add DT support)
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
.../bindings/input/touchscreen/edt-ft5x06.txt | 9 ++++++---
drivers/input/touchscreen/edt-ft5x06.c | 17 ++++++-----------
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 76db967..50bd5d2 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -14,9 +14,12 @@ bindings.
Required properties:
- - compatible: "edt,edt-ft5206"
- or: "edt,edt-ft5306"
- or: "edt,edt-ft5406"
+ - compatible: "edt-ft5206"
+ or: "edt-ft5306"
+ or: "edt-ft5406"
+ or: "edt,edt-ft5206" (deprecated)
+ or: "edt,edt-ft5306" (deprecated)
+ or: "edt,edt-ft5406" (deprecated)
- reg: I2C slave address of the chip (0x38)
- interrupt-parent: a phandle pointing to the interrupt controller
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index ee3434f..f161ff9 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1119,25 +1119,20 @@ static SIMPLE_DEV_PM_OPS(edt_ft5x06_ts_pm_ops,
static const struct i2c_device_id edt_ft5x06_ts_id[] = {
{ "edt-ft5x06", 0, },
+ { "edt-ft5206", 0, },
+ { "edt-ft5306", 0, },
+ { "edt-ft5406", 0, },
+ { "edt,edt-ft5206", 0, },
+ { "edt,edt-ft5306", 0, },
+ { "edt,edt-ft5406", 0, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(i2c, edt_ft5x06_ts_id);
-#ifdef CONFIG_OF
-static const struct of_device_id edt_ft5x06_of_match[] = {
- { .compatible = "edt,edt-ft5206", },
- { .compatible = "edt,edt-ft5306", },
- { .compatible = "edt,edt-ft5406", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, edt_ft5x06_of_match);
-#endif
-
static struct i2c_driver edt_ft5x06_ts_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "edt_ft5x06",
- .of_match_table = of_match_ptr(edt_ft5x06_of_match),
.pm = &edt_ft5x06_ts_pm_ops,
},
.id_table = edt_ft5x06_ts_id,
--
2.1.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Dmitry Torokhov @ 2014-11-18 17:12 UTC (permalink / raw)
To: Lee Jones
Cc: Vignesh R, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Benoit Cousson, Tony Lindgren, Russell King,
Jonathan Cameron, Hartmut Knaack,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w, Sebastian Andrzej Siewior,
Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Brad Griffis, Sanjeev Sharma, Paul Gortmaker, Jan Kardell,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kern
In-Reply-To: <20141118143005.GF24004@x1>
On Tue, Nov 18, 2014 at 02:30:05PM +0000, Lee Jones wrote:
> On Fri, 14 Nov 2014, Vignesh R wrote:
>
> > In one shot mode, sequencer automatically disables all enabled steps at
> > the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> > need not be saved in reg_se_cache for clearing these steps at a later
> > stage.
> > Also, when ADC wakes up Sequencer should not be busy executing any of the
> > config steps except for the charge step. Previously charge step was 1 ADC
> > clock cycle and hence it was ignored.
> >
> > Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
> > ---
> > drivers/mfd/ti_am335x_tscadc.c | 7 +++++--
> > include/linux/mfd/ti_am335x_tscadc.h | 1 +
> > 2 files changed, 6 insertions(+), 2 deletions(-)
>
> Code looks better now.
>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> What's the plan for this series?
I am waiting for the interested parties to provide more feedback. So far
I have seen a few reports saying that they see issues with the series
applied.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Lee Jones @ 2014-11-18 14:30 UTC (permalink / raw)
To: Vignesh R
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, richardcochran, Dmitry Torokhov,
Sebastian Andrzej Siewior, Lars-Peter Clausen, Peter Meerwald,
Samuel Ortiz, Felipe Balbi, Brad Griffis, Sanjeev Sharma,
Paul Gortmaker, Jan Kardell, devicetree, linux-kernel, linux-omap
In-Reply-To: <1415941651-28962-4-git-send-email-vigneshr@ti.com>
On Fri, 14 Nov 2014, Vignesh R wrote:
> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
> Also, when ADC wakes up Sequencer should not be busy executing any of the
> config steps except for the charge step. Previously charge step was 1 ADC
> clock cycle and hence it was ignored.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> drivers/mfd/ti_am335x_tscadc.c | 7 +++++--
> include/linux/mfd/ti_am335x_tscadc.h | 1 +
> 2 files changed, 6 insertions(+), 2 deletions(-)
Code looks better now.
Acked-by: Lee Jones <lee.jones@linaro.org>
What's the plan for this series?
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index d877e777cce6..110038859a8d 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev *tsadc)
> spin_lock_irq(&tsadc->reg_lock);
> finish_wait(&tsadc->reg_se_wait, &wait);
>
> + /*
> + * Sequencer should either be idle or
> + * busy applying the charge step.
> + */
> reg = tscadc_readl(tsadc, REG_ADCFSM);
> - WARN_ON(reg & SEQ_STATUS);
> + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
> tsadc->adc_waiting = false;
> }
> tsadc->adc_in_use = true;
> @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev *tsadc)
> void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
> {
> spin_lock_irq(&tsadc->reg_lock);
> - tsadc->reg_se_cache |= val;
> am335x_tscadc_need_adc(tsadc);
>
> tscadc_writel(tsadc, REG_SE, val);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> index 3f4e994ace2b..1fd50dcfe47c 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -128,6 +128,7 @@
>
> /* Sequencer Status */
> #define SEQ_STATUS BIT(5)
> +#define CHARGE_STEP 0x11
>
> #define ADC_CLK 3000000
> #define TOTAL_STEPS 16
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning
From: bri @ 2014-11-18 14:26 UTC (permalink / raw)
To: Frank Praznik
Cc: Antonio Ospite, Jiri Kosina, Henrik Rydberg, open, HID CORE LAYER,
open list, Michael Kerrisk
In-Reply-To: <546ABB51.4010905@gmail.com>
On Mon, Nov 17, 2014 at 10:21:53PM -0500, Frank Praznik wrote:
> Hi Brian,
>
> On 11/17/2014 19:00, bri wrote:
> >
> >>Yeah, the device ID in the driver is only for tracking devices internally
> >>and setting sane default LED values. It has no meaning outside of the
> >>module. Like Antonio said, if you want the system number for a controller
> >>you are better off just getting it from the joystick device.
> >Would you be amenable to a patch that removes the IDA entirely and just sets
> >the LEDs to all solid-on? Since the LEDs are available through sysfs,
> >udev rule could probably be made to set the LEDs in the absence of bluez
> >or a higher level controller manager, and then it becomes the distro's
> >responsibility.
> >
>
> What would be the benefit of doing this? Nothing is stopping higher level
> services from setting the LEDs right now. The driver just sets sane
> defaults for systems that don't have anything else to set the 'real' values.
> Other controllers like Wiimotes and Xbox gamepads do the same thing. It
> doesn't get in the way of services like BlueZ setting them once
> initialization is complete.
>
> Leaving it completely up to the distro just means that there will be
> situations where there is nothing to set the default values which makes for
> a bad user experience.
It would eliminate 50 to 100 lines of code just for that tiny purpose,
which userspace can and probably should take care of, given the disparity
with the eventual values. I'm honestly a bit confused of the criteria in use
here, as I thought it was mostly deciding between the usefulness of features
versus maintainability. In my mind if I weight a master_bdaddr sysfs file
and the code to support it versus this feature, I don't see where this one
wins out.
But whatever. I made this for my own use, and offered it up, and if the
community does not want it I am free to keep using what I made, so I'm happy
either way.
^ permalink raw reply
* Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning
From: Frank Praznik @ 2014-11-18 3:21 UTC (permalink / raw)
To: bri
Cc: Antonio Ospite, Jiri Kosina, Henrik Rydberg, open, HID CORE LAYER,
open list, Michael Kerrisk
In-Reply-To: <20141118000005.GA32256@abrij.org>
Hi Brian,
On 11/17/2014 19:00, bri wrote:
>
>> Yeah, the device ID in the driver is only for tracking devices internally
>> and setting sane default LED values. It has no meaning outside of the
>> module. Like Antonio said, if you want the system number for a controller
>> you are better off just getting it from the joystick device.
> Would you be amenable to a patch that removes the IDA entirely and just sets
> the LEDs to all solid-on? Since the LEDs are available through sysfs,
> udev rule could probably be made to set the LEDs in the absence of bluez
> or a higher level controller manager, and then it becomes the distro's
> responsibility.
>
What would be the benefit of doing this? Nothing is stopping higher
level services from setting the LEDs right now. The driver just sets
sane defaults for systems that don't have anything else to set the
'real' values. Other controllers like Wiimotes and Xbox gamepads do the
same thing. It doesn't get in the way of services like BlueZ setting
them once initialization is complete.
Leaving it completely up to the distro just means that there will be
situations where there is nothing to set the default values which makes
for a bad user experience.
^ permalink raw reply
* Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning
From: bri @ 2014-11-18 2:01 UTC (permalink / raw)
To: Antonio Ospite
Cc: Frank Praznik, Jiri Kosina, Henrik Rydberg,
open list:HID CORE LAYER, open list, Michael Kerrisk
In-Reply-To: <20141117133518.ee306b3b35a0e0566a255b14@ao2.it>
On Mon, Nov 17, 2014 at 01:35:18PM +0100, Antonio Ospite wrote:
> I had tried doing something similar in the past (the parsing was just a
> sscanf): http://thread.gmane.org/gmane.linux.bluez.kernel/5261 but then
> we deliberately decided against exposing specific sysfs interfaces for
> device/master_bdaddr, you can just use generic HID feature reports from
> userspace to get/set these, write a simple program reusing the code in
> the BlueZ sixaxis plugin, using the ioclts
> HIDIOCGFEATURE/HIDIOCSFEATURE, this way you don't depend on libusb. As
> an historical note, the BlueZ sixaxis plugin was one of the first user
> of these ioctls.
...
> That said I still don't think the changes you are proposing are strictly
> necessary in the kernel driver, but let's see what the others have to
> say about that.
On Mon, Nov 17, 2014 at 02:39:35PM -0500, Frank Praznik wrote:
> Agreed, I don't see a need for exposing this as a sysfs entry since it's
> easy enough to use hidraw and an ioctl call to set/get the master address.
For this argument I would offer that "easy" is different for you or I
working on a development system than for a less versed person working
to personally customize an appliance that didn't come with a gcc package,
but probably did come with /bin/sh.
(That it is no longer necessary to detach the kernel driver and go
through another enumeration cycle as it was with libusb is a definite
improvement.)
Frank, still:
> What happened when plugging in a DS3 or DS4 via USB when it was already
> connected via Bluetooth was that you ended up with a duplicate device. In
> the case of the DS3 the extra controller entry was basically a
> non-functional "zombie" since the controller itself didn't send any events
> over USB if it was already running over Bluetooth. If you want to switch
> from wireless to wired you just have to disconnect first. I don't think
> it's possible to get around this, at least not in a way that is as seamless
> as the current solution.
Is that a limitation of the device, in your assessment, or a shortcoming
of the driver code/hid-core? I know the PS3 can at least sleep the
dualshocks while they are on BT, so could a disconnect not be sent by bluez
upon sensing the USB connection? At that point the problem boils down to
descriptor churn, which is entirely an artifact of the driver model, and
maybe it is time to challenge that model a tiny bit.
>From an end-user perspective, with USB "disconnecting" is something as
easy and self-explanatory as pulling a wire. With bluetooth not so much,
so your average console user is going to be without a UI-less recourse
if they want to go back to wired operation hastily during play, unless
we make connecting USB a surrogate for disconnecting BT.
> Just one code comment to add to what Antonio already said:
>
> >
> >+
> >+ ret = device_create_file(&hdev->dev, &dev_attr_master_bdaddr);
> >+ if (ret) {
> >+ hid_err(hdev, "failed to create master_bdaddr sysfs file\n");
> >+ goto err_nosysfs1;
> > }
> Why even expose this on the DS4 or the Sixaxis when in Bluetooth mode? Put
> it behind if (sc->quirks & SIXAXIS_CONTROLLER_USB)
I figured it would be easier for shell scripts if the fd always exists. Also
if you had multiple bluetooth hosts and were using it to figure out which
one a controller was currently attached to you would not have to do anything
additional. But, as Antonio points out:
On Mon, Nov 17, 2014 at 01:35:18PM +0100, Antonio Ospite wrote:
> > +#include <net/bluetooth/bluetooth.h>
> > +#include <net/bluetooth/hci_core.h>
>
> A HID driver should not need to depend on bluetooth, no other HID
> driver does. Layer violations should be avoided as much as possible.
...so yeah that was probably a bad idea, though it does make me wonder
if there is a proper way for a device hid driver to query properties
of its host.
Continuing on with Antonio's comments:
> I'd also try to avoid custom parsing routines in kernel code as much as
> possible.
Sorry, I work as a network administrator and lose a minimum of 10 minutes
of productivity a day massaging pasted MAC addresses between different
formats, and that adds up over time. So, I just could not bring myself
to become part of that problem.
> You know you can build Debian packages from the official git kernel
> repository, don't you?
> make LOCALVERSION=-brian INSTALL_MOD_STRIP=1 deb-pkg
I had in fact missed that development, thank you.
> > On the other hand this is not the behavior gamers expect and will not
> > help matters if the reason for plugging the pad in was to decrease
> > latency due to RF contention.
>
> This is an interesting point, can you show numbers about these latency
> problems?
Personally, no, not being a gadgeteer, I don't own enough RF devices to
test that. Also I'm an old caffeine-damaged fogey who doesn't have the
steady hand to play twitch games anymore so I cannot say I have experienced
it personally.
In lieu of that I can offer that a google search of "ps4 controller wired"
shows evidence that a lack of wired fallback functionality earns brickbats
from the gamer community. I'd also point out that SteamOS is certainly going
to find itself in tournament and LAN-party situations where many systems
are crammed in close quarters.
^ permalink raw reply
* Re: [PATCH] HID: wacom - Bamboo pen only tablet does not support PAD
From: Ping Cheng @ 2014-11-18 0:13 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, Ping Cheng
In-Reply-To: <CAN+gG=Edu2JXSguJE0w710xnuQQP-vvi6wEG-hBTex=bfqS9DA@mail.gmail.com>
Hi Benjamin,
Thank you for the review. An updated version will be posted soon. Let
me know if you need us to capture data from more devices for your
testing.
Cheers,
Ping
On Mon, Nov 17, 2014 at 2:38 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi Ping,
>
> On Mon, Nov 17, 2014 at 4:45 PM, Ping Cheng <pinglinux@gmail.com> wrote:
>> Bamboo models do not support HID_DG_CONTACTMAX. We should not rely
>> on that description to decide touch_max for them. Plus, no Bamboo
>> device supports single touch.
>>
>> Signed-off-by: Ping Cheng <pingc@wacom.com>
>> ---
>> drivers/hid/wacom_sys.c | 4 ++--
>> drivers/hid/wacom_wac.c | 30 ++++++++++++++++++++++--------
>> 2 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
>> index 8593047..46147b4 100644
>> --- a/drivers/hid/wacom_sys.c
>> +++ b/drivers/hid/wacom_sys.c
>> @@ -192,8 +192,8 @@ static void wacom_usage_mapping(struct hid_device *hdev,
>> if (!pen && !finger)
>> return;
>>
>> - if (finger && !features->touch_max)
>> - /* touch device at least supports one touch point */
>> + if (finger && !features->touch_max && (features->type != BAMBOO_PT))
>> + /* ISDv4 touch devices at least supports one touch point */
>
> Can you also explain here that the report descriptor of the Bamboos
> contains the touch even if the device itself has not the capability?
> IMO, it will help further readings when we will try to understand this
> particular case.
>
>> features->touch_max = 1;
>>
>> switch (usage->hid) {
>> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
>> index 586b240..fc9b492 100644
>> --- a/drivers/hid/wacom_wac.c
>> +++ b/drivers/hid/wacom_wac.c
>> @@ -2402,7 +2402,7 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
>> case INTUOSPS:
>> /* touch interface does not have the pad device */
>> if (features->device_type != BTN_TOOL_PEN)
>> - return 1;
>> + goto no_pad;
>
> There is actually no need to clean up the pad on error.
> When an error is raised, the associated pad input device is simply
> freed, so the cleanup add superfluous steps.
>
> Maybe a cleaner way to handle that would be to return -ENODEV. This
> will show that this is an abort and that the pad input device will not
> be used anymore.
>
>>
>> for (i = 0; i < 7; i++)
>> __set_bit(BTN_0 + i, input_dev->keybit);
>> @@ -2447,22 +2447,36 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
>> case BAMBOO_PT:
>> /* pad device is on the touch interface */
>> if (features->device_type != BTN_TOOL_FINGER)
>> - return 1;
>> + goto no_pad;
>>
>> __clear_bit(ABS_MISC, input_dev->absbit);
>>
>> - __set_bit(BTN_LEFT, input_dev->keybit);
>> - __set_bit(BTN_FORWARD, input_dev->keybit);
>> - __set_bit(BTN_BACK, input_dev->keybit);
>> - __set_bit(BTN_RIGHT, input_dev->keybit);
>> + /* Bamboo Pen only tablet does not have pad */
>> + if ((features->type != BAMBOO_PT) ||
>> + ((features->type == BAMBOO_PT) && features->touch_max)) {
>
> I would prefer keeping the standard path as it is, and add a special
> test above where you bail out. We will be able to add further special
> cases as needed, and not stack the parenthesis :)
>
> [looks like it is bikeshedding day for me... sorry]
>
>> + __set_bit(BTN_LEFT, input_dev->keybit);
>> + __set_bit(BTN_FORWARD, input_dev->keybit);
>> + __set_bit(BTN_BACK, input_dev->keybit);
>> + __set_bit(BTN_RIGHT, input_dev->keybit);
>> + } else
>> + goto no_pad;
>>
>> break;
>>
>> default:
>> - /* no pad supported */
>> - return 1;
>> + goto no_pad;
>> }
>> return 0;
>> +
>> +no_pad:
>> + input_dev->evbit[0] &= ~BIT_MASK(EV_KEY) & ~BIT_MASK(EV_ABS);
>> + __clear_bit(ABS_MISC, input_dev->absbit);
>> + __clear_bit(ABS_X, input_dev->absbit);
>> + __clear_bit(ABS_Y, input_dev->absbit);
>> + __clear_bit(BTN_STYLUS, input_dev->keybit);
>> +
>> + return 1;
>> +
>> }
>>
>> static const struct wacom_features wacom_features_0x00 =
>> --
>> 1.9.1
>>
>
> FWIW, there is no regressions with this patch regarding the devices we
> have at Red Hat :)
> /me just updated hid-replay and played with it...
>
> Cheers,
> Benjamin
^ permalink raw reply
* Re: [PATCH] HID: wacom - Bamboo pen only tablet does not support PAD
From: Benjamin Tissoires @ 2014-11-17 22:38 UTC (permalink / raw)
To: Ping Cheng; +Cc: Jiri Kosina, linux-input, Ping Cheng
In-Reply-To: <1416260755-13635-1-git-send-email-pingc@wacom.com>
Hi Ping,
On Mon, Nov 17, 2014 at 4:45 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> Bamboo models do not support HID_DG_CONTACTMAX. We should not rely
> on that description to decide touch_max for them. Plus, no Bamboo
> device supports single touch.
>
> Signed-off-by: Ping Cheng <pingc@wacom.com>
> ---
> drivers/hid/wacom_sys.c | 4 ++--
> drivers/hid/wacom_wac.c | 30 ++++++++++++++++++++++--------
> 2 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 8593047..46147b4 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -192,8 +192,8 @@ static void wacom_usage_mapping(struct hid_device *hdev,
> if (!pen && !finger)
> return;
>
> - if (finger && !features->touch_max)
> - /* touch device at least supports one touch point */
> + if (finger && !features->touch_max && (features->type != BAMBOO_PT))
> + /* ISDv4 touch devices at least supports one touch point */
Can you also explain here that the report descriptor of the Bamboos
contains the touch even if the device itself has not the capability?
IMO, it will help further readings when we will try to understand this
particular case.
> features->touch_max = 1;
>
> switch (usage->hid) {
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 586b240..fc9b492 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -2402,7 +2402,7 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
> case INTUOSPS:
> /* touch interface does not have the pad device */
> if (features->device_type != BTN_TOOL_PEN)
> - return 1;
> + goto no_pad;
There is actually no need to clean up the pad on error.
When an error is raised, the associated pad input device is simply
freed, so the cleanup add superfluous steps.
Maybe a cleaner way to handle that would be to return -ENODEV. This
will show that this is an abort and that the pad input device will not
be used anymore.
>
> for (i = 0; i < 7; i++)
> __set_bit(BTN_0 + i, input_dev->keybit);
> @@ -2447,22 +2447,36 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
> case BAMBOO_PT:
> /* pad device is on the touch interface */
> if (features->device_type != BTN_TOOL_FINGER)
> - return 1;
> + goto no_pad;
>
> __clear_bit(ABS_MISC, input_dev->absbit);
>
> - __set_bit(BTN_LEFT, input_dev->keybit);
> - __set_bit(BTN_FORWARD, input_dev->keybit);
> - __set_bit(BTN_BACK, input_dev->keybit);
> - __set_bit(BTN_RIGHT, input_dev->keybit);
> + /* Bamboo Pen only tablet does not have pad */
> + if ((features->type != BAMBOO_PT) ||
> + ((features->type == BAMBOO_PT) && features->touch_max)) {
I would prefer keeping the standard path as it is, and add a special
test above where you bail out. We will be able to add further special
cases as needed, and not stack the parenthesis :)
[looks like it is bikeshedding day for me... sorry]
> + __set_bit(BTN_LEFT, input_dev->keybit);
> + __set_bit(BTN_FORWARD, input_dev->keybit);
> + __set_bit(BTN_BACK, input_dev->keybit);
> + __set_bit(BTN_RIGHT, input_dev->keybit);
> + } else
> + goto no_pad;
>
> break;
>
> default:
> - /* no pad supported */
> - return 1;
> + goto no_pad;
> }
> return 0;
> +
> +no_pad:
> + input_dev->evbit[0] &= ~BIT_MASK(EV_KEY) & ~BIT_MASK(EV_ABS);
> + __clear_bit(ABS_MISC, input_dev->absbit);
> + __clear_bit(ABS_X, input_dev->absbit);
> + __clear_bit(ABS_Y, input_dev->absbit);
> + __clear_bit(BTN_STYLUS, input_dev->keybit);
> +
> + return 1;
> +
> }
>
> static const struct wacom_features wacom_features_0x00 =
> --
> 1.9.1
>
FWIW, there is no regressions with this patch regarding the devices we
have at Red Hat :)
/me just updated hid-replay and played with it...
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: fix race condition reading reports
From: Benjamin Tissoires @ 2014-11-17 22:07 UTC (permalink / raw)
To: Greg KH
Cc: Antonio Borneo, Jiri Kosina, linux-input, linux-kernel,
Jean-Baptiste Maneyrol, stable
In-Reply-To: <20141117215111.GA19828@kroah.com>
On Nov 17 2014 or thereabouts, Greg KH wrote:
> On Mon, Nov 17, 2014 at 04:43:05PM -0500, Benjamin Tissoires wrote:
> > Hey Antonio,
> >
> > On Nov 16 2014 or thereabouts, Antonio Borneo wrote:
> > > From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> > >
> > > From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> > >
> > > Current driver uses a common buffer for reading reports either
> > > synchronously in i2c_hid_get_raw_report() and asynchronously in
> > > the interrupt handler.
> > > There is race condition if an interrupt arrives immediately after
> > > the report is received in i2c_hid_get_raw_report(); the common
> > > buffer is modified by the interrupt handler with the new report
> > > and then i2c_hid_get_raw_report() proceed using wrong data.
> > >
> > > Fix it by using a separate buffers for asynchronous reports.
> > >
> > > Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> > > [Antonio Borneo: cleanup and rebase to v3.17]
> > > Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
> > > Cc: stable@vger.kernel.org
> >
> > For your next submission, when you want a patch to go in stable, put CC
> > here, but please do not CC the actual mail to stable@. Stable should receive
> > either mails which are already in Linus' tree, or which refer a commit
> > in Linus' tree in case it does not applies smoothly.
> >
> > [keeping stable@ here to show them that this one should not get picked
> > right now]
>
> stable@ is smarter than that, I don't mind seeing patches that are
> coming in the future like this at all, it's not a problem.
>
OK. Sorry for the noise then. I assumed that if everybody starts sending
potential patches to stable without them being the accepted ones, you
will end up having to deal with a lot more workload that you already have.
And just to be sure that there is no misinterpretation, I did not wanted
to imply that stable was not smart enough to deal with such patches... I
really appreciate the work done and my concern was to not add workload.
Cheers,
Benjamin
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: fix race condition reading reports
From: Greg KH @ 2014-11-17 21:51 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Antonio Borneo, Jiri Kosina, linux-input, linux-kernel,
Jean-Baptiste Maneyrol, stable
In-Reply-To: <20141117214305.GC30324@mail.corp.redhat.com>
On Mon, Nov 17, 2014 at 04:43:05PM -0500, Benjamin Tissoires wrote:
> Hey Antonio,
>
> On Nov 16 2014 or thereabouts, Antonio Borneo wrote:
> > From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> >
> > From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> >
> > Current driver uses a common buffer for reading reports either
> > synchronously in i2c_hid_get_raw_report() and asynchronously in
> > the interrupt handler.
> > There is race condition if an interrupt arrives immediately after
> > the report is received in i2c_hid_get_raw_report(); the common
> > buffer is modified by the interrupt handler with the new report
> > and then i2c_hid_get_raw_report() proceed using wrong data.
> >
> > Fix it by using a separate buffers for asynchronous reports.
> >
> > Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> > [Antonio Borneo: cleanup and rebase to v3.17]
> > Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
> > Cc: stable@vger.kernel.org
>
> For your next submission, when you want a patch to go in stable, put CC
> here, but please do not CC the actual mail to stable@. Stable should receive
> either mails which are already in Linus' tree, or which refer a commit
> in Linus' tree in case it does not applies smoothly.
>
> [keeping stable@ here to show them that this one should not get picked
> right now]
stable@ is smarter than that, I don't mind seeing patches that are
coming in the future like this at all, it's not a problem.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] HID: wacom - Bamboo pen only tablet does not support PAD
From: Ping Cheng @ 2014-11-17 21:45 UTC (permalink / raw)
To: jkosina; +Cc: linux-input, Ping Cheng
Bamboo models do not support HID_DG_CONTACTMAX. We should not rely
on that description to decide touch_max for them. Plus, no Bamboo
device supports single touch.
Signed-off-by: Ping Cheng <pingc@wacom.com>
---
drivers/hid/wacom_sys.c | 4 ++--
drivers/hid/wacom_wac.c | 30 ++++++++++++++++++++++--------
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 8593047..46147b4 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -192,8 +192,8 @@ static void wacom_usage_mapping(struct hid_device *hdev,
if (!pen && !finger)
return;
- if (finger && !features->touch_max)
- /* touch device at least supports one touch point */
+ if (finger && !features->touch_max && (features->type != BAMBOO_PT))
+ /* ISDv4 touch devices at least supports one touch point */
features->touch_max = 1;
switch (usage->hid) {
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 586b240..fc9b492 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -2402,7 +2402,7 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
case INTUOSPS:
/* touch interface does not have the pad device */
if (features->device_type != BTN_TOOL_PEN)
- return 1;
+ goto no_pad;
for (i = 0; i < 7; i++)
__set_bit(BTN_0 + i, input_dev->keybit);
@@ -2447,22 +2447,36 @@ int wacom_setup_pad_input_capabilities(struct input_dev *input_dev,
case BAMBOO_PT:
/* pad device is on the touch interface */
if (features->device_type != BTN_TOOL_FINGER)
- return 1;
+ goto no_pad;
__clear_bit(ABS_MISC, input_dev->absbit);
- __set_bit(BTN_LEFT, input_dev->keybit);
- __set_bit(BTN_FORWARD, input_dev->keybit);
- __set_bit(BTN_BACK, input_dev->keybit);
- __set_bit(BTN_RIGHT, input_dev->keybit);
+ /* Bamboo Pen only tablet does not have pad */
+ if ((features->type != BAMBOO_PT) ||
+ ((features->type == BAMBOO_PT) && features->touch_max)) {
+ __set_bit(BTN_LEFT, input_dev->keybit);
+ __set_bit(BTN_FORWARD, input_dev->keybit);
+ __set_bit(BTN_BACK, input_dev->keybit);
+ __set_bit(BTN_RIGHT, input_dev->keybit);
+ } else
+ goto no_pad;
break;
default:
- /* no pad supported */
- return 1;
+ goto no_pad;
}
return 0;
+
+no_pad:
+ input_dev->evbit[0] &= ~BIT_MASK(EV_KEY) & ~BIT_MASK(EV_ABS);
+ __clear_bit(ABS_MISC, input_dev->absbit);
+ __clear_bit(ABS_X, input_dev->absbit);
+ __clear_bit(ABS_Y, input_dev->absbit);
+ __clear_bit(BTN_STYLUS, input_dev->keybit);
+
+ return 1;
+
}
static const struct wacom_features wacom_features_0x00 =
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: fix race condition reading reports
From: Benjamin Tissoires @ 2014-11-17 21:43 UTC (permalink / raw)
To: Antonio Borneo
Cc: Jiri Kosina, linux-input, linux-kernel, Jean-Baptiste Maneyrol,
stable
In-Reply-To: <1416149064-25655-1-git-send-email-borneo.antonio@gmail.com>
Hey Antonio,
On Nov 16 2014 or thereabouts, Antonio Borneo wrote:
> From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
>
> From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
>
> Current driver uses a common buffer for reading reports either
> synchronously in i2c_hid_get_raw_report() and asynchronously in
> the interrupt handler.
> There is race condition if an interrupt arrives immediately after
> the report is received in i2c_hid_get_raw_report(); the common
> buffer is modified by the interrupt handler with the new report
> and then i2c_hid_get_raw_report() proceed using wrong data.
>
> Fix it by using a separate buffers for asynchronous reports.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> [Antonio Borneo: cleanup and rebase to v3.17]
> Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
> Cc: stable@vger.kernel.org
For your next submission, when you want a patch to go in stable, put CC
here, but please do not CC the actual mail to stable@. Stable should receive
either mails which are already in Linus' tree, or which refer a commit
in Linus' tree in case it does not applies smoothly.
[keeping stable@ here to show them that this one should not get picked
right now]
> ---
>
> Hi Jiri, Benjamin,
>
> I think this patch should also go through linux-stable.
> Confirmation from our side is welcome.
I think the patch is definitively valuable. However, my personal taste
would go for having a new .rawbuf buffer and use it in
i2c_hid_get_raw_report(). The rationale would be that it's actually
i2c_hid_get_raw_report() which is problematic, not the generic irq
handling. Also I prefer rawbuf to irqinbuf.
I am perfectly aware that this is just bikeshedding, so if changing the
patch is too cumbersome (looks like Jean-Baptiste is involved), and if
Jiri agree, this can go into the hid tree with my reviewed-by.
I am fine having this version or the rawbuf one in stable BTW.
Cheers,
Benjamin
>
> Regards,
> Antonio
>
> drivers/hid/i2c-hid/i2c-hid.c | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 933bf10..7c80e96 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -136,6 +136,7 @@ struct i2c_hid {
> * register of the HID
> * descriptor. */
> unsigned int bufsize; /* i2c buffer size */
> + char *irqinbuf; /* Asynchronous Input buffer */
> char *inbuf; /* Input buffer */
> char *cmdbuf; /* Command buffer */
> char *argsbuf; /* Command arguments buffer */
> @@ -371,7 +372,7 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
> int ret, ret_size;
> int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
>
> - ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
> + ret = i2c_master_recv(ihid->client, ihid->irqinbuf, size);
> if (ret != size) {
> if (ret < 0)
> return;
> @@ -381,7 +382,7 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
> return;
> }
>
> - ret_size = ihid->inbuf[0] | ihid->inbuf[1] << 8;
> + ret_size = ihid->irqinbuf[0] | ihid->irqinbuf[1] << 8;
>
> if (!ret_size) {
> /* host or device initiated RESET completed */
> @@ -396,11 +397,11 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
> return;
> }
>
> - i2c_hid_dbg(ihid, "input: %*ph\n", ret_size, ihid->inbuf);
> + i2c_hid_dbg(ihid, "input: %*ph\n", ret_size, ihid->irqinbuf);
>
> if (test_bit(I2C_HID_STARTED, &ihid->flags))
> - hid_input_report(ihid->hid, HID_INPUT_REPORT, ihid->inbuf + 2,
> - ret_size - 2, 1);
> + hid_input_report(ihid->hid, HID_INPUT_REPORT,
> + ihid->irqinbuf + 2, ret_size - 2, 1);
>
> return;
> }
> @@ -503,9 +504,11 @@ static void i2c_hid_find_max_report(struct hid_device *hid, unsigned int type,
>
> static void i2c_hid_free_buffers(struct i2c_hid *ihid)
> {
> + kfree(ihid->irqinbuf);
> kfree(ihid->inbuf);
> kfree(ihid->argsbuf);
> kfree(ihid->cmdbuf);
> + ihid->irqinbuf = NULL;
> ihid->inbuf = NULL;
> ihid->cmdbuf = NULL;
> ihid->argsbuf = NULL;
> @@ -521,11 +524,13 @@ static int i2c_hid_alloc_buffers(struct i2c_hid *ihid, size_t report_size)
> sizeof(__u16) + /* size of the report */
> report_size; /* report */
>
> + ihid->irqinbuf = kzalloc(report_size, GFP_KERNEL);
> ihid->inbuf = kzalloc(report_size, GFP_KERNEL);
> ihid->argsbuf = kzalloc(args_len, GFP_KERNEL);
> ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
>
> - if (!ihid->inbuf || !ihid->argsbuf || !ihid->cmdbuf) {
> + if (!ihid->irqinbuf || !ihid->inbuf ||
> + !ihid->argsbuf || !ihid->cmdbuf) {
> i2c_hid_free_buffers(ihid);
> return -ENOMEM;
> }
> --
> 2.1.3
>
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: print the correct data in dbg msg
From: Benjamin Tissoires @ 2014-11-17 21:32 UTC (permalink / raw)
To: Antonio Borneo
Cc: Jiri Kosina, linux-input, linux-kernel, Jean-Baptiste Maneyrol
In-Reply-To: <1416149143-25703-1-git-send-email-borneo.antonio@gmail.com>
On Nov 16 2014 or thereabouts, Antonio Borneo wrote:
> From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
>
> From: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
>
> Report is received in "buffer"; fix the following i2c_hid_dbg()
> to dump data from the correct pointer.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
> [Antonio Borneo: cleanup and rebase to v3.17]
> Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
> ---
Good catch.
This one is Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
> drivers/hid/i2c-hid/i2c-hid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 747d544..933bf10 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -437,7 +437,7 @@ static void i2c_hid_init_report(struct hid_report *report, u8 *buffer,
> report->id, buffer, size))
> return;
>
> - i2c_hid_dbg(ihid, "report (len=%d): %*ph\n", size, size, ihid->inbuf);
> + i2c_hid_dbg(ihid, "report (len=%d): %*ph\n", size, size, buffer);
>
> ret_size = buffer[0] | (buffer[1] << 8);
>
> --
> 2.1.3
>
^ permalink raw reply
* [PATCH] HID: yet another buggy ELAN touchscreen
From: Oliver Neukum @ 2014-11-17 16:11 UTC (permalink / raw)
To: jkosina, linux-input; +Cc: Oliver Neukum, stable
The touchscreen needs the same quirk as the other models.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Reported-by: Bryan Poling <poli0048@umn.edu>
CC: stable@vger.kernel.org
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
drivers/usb/core/quirks.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e23ab8b..282ffbe 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -299,6 +299,7 @@
#define USB_VENDOR_ID_ELAN 0x04f3
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B 0x009b
+#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c 0x010c
#define USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F 0x016f
#define USB_VENDOR_ID_ELECOM 0x056e
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 5014bb5..08b9626 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -72,6 +72,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B, HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_010c, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_016F, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, HID_QUIRK_NO_INIT_REPORTS },
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 39b4081..8e8bc4f 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -100,6 +100,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x04f3, 0x009b), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
+ { USB_DEVICE(0x04f3, 0x010c), .driver_info =
+ USB_QUIRK_DEVICE_QUALIFIER },
+
{ USB_DEVICE(0x04f3, 0x016f), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH 001/001] hid-sony.c: add sysfs provisioning
From: Antonio Ospite @ 2014-11-17 12:35 UTC (permalink / raw)
To: bri
Cc: Frank Praznik, Jiri Kosina, Henrik Rydberg,
open list:HID CORE LAYER, open list, Michael Kerrisk
In-Reply-To: <20141116181846.GA31516@abrij.org>
On Sun, 16 Nov 2014 13:18:46 -0500
bri <bri@abrij.org> wrote:
Hi Brian,
> Add some sysfs interfaces to cover some corner use cases when provisioning:
>
> 1) Allow read access to the IDA index through device/gamepad_number. The
> IDA index is used to identify the device to the user as the "controller number"
> and is reflected via the initial LED states when plugged in. This sysfs
> attribute could be used by userspace for a more seamless transition to
> userspace drivers without controller numbers changing. Write access is not
> addressed as it raises the issue of a global IDA that works across different
> gamepad drivers. Internally, remove the use of the term "device_id" for
> the gamepad number for code grepability purposes.
>
I am not sure about this, Frank can better comment on it.
>From how I always saw it, the IDA for sixaxis controller may be useful
in a scenario when you _only_ have Sixaxis controllers, but if you have
hooked up controllers relying on different drivers, then using the
joystick device numbers instead (i.e. the X in /dev/input/jsX) as
identifier is more reliable IMHO, so that's how the BlueZ sixaxis
plugin sets the LEDs, see:
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/plugins/sixaxis.c
Imagine:
1. plug in a sixaxis (IDA = 0, /dev/input/js0)
2. plug in another joypad (/dev/input/js1)
3. plug in a second sixaxis (IDA = 1, /dev/input/js2)
> 2) Allow manual provisioning of the Sixaxis/Dualshock3 USB "pairing" process
> through device/master_bdaddr. The bluez plugin has removed the need for
> sixpair.c or other such utilities for the common use case of autoprovisioning.
> Under less usual situations, the bluez behavior may not be desired, e.g.
> if you need to pair a gamepad with a different machine, see what machine
> a pad is paired to, or restore old pairings after use. This removes
> the need to use sixpair.c or roll-your-own libusb code for that sort
> of thing.
>
I had tried doing something similar in the past (the parsing was just a
sscanf): http://thread.gmane.org/gmane.linux.bluez.kernel/5261 but then
we deliberately decided against exposing specific sysfs interfaces for
device/master_bdaddr, you can just use generic HID feature reports from
userspace to get/set these, write a simple program reusing the code in
the BlueZ sixaxis plugin, using the ioclts
HIDIOCGFEATURE/HIDIOCSFEATURE, this way you don't depend on libusb. As
an historical note, the BlueZ sixaxis plugin was one of the first user
of these ioctls.
It's true that you still need some code, but when possible it's better
to have code for corner cases in userspace rather than in the kernel.
A more general note, when submitting kernel patches try to send one
patch per logical change, in this case I would have expected several
patches, one for the rename device_id/gamepad_number, one for the IDA
sysfs hook and one for the bdaddrs sysfs hooks. Self contained patches
are easier to review.
I'd also try to avoid custom parsing routines in kernel code as much as
possible.
That said I still don't think the changes you are proposing are strictly
necessary in the kernel driver, but let's see what the others have to
say about that.
Misc comments inlined below.
Thanks,
Antonio
> Signed-off-by: Brian S. Julin <bri@abrij.org>
> Tested-by: Brian S. Julin <bri@abrij.org>
>
> ---
>
> I've tested with both SixAxis and Dualshock 3 on stock Debian kernel 3.16.5.
> I've also tested a copy of the 3.18 git version inserted into the 3.16.5
> kernel. The patch should apply to both (with fuzz on the newer version.)
> Tests are still needed on pure 3.18.
>
You know you can build Debian packages from the official git kernel
repository, don't you?
make LOCALVERSION=-brian INSTALL_MOD_STRIP=1 deb-pkg
When sending kernel patches try to base them on the master branch from
the linus tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> I do not have access to the non-Sony pads handled by this driver, but did
> test the with a Dualshock4 to ensure that the sysfs files are harmless
> vestigials for such devices.
>
> It has been a long time since I popped the hood on the kernel and much
> has changed. I'm unclear as to under what conditions hid-core relieves
> the need to lock. Some review is definitely needed there.
>
> General comment on the driver: when a gamepad being used over
> BT is plugged back in to USB, it continues to use BT rather than
> switching to USB. This has both benefits and disadvantages.
>
> On the bright side, this prevents the evdev and js devices from being
> destroyed and recreated. Some applications, many closed-source, may
> not respond well to that even when udev rules are used to pin the
> device names.
>
Exactly.
> On the other hand this is not the behavior gamers expect and will not
> help matters if the reason for plugging the pad in was to decrease
> latency due to RF contention.
This is an interesting point, can you show numbers about these latency
problems?
> I notice that sysfs-rules.txt mentions that a device's parentage in
> the tree may change, and teaching the hid core to allow graceful
> takeover of a device by a different host/bus driver for these
> devices might be a use case for that.
>
> --- drivers/hid/hid-sony.c.orig 2014-11-05 20:32:47.387599486 -0500
> +++ drivers/hid/hid-sony.c 2014-11-14 20:35:28.327053036 -0500
> @@ -8,6 +8,7 @@
> * Copyright (c) 2012 David Dillow <dave@thedillows.org>
> * Copyright (c) 2006-2013 Jiri Kosina
> * Copyright (c) 2013 Colin Leitner <colin.leitner@gmail.com>
> + * Copyright (c) 2014 Brian S. Julin <bri@abrij.org>
> */
>
> /*
> @@ -35,6 +36,9 @@
> #include <linux/list.h>
> #include <linux/idr.h>
> #include <linux/input/mt.h>
> +#include <linux/ctype.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
A HID driver should not need to depend on bluetooth, no other HID
driver does. Layer violations should be avoided as much as possible.
> #include "hid-ids.h"
>
> @@ -750,7 +754,7 @@ union sixaxis_output_report_01 {
>
> static spinlock_t sony_dev_list_lock;
> static LIST_HEAD(sony_device_list);
> -static DEFINE_IDA(sony_device_id_allocator);
> +static DEFINE_IDA(sony_gamepad_number_allocator);
>
> struct sony_sc {
> spinlock_t lock;
> @@ -760,7 +764,7 @@ struct sony_sc {
> unsigned long quirks;
> struct work_struct state_worker;
> struct power_supply battery;
> - int device_id;
> + int gamepad_number;
As I tried to explain above, the value of this variable won't
corresponds to the "gamepad number" if you have a mixed driver scenario.
>
> #ifdef CONFIG_SONY_FF
> __u8 left;
> @@ -1321,7 +1325,8 @@ static int sony_leds_init(struct sony_sc
> if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 0, 0, 7))
> return -ENODEV;
> } else if (sc->quirks & DUALSHOCK4_CONTROLLER) {
> - dualshock4_set_leds_from_id(sc->device_id, initial_values);
> + dualshock4_set_leds_from_id(sc->gamepad_number,
> + initial_values);
> initial_values[3] = 1;
> sc->led_count = 4;
> memset(max_brightness, 255, 3);
> @@ -1330,7 +1335,7 @@ static int sony_leds_init(struct sony_sc
> name_len = 0;
> name_fmt = "%s:%s";
> } else {
> - sixaxis_set_leds_from_id(sc->device_id, initial_values);
> + sixaxis_set_leds_from_id(sc->gamepad_number, initial_values);
> sc->led_count = 4;
> memset(use_hw_blink, 1, 4);
> use_ds4_names = 0;
> @@ -1758,38 +1763,209 @@ static int sony_check_add(struct sony_sc
> return sony_check_add_dev_list(sc);
> }
>
> -static int sony_set_device_id(struct sony_sc *sc)
> +/* PS3 pads do not pair over bluetooth; Instead a USB handshake is used. */
> +static ssize_t sony_master_bdaddr_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> + struct sony_sc *sc = hid_get_drvdata(hdev);
> + size_t count;
> + unsigned char msg[8];
> + int ret;
> +
> + if (!sc) {
> + hid_err(hdev, "No device data\n");
> + return 0;
> + }
> +
> + if (sc->quirks & SIXAXIS_CONTROLLER_BT) {
> + struct device *parent;
> +
> + parent = dev->parent;
> + if (!parent)
> + return 0;
> + parent = parent->parent;
> + if (!parent || !parent->type
> + || strcmp(parent->type->name, "host"))
> + return 0;
> +
> + count = scnprintf(buf, PAGE_SIZE, "%pMR\n",
> + &(to_hci_dev(parent)->bdaddr));
> + return count;
> + }
> +
> + if (!(sc->quirks & SIXAXIS_CONTROLLER_USB))
> + return 0;
> +
> + ret = hid_hw_raw_request(hdev, 0xf5, msg, sizeof(msg),
> + HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
> + if (ret < 0) {
> + /* This matches bluez error message */
> + hid_err(hdev, "failed to read master address\n");
> + return 0;
> + }
> +
> + count = scnprintf(buf, PAGE_SIZE, "%pM\n", msg + 2);
> + return count;
> +}
> +
> +/*
> + * This could probably be useful in lib/.
> + *
> + * Convert a string to a MAC address, accepting multiple formats.
> + *
> + * Will take most commonly cut-and-pasted formats without being too liberal.
> + * Accepts any hex with delims [-:.] between any octets, no mixing delims,
> + * no splitting octets.
> + *
> + * *buf should have at least 6 bytes of space and will not be altered on fail
> + * Will halt at null terminator or before reading more than lim chars from *c
> + * Return code is sscanf-style: number of non-null bytes read, or 0 on failure
> + */
> +static int sony_kstrntomac(const char *c, u8 *buf, size_t lim)
> +{
> + int cnt = 0;
> + int dcnt = 0;
> + char delim = '\0';
> + u8 octet[6];
> +
> + while (cnt < 6) {
> + if (lim < 2 || !isxdigit(*c) || !isxdigit(*(c+1)))
> + return 0;
> +
> + lim -= 2;
> +
> + if (isdigit(*c))
> + octet[cnt] = (*c - '0') << 4;
> + else
> + octet[cnt] = (tolower(*c) - 'a' + 10) << 4;
> + c++;
> +
> + if (isdigit(*c))
> + octet[cnt] |= *c - '0';
> + else
> + octet[cnt] |= tolower(*c) - 'a' + 10;
> + c++;
> +
> + if (cnt < 5) {
> + if (!lim)
> + return 0;
> + if (!delim && (*c == '-' || *c == ':' || *c == '.'))
> + delim = *c;
> + if (delim && *c == delim) {
> + dcnt++;
> + c++;
> + lim--;
> + }
> + }
> + cnt++;
> + }
> +
> + memcpy(buf, octet, 6);
> +
> + return cnt * 2 + dcnt;
> +}
> +
> +static ssize_t sony_master_bdaddr_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> + struct sony_sc *sc = hid_get_drvdata(hdev);
> + u8 msg[8];
> + int ret;
> +
> + if (!sc) {
> + hid_err(hdev, "No device data\n");
> + return -EBADFD;
> + }
> +
> + if (!(sc->quirks & SIXAXIS_CONTROLLER_USB)) {
> + if (sc->quirks & SIXAXIS_CONTROLLER_BT) {
> + hid_err(hdev,
> + "To set master disconnect BT then use USB\n");
> + return -EOPNOTSUPP;
> + }
> + return -ENOTSUPP;
> + }
> +
> + msg[0] = 0x01;
> + msg[1] = 0x00;
> +
> + if (!sony_kstrntomac(buf, msg + 2, count))
> + return -EINVAL;
> +
> + ret = hid_hw_raw_request(hdev, 0xf5, msg, sizeof(msg),
> + HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
> + if (ret < 0) {
> + /* This matches bluez error message */
> + hid_err(hdev, "failed to write master address\n");
> + return count;
> + }
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(master_bdaddr, S_IRUGO | S_IWUSR,
> + sony_master_bdaddr_show, sony_master_bdaddr_store);
> +
> +static int sony_set_gamepad_number(struct sony_sc *sc)
> {
> int ret;
>
> /*
> - * Only DualShock 4 or Sixaxis controllers get an id.
> + * Only DualShock 4 or Sixaxis controllers get a number.
> * All others are set to -1.
> */
> if ((sc->quirks & SIXAXIS_CONTROLLER) ||
> (sc->quirks & DUALSHOCK4_CONTROLLER)) {
> - ret = ida_simple_get(&sony_device_id_allocator, 0, 0,
> - GFP_KERNEL);
> + ret = ida_simple_get(&sony_gamepad_number_allocator, 0, 0,
> + GFP_KERNEL);
> if (ret < 0) {
> - sc->device_id = -1;
> + sc->gamepad_number = -1;
> return ret;
> }
> - sc->device_id = ret;
> + sc->gamepad_number = ret;
> } else {
> - sc->device_id = -1;
> + sc->gamepad_number = -1;
> }
>
> return 0;
> }
>
> -static void sony_release_device_id(struct sony_sc *sc)
> +static void sony_release_gamepad_number(struct sony_sc *sc)
> {
> - if (sc->device_id >= 0) {
> - ida_simple_remove(&sony_device_id_allocator, sc->device_id);
> - sc->device_id = -1;
> + if (sc->gamepad_number >= 0) {
> + ida_simple_remove(&sony_gamepad_number_allocator,
> + sc->gamepad_number);
> + sc->gamepad_number = -1;
> }
> }
>
> +static ssize_t sony_gamepad_number_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> + struct sony_sc *sc = hid_get_drvdata(hdev);
> + size_t count;
> +
> + if (!sc) {
> + hid_err(hdev, "No device data\n");
> + return 0;
> + }
> +
> + if (sc->gamepad_number < 0)
> + return 0;
> +
> + /* Add one to match console user expectations */
> + count = scnprintf(buf, PAGE_SIZE, "%i\n", sc->gamepad_number + 1);
> + return count;
> +}
> +
> +static DEVICE_ATTR(gamepad_number, S_IRUGO, sony_gamepad_number_show, NULL);
> +
> static inline void sony_init_work(struct sony_sc *sc,
> void (*worker)(struct work_struct *))
> {
> @@ -1841,10 +2017,22 @@ static int sony_probe(struct hid_device
> return ret;
> }
>
> - ret = sony_set_device_id(sc);
> + ret = sony_set_gamepad_number(sc);
> if (ret < 0) {
> - hid_err(hdev, "failed to allocate the device id\n");
> - goto err_stop;
> + hid_err(hdev, "failed to allocate the gamepad number\n");
> + goto err_nosysfs2;
> + }
> +
> + ret = device_create_file(&hdev->dev, &dev_attr_gamepad_number);
> + if (ret) {
> + hid_err(hdev, "failed to create gamepad_number sysfs file\n");
> + goto err_nosysfs2;
> + }
> +
> + ret = device_create_file(&hdev->dev, &dev_attr_master_bdaddr);
> + if (ret) {
> + hid_err(hdev, "failed to create master_bdaddr sysfs file\n");
> + goto err_nosysfs1;
> }
>
> if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
> @@ -1932,13 +2120,17 @@ static int sony_probe(struct hid_device
> err_close:
> hid_hw_close(hdev);
> err_stop:
> + device_remove_file(&hdev->dev, &dev_attr_master_bdaddr);
> +err_nosysfs1:
> + device_remove_file(&hdev->dev, &dev_attr_gamepad_number);
> +err_nosysfs2:
> if (sc->quirks & SONY_LED_SUPPORT)
> sony_leds_remove(sc);
> if (sc->quirks & SONY_BATTERY_SUPPORT)
> sony_battery_remove(sc);
> sony_cancel_work_sync(sc);
> sony_remove_dev_list(sc);
> - sony_release_device_id(sc);
> + sony_release_gamepad_number(sc);
> hid_hw_stop(hdev);
> return ret;
> }
> @@ -1959,7 +2151,11 @@ static void sony_remove(struct hid_devic
>
> sony_remove_dev_list(sc);
>
> - sony_release_device_id(sc);
> + device_remove_file(&hdev->dev, &dev_attr_master_bdaddr);
> +
> + device_remove_file(&hdev->dev, &dev_attr_gamepad_number);
> +
> + sony_release_gamepad_number(sc);
>
> hid_hw_stop(hdev);
> }
> @@ -2017,7 +2213,7 @@ static void __exit sony_exit(void)
> {
> dbg_hid("Sony:%s\n", __func__);
>
> - ida_destroy(&sony_device_id_allocator);
> + ida_destroy(&sony_gamepad_number_allocator);
> hid_unregister_driver(&sony_driver);
> }
> module_init(sony_init);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* Re: [PATCH 0/4] Touchscreen performance related fixes
From: Vignesh R @ 2014-11-17 12:18 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Griffis, Brad, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Benoit Cousson,
Tony Lindgren, Russell King, Jonathan Cameron, Dmitry Torokhov
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz,
Lee Jones, Balbi, Felipe, Jan Kardell, Paul Gortmaker,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-iio@vger.kernel.org, linux-input@vger.kernel.org
In-Reply-To: <5458C87F.80409@linutronix.de>
On Tuesday 04 November 2014 06:07 PM, Sebastian Andrzej Siewior wrote:
> On 11/04/2014 12:44 PM, Vignesh R wrote:
>
>> I ran following commands
>> $ evtest /dev/input/touchscreen0 &
>> (with heavy item on touchscreen)
>> and
>> $ cat /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage4_en
>> (in a busy loop)
>> I tried above experiment on my board but I didn't hit any problem even
>> after running for close to 30 minutes. I was unable to reproduce failure
>
> Just to make sure: You had the touchscreen and iio command running in
> parallel and you saw evtest output while there was iio operation?
>
>> The problem may be in configuring correct charge-delay value. Please run:
>> $ ts_test > /dev/null
>> and let me know if pen events are being detected properly.
>
> Well I get the touch events but not while busy loop on iio interface is
> running (I get maybe one event every 5 seconds or so).
> After all, it is the same HW you have.
Were you able to test the latest version (v4) of this patch series?
Please let me know if the performance is satisfactory.
Regards
Vignesh
>
> Sebastian
> --
> 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 v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Vignesh R @ 2014-11-17 12:18 UTC (permalink / raw)
To: Richard Cochran
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, Dmitry Torokhov, Lee Jones,
Sebastian Andrzej Siewior, Lars-Peter Clausen, Peter Meerwald,
Samuel Ortiz, Felipe Balbi, Brad Griffis, Sanjeev Sharma,
Paul Gortmaker, Jan Kardell, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap
In-Reply-To: <20141117082337.GA3946-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Monday 17 November 2014 01:53 PM, Richard Cochran wrote:
> On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote:
>> My patches are based on v3.18rc2. I tested my patches on am335x-evm
>> using tslib.
>
> No beaglebone + cape testing?
>
>> Please explain "touch is broken"? What is the behaviour of TSC?
>
> With plain v3.17 plus your series, the cursor is almost never near the
> pen. Mostly it jitters around the right hand edge.
>
> My customer had already changed the step delay (I think by trial and
> error, not sure) in order to get the cursor near the pen. I ported
> this change onto your series (see patch, below), but still the pen up
> event causes a huge cursor jump.
>
> (Again, I did solve the pen up issue, but in a totally different
> way. I never posted the fix, because I could not be sure that it would
> work on a wide variety of boards.)
>
>> Which ADC channels are being used for TSC?
>
> &tscadc {
> status = "okay";
> tsc {
> ti,wires = <4>;
> ti,x-plate-resistance = <300>;
> ti,coordinate-readouts = <5>;
> ti,wire-config = <0x00 0x11 0x23 0x32>;
> };
What is the ti,charge-delay value you have tried?
Try setting it to 0xB000 and experiment.
>
> adc {
> ti,adc-channels = <5 6 7>;
> };
> };
>
> So for this particular design, your series really does not help, not
> even a little. You did not test the series on many boards. I am
> concerned that this series only works on the one board you did test,
> and that it may break functionality on other people's boards.
>
I just have one am335x-evm available. I will search for a beaglebone
cape and test the patches. Let Sebastian, Johannes come back with their
results. If the series works on multiple boards then, I believe, this
series can go in.
Regards
Vignesh
> Thanks,
> Richard
>
> ---
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
> index b84493f..77a4883 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -148,7 +148,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> end_step = first_step + tsc_steps;
> for (i = end_step - ts_dev->coordinate_readouts; i < end_step; i++) {
> titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
> - titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
> + titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
> }
>
> config = 0;
> @@ -172,7 +172,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> end_step = first_step + ts_dev->coordinate_readouts;
> for (i = first_step; i < end_step; i++) {
> titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
> - titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
> + titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
> }
>
> /* Make CHARGECONFIG same as IDLECONFIG */
> @@ -188,13 +188,13 @@ static void titsc_step_config(struct titsc *ts_dev)
> STEPCONFIG_INP(ts_dev->inp_xp);
> titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
> titsc_writel(ts_dev, REG_STEPDELAY(end_step),
> - STEPCONFIG_OPENDLY);
> + STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
>
> end_step++;
> config |= STEPCONFIG_INP(ts_dev->inp_yn);
> titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
> titsc_writel(ts_dev, REG_STEPDELAY(end_step),
> - STEPCONFIG_OPENDLY);
> + STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
>
> /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
> stepenable = 1;
>
^ permalink raw reply
* Re: [PATCH 0/4] Touchscreen performance related fixes
From: Vignesh R @ 2014-11-17 11:39 UTC (permalink / raw)
To: Johannes Pointner
Cc: Richard Cochran, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Benoit Cousson, Tony Lindgren,
Russell King, Jonathan Cameron, Dmitry Torokhov,
devicetree-u79uwXL29TY76Z2rM5mHXA, Lars-Peter Clausen,
Samuel Ortiz, Jan Kardell, linux-iio, Sebastian Andrzej Siewior,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi, Paul Gortmaker,
Peter Meerwald, Hartmut Knaack, linux-om
In-Reply-To: <5464A2B5.3020207-l0cyMroinI0@public.gmane.org>
Hi,
On Thursday 13 November 2014 05:53 PM, Vignesh R wrote:
> Hi,
>
> On Wednesday 12 November 2014 06:30 PM, Johannes Pointner wrote:
>> Hello Vignesh,
>>
>> I tried your patch version 3 on a customized board and had some
>> behavior I couldn't explain.
>> If I only use the touchscreen it works fine but if I also read values
>> from the ADCs then I get a lot of pen_up events even if I am still
>> touching the screen.
>> For the test I read via
>> # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw
>> values from the ADC in an busy loop as you explained in an email
>> before. Did you also experience such behavior or do you know what
>> causes it?
>
> Thanks for testing. I was able to fix this issue. Will post version 4
> shortly.
>
Were you able to test the v4 patch series on your board? Is the issue fixed?
> Regards
> Vignesh
>
>>
>> Without the patches the touchscreen works fine during the iio test.
>>
>> Thanks,
>> Hannes
>>
>> 2014-11-06 8:42 GMT+01:00 Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>:
>>>
>>>
>>> On Monday 03 November 2014 11:39 PM, Richard Cochran wrote:
>>>> On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote:
>>>>> This series of patches fix TSC defects related to lag in touchscreen
>>>>> performance and cursor jump at touch release. The lag was result of
>>>>> udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
>>>>> The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
>>>>> to avoid false pen-up events and remove udelay.
>>>>
>>>> That advisory has two workarounds. You have chosen the second one?
>>>
>>> Work around one. Hence 5 wire design is not broken.
>>>
>>>>
>>>> The text of the second workaround says it only works on 4 wire setups,
>>>> so I wonder how 5 wire designs will be affected.
>>>>
>>>>> The advisory says to use
>>>>> steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel
>>>>> ADC).
>>>>
>>>> No, it doesn't say that. (sprz360f.pdf)
>>>
>>> The pen up event detection happens immediately after charge step. Hence,
>>> interchanging ADC and TSC steps makes sure that sampling of touch
>>> co-ordinates and pen events are done one after the other. This
>>> workaround was suggested by internal hardware folks. Earlier ADC steps
>>> intervened between sampling of co-ordinates and pen event detection
>>> which is not desirable.
>>>
>>>>
>>>>> Further the X co-ordinate must be the last one to be sampled just
>>>>> before charge step. The first two patches implement the required changes.
>>>>
>>>> FWIW, I implemented the first workaround and removed the udelay not
>>>> too long ago. Like Sebastian, I saw the TSC unit hang after about
>>>> 50000 interrupts when running with the workaround.
>>>>
>>>> Did you test you patch for very long?
>>>
>>> Yes, I tested for about 200000 interrupts and I didn't see any hang.
>>> This patch series does not just implement workaround but also does some
>>> minor changes, such as interchanging ADC and TSC steps etc, which makes
>>> TSC driver more robust. Let me know if you encounter any issues with my
>>> patch series.
>>>
>>> Regards
>>> Vignesh
>>>
>>>>
>>>> Thanks,
>>>> Richard
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Richard Cochran @ 2014-11-17 8:23 UTC (permalink / raw)
To: Vignesh R
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, Dmitry Torokhov, Lee Jones,
Sebastian Andrzej Siewior, Lars-Peter Clausen, Peter Meerwald,
Samuel Ortiz, Felipe Balbi, Brad Griffis, Sanjeev Sharma,
Paul Gortmaker, Jan Kardell, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap
In-Reply-To: <54697919.5030302-l0cyMroinI0@public.gmane.org>
On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote:
> My patches are based on v3.18rc2. I tested my patches on am335x-evm
> using tslib.
No beaglebone + cape testing?
> Please explain "touch is broken"? What is the behaviour of TSC?
With plain v3.17 plus your series, the cursor is almost never near the
pen. Mostly it jitters around the right hand edge.
My customer had already changed the step delay (I think by trial and
error, not sure) in order to get the cursor near the pen. I ported
this change onto your series (see patch, below), but still the pen up
event causes a huge cursor jump.
(Again, I did solve the pen up issue, but in a totally different
way. I never posted the fix, because I could not be sure that it would
work on a wide variety of boards.)
> Which ADC channels are being used for TSC?
&tscadc {
status = "okay";
tsc {
ti,wires = <4>;
ti,x-plate-resistance = <300>;
ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x23 0x32>;
};
adc {
ti,adc-channels = <5 6 7>;
};
};
So for this particular design, your series really does not help, not
even a little. You did not test the series on many boards. I am
concerned that this series only works on the one board you did test,
and that it may break functionality on other people's boards.
Thanks,
Richard
---
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index b84493f..77a4883 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -148,7 +148,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + tsc_steps;
for (i = end_step - ts_dev->coordinate_readouts; i < end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
}
config = 0;
@@ -172,7 +172,7 @@ static void titsc_step_config(struct titsc *ts_dev)
end_step = first_step + ts_dev->coordinate_readouts;
for (i = first_step; i < end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
- titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
}
/* Make CHARGECONFIG same as IDLECONFIG */
@@ -188,13 +188,13 @@ static void titsc_step_config(struct titsc *ts_dev)
STEPCONFIG_INP(ts_dev->inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
end_step++;
config |= STEPCONFIG_INP(ts_dev->inp_yn);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
- STEPCONFIG_OPENDLY);
+ STEPCONFIG_OPENDLY | STEPDELAY_SAMPLE(20));
/* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
stepenable = 1;
^ permalink raw reply related
* Re: [PATCH 0/7] Fixes for ALPS trackstick
From: Pali Rohár @ 2014-11-17 7:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Hans de Goede, Yunkang Tang, Vadim Klishko, linux-input,
linux-kernel
In-Reply-To: <1541270.g199T8YFIC@dtor-glaptop>
[-- Attachment #1: Type: Text/Plain, Size: 967 bytes --]
On Friday 14 November 2014 21:59:31 Dmitry Torokhov wrote:
> Hi Pali,
>
> On Friday, November 14, 2014 08:38:19 PM Pali Rohár wrote:
> > This patch series fix detection and identifying trackstick
> > on machines with ALPS devices. Last patch split trackstick
> > and bare PS/2 mouse packets between dev2 and dev3 input
> > devices which make sure that driver will send only
> > trackstick data to trackstick input device.
>
> Thank you for splitting the change, unfortunately it is now
> quite big to apply to 3.18. Any chance you could try
> implementing what I suggested in
> http://www.spinics.net/lists/linux-input/msg34029.html and
> then we can do the more comprehensive solution in 3.19.
>
> Thanks.
Hello, I think that patches 1/7 and 5/7 could do that job. I did
not tested them alone (without other patches), but if you think
that two patches are ok for 3.18 & stable I can test them...
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [ASUS X550LA] The trackpad is not recognized
From: Ben Lansdell @ 2014-11-17 6:37 UTC (permalink / raw)
To: linux-input
[1.] [ASUS X550LA] The trackpad is not recognized
[2.] Touchpad is detected as a mouse. It works but with no multi-touch
or scrolling functionality.
xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ PS/2 FocalTech FocalTech Touchpad in mouse emulation mode id=13
[slave pointer (2)]
This bug exists on kernel 3.18-rc4
[3.]
[4.] Linux version 3.18.0-031800rc4-generic (apw@gomeisa) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411091835 SMP Sun Nov 9
23:36:36 UTC 2014
[5.] n/a
[6.] n/a
[7.] lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04
[7.1.] sh ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux juneau 3.18.0-031800rc4-generic #201411091835 SMP Sun Nov 9
23:36:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Gnu C 4.8
Gnu make 3.81
binutils 2.24
util-linux 2.20.1
mount support
module-init-tools 15
e2fsprogs 1.42.9
pcmciautils 018
PPP 2.4.5
Linux C Library 2.19
Dynamic linker (ldd) 2.19
Procps 3.3.9
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.21
wireless-tools 30
Modules Loaded ctr ccm rfcomm bnep bluetooth binfmt_misc
nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_hdmi
snd_hda_codec_generic snd_soc_rt5640 snd_soc_rl6231 snd_hda_intel
intel_rapl snd_soc_core snd_hda_controller arc4 snd_hda_codec
snd_compress snd_pcm_dmaengine snd_hwdep snd_pcm snd_seq_midi
snd_seq_midi_event rt2800pci x86_pkg_temp_thermal rt2800mmio
snd_rawmidi intel_powerclamp rt2800lib coretemp rt2x00pci rt2x00mmio
kvm_intel rt2x00lib kvm asus_nb_wmi crct10dif_pclmul asus_wmi mac80211
i915 snd_seq crc32_pclmul cfg80211 ghash_clmulni_intel aesni_intel
uvcvideo aes_x86_64 sparse_keymap lrw videobuf2_vmalloc snd_seq_device
snd_timer videobuf2_memops gf128mul eeprom_93cx6 videobuf2_core
i2c_hid v4l2_common crc_ccitt drm_kms_helper snd drm videodev
glue_helper ablk_helper i2c_designware_platform serio_raw cryptd media
i2c_designware_core parport_pc soundcore ppdev wmi i2c_algo_bit
dm_multipath rtsx_pci_ms snd_soc_sst_acpi lp dw_dmac mei_me
dw_dmac_core memstick mei parport lpc_ich 8250_dw video
int3400_thermal int3402_thermal acpi_thermal_rel scsi_dh
spi_pxa2xx_platform mac_hid hid_logitech_dj usbhid hid rtsx_pci_sdmmc
psmouse ahci r8169 rtsx_pci libahci mii sdhci_acpi sdhci
[7.2.] cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 69
model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping : 1
microcode : 0x17
cpu MHz : 1499.941
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4588.97
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 69
model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping : 1
microcode : 0x17
cpu MHz : 1500.031
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4588.97
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 69
model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping : 1
microcode : 0x17
cpu MHz : 1500.121
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4588.97
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 69
model name : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping : 1
microcode : 0x17
cpu MHz : 1500.121
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs :
bogomips : 4588.97
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
[7.3.] cat /proc/modules
ctr 13193 1 - Live 0x0000000000000000
ccm 17856 1 - Live 0x0000000000000000
rfcomm 75066 0 - Live 0x0000000000000000
bnep 23980 2 - Live 0x0000000000000000
bluetooth 486890 10 rfcomm,bnep, Live 0x0000000000000000
binfmt_misc 17501 1 - Live 0x0000000000000000
nls_iso8859_1 12713 1 - Live 0x0000000000000000
snd_hda_codec_realtek 80418 1 - Live 0x0000000000000000
snd_hda_codec_hdmi 52670 1 - Live 0x0000000000000000
snd_hda_codec_generic 69995 1 snd_hda_codec_realtek, Live 0x0000000000000000
snd_soc_rt5640 93325 0 - Live 0x0000000000000000
snd_soc_rl6231 13037 1 snd_soc_rt5640, Live 0x0000000000000000
snd_hda_intel 30783 5 - Live 0x0000000000000000
intel_rapl 19196 0 - Live 0x0000000000000000
snd_soc_core 207596 1 snd_soc_rt5640, Live 0x0000000000000000
snd_hda_controller 32234 1 snd_hda_intel, Live 0x0000000000000000
arc4 12573 2 - Live 0x0000000000000000
snd_hda_codec 144641 5
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller,
Live 0x0000000000000000
snd_compress 19395 1 snd_soc_core, Live 0x0000000000000000
snd_pcm_dmaengine 15229 1 snd_soc_core, Live 0x0000000000000000
snd_hwdep 17709 1 snd_hda_codec, Live 0x0000000000000000
snd_pcm 106273 7
snd_hda_codec_hdmi,snd_soc_rt5640,snd_hda_intel,snd_soc_core,snd_hda_controller,snd_hda_codec,snd_pcm_dmaengine,
Live 0x0000000000000000
snd_seq_midi 13564 0 - Live 0x0000000000000000
snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
rt2800pci 13674 0 - Live 0x0000000000000000
x86_pkg_temp_thermal 14312 0 - Live 0x0000000000000000
rt2800mmio 21082 1 rt2800pci, Live 0x0000000000000000
snd_rawmidi 31197 1 snd_seq_midi, Live 0x0000000000000000
intel_powerclamp 19099 0 - Live 0x0000000000000000
rt2800lib 95583 2 rt2800pci,rt2800mmio, Live 0x0000000000000000
coretemp 13638 0 - Live 0x0000000000000000
rt2x00pci 13287 1 rt2800pci, Live 0x0000000000000000
rt2x00mmio 13661 2 rt2800pci,rt2800mmio, Live 0x0000000000000000
kvm_intel 149984 0 - Live 0x0000000000000000
rt2x00lib 56113 5 rt2800pci,rt2800mmio,rt2800lib,rt2x00pci,rt2x00mmio,
Live 0x0000000000000000
kvm 475233 1 kvm_intel, Live 0x0000000000000000
asus_nb_wmi 21128 0 - Live 0x0000000000000000
crct10dif_pclmul 14268 0 - Live 0x0000000000000000
asus_wmi 24697 1 asus_nb_wmi, Live 0x0000000000000000
mac80211 697143 3 rt2800lib,rt2x00pci,rt2x00lib, Live 0x0000000000000000
i915 1031913 7 - Live 0x0000000000000000
snd_seq 63540 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
crc32_pclmul 13180 0 - Live 0x0000000000000000
cfg80211 520257 2 rt2x00lib,mac80211, Live 0x0000000000000000
ghash_clmulni_intel 13230 0 - Live 0x0000000000000000
aesni_intel 169686 2 - Live 0x0000000000000000
uvcvideo 86723 0 - Live 0x0000000000000000
aes_x86_64 17131 1 aesni_intel, Live 0x0000000000000000
sparse_keymap 13890 1 asus_wmi, Live 0x0000000000000000
lrw 13323 1 aesni_intel, Live 0x0000000000000000
videobuf2_vmalloc 13216 1 uvcvideo, Live 0x0000000000000000
snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000
snd_timer 30118 2 snd_pcm,snd_seq, Live 0x0000000000000000
videobuf2_memops 13362 1 videobuf2_vmalloc, Live 0x0000000000000000
gf128mul 14951 1 lrw, Live 0x0000000000000000
eeprom_93cx6 13344 1 rt2800pci, Live 0x0000000000000000
videobuf2_core 51547 1 uvcvideo, Live 0x0000000000000000
i2c_hid 19065 0 - Live 0x0000000000000000
v4l2_common 15715 1 videobuf2_core, Live 0x0000000000000000
crc_ccitt 12707 1 rt2800lib, Live 0x0000000000000000
drm_kms_helper 99802 1 i915, Live 0x0000000000000000
snd 84025 23 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_soc_core,snd_hda_codec,snd_compress,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
Live 0x0000000000000000
drm 323675 6 i915,drm_kms_helper, Live 0x0000000000000000
videodev 163831 3 uvcvideo,videobuf2_core,v4l2_common, Live 0x0000000000000000
glue_helper 14095 1 aesni_intel, Live 0x0000000000000000
ablk_helper 13597 1 aesni_intel, Live 0x0000000000000000
i2c_designware_platform 13025 0 - Live 0x0000000000000000
serio_raw 13483 0 - Live 0x0000000000000000
cryptd 20531 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live
0x0000000000000000
media 22008 2 uvcvideo,videodev, Live 0x0000000000000000
i2c_designware_core 14990 1 i2c_designware_platform, Live 0x0000000000000000
parport_pc 32909 0 - Live 0x0000000000000000
soundcore 15091 2 snd_hda_codec,snd, Live 0x0000000000000000
ppdev 17711 0 - Live 0x0000000000000000
wmi 19379 1 asus_wmi, Live 0x0000000000000000
i2c_algo_bit 13564 1 i915, Live 0x0000000000000000
dm_multipath 23188 0 - Live 0x0000000000000000
rtsx_pci_ms 18337 0 - Live 0x0000000000000000
snd_soc_sst_acpi 13007 0 - Live 0x0000000000000000
lp 17799 0 - Live 0x0000000000000000
dw_dmac 12835 0 - Live 0x0000000000000000
mei_me 19565 0 - Live 0x0000000000000000
dw_dmac_core 28558 1 dw_dmac, Live 0x0000000000000000
memstick 16968 1 rtsx_pci_ms, Live 0x0000000000000000
mei 88473 1 mei_me, Live 0x0000000000000000
parport 42481 3 parport_pc,ppdev,lp, Live 0x0000000000000000
lpc_ich 21176 0 - Live 0x0000000000000000
8250_dw 13474 0 - Live 0x0000000000000000
video 20649 2 asus_wmi,i915, Live 0x0000000000000000
int3400_thermal 13040 0 - Live 0x0000000000000000
int3402_thermal 13060 0 - Live 0x0000000000000000
acpi_thermal_rel 13807 1 int3400_thermal, Live 0x0000000000000000
scsi_dh 14873 1 dm_multipath, Live 0x0000000000000000
spi_pxa2xx_platform 23256 0 - Live 0x0000000000000000
mac_hid 13275 0 - Live 0x0000000000000000
hid_logitech_dj 18569 0 - Live 0x0000000000000000
usbhid 53155 0 - Live 0x0000000000000000
hid 110572 4 i2c_hid,hid_logitech_dj,usbhid, Live 0x0000000000000000
rtsx_pci_sdmmc 23718 0 - Live 0x0000000000000000
psmouse 118117 0 - Live 0x0000000000000000
ahci 34220 3 - Live 0x0000000000000000
r8169 86907 0 - Live 0x0000000000000000
rtsx_pci 51162 2 rtsx_pci_ms,rtsx_pci_sdmmc, Live 0x0000000000000000
libahci 32446 1 ahci, Live 0x0000000000000000
mii 13981 1 r8169, Live 0x0000000000000000
sdhci_acpi 13502 0 - Live 0x0000000000000000
sdhci 43929 1 sdhci_acpi, Live 0x0000000000000000
[7.4.] cat /proc/ioports
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : PNP0C09:00
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : PNP0C09:00
0066-0066 : EC cmd
0070-0077 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0240-0259 : pnp 00:05
04d0-04d1 : pnp 00:04
0680-069f : pnp 00:01
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
164e-164f : pnp 00:01
1800-1803 : ACPI PM1a_EVT_BLK
1804-1805 : ACPI PM1a_CNT_BLK
1808-180b : ACPI PM_TMR
1810-1815 : ACPI CPU throttle
1830-1833 : iTCO_wdt
1850-1850 : ACPI PM2_CNT_BLK
1854-1857 : pnp 00:03
1860-187f : iTCO_wdt
1880-189f : ACPI GPE0_BLK
1c00-1cfe : pnp 00:01
1d00-1dfe : pnp 00:01
1e00-1efe : pnp 00:01
1f00-1ffe : pnp 00:01
2000-2fff : PCI Bus 0000:01
3000-3fff : PCI Bus 0000:03
e000-efff : PCI Bus 0000:02
e000-e0ff : 0000:02:00.1
e000-e0ff : r8169
f000-f03f : 0000:00:02.0
f040-f05f : 0000:00:1f.3
f060-f07f : 0000:00:1f.2
f060-f07f : ahci
f080-f083 : 0000:00:1f.2
f080-f083 : ahci
f090-f097 : 0000:00:1f.2
f090-f097 : ahci
f0a0-f0a3 : 0000:00:1f.2
f0a0-f0a3 : ahci
f0b0-f0b7 : 0000:00:1f.2
f0b0-f0b7 : ahci
ffff-ffff : pnp 00:01
ffff-ffff : pnp 00:01
ffff-ffff : pnp 00:01
cat /proc/iomem
00000000-00000fff : reserved
00001000-00057fff : System RAM
00058000-00058fff : reserved
00059000-0009dfff : System RAM
0009e000-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c3fff : PCI Bus 0000:00
000c4000-000c7fff : PCI Bus 0000:00
000c8000-000cbfff : PCI Bus 0000:00
000cc000-000cffff : PCI Bus 0000:00
000d0000-000d3fff : PCI Bus 0000:00
000d4000-000d7fff : PCI Bus 0000:00
000d8000-000dbfff : PCI Bus 0000:00
000dc000-000dffff : PCI Bus 0000:00
000f0000-000fffff : System ROM
00100000-d5be1fff : System RAM
02000000-027b1c17 : Kernel code
027b1c18-02d19c7f : Kernel data
02e80000-02fc8fff : Kernel bss
d5be2000-d5be8fff : ACPI Non-volatile Storage
d5be9000-d63f6fff : System RAM
d63f7000-d664ffff : reserved
d6650000-d9961fff : System RAM
d9962000-d9b56fff : reserved
d9b57000-d9e94fff : System RAM
d9e95000-dab5dfff : ACPI Non-volatile Storage
dab5e000-daf59fff : reserved
daf5a000-daffefff : reserved
dafff000-daffffff : System RAM
db000000-dbbfffff : RAM buffer
dbc00000-dfdfffff : reserved
dbe00000-dfdfffff : Graphics Stolen Memory
dfe00000-feafffff : PCI Bus 0000:00
dfe00000-dfffffff : PCI Bus 0000:01
e0000000-efffffff : 0000:00:02.0
f0000000-f01fffff : PCI Bus 0000:01
f0200000-f03fffff : PCI Bus 0000:02
f0400000-f05fffff : PCI Bus 0000:03
f7800000-f7bfffff : 0000:00:02.0
f7c00000-f7cfffff : PCI Bus 0000:03
f7c00000-f7c0ffff : 0000:03:00.1
f7c10000-f7c1ffff : 0000:03:00.0
f7c10000-f7c1ffff : 0000:03:00.0
f7d00000-f7dfffff : PCI Bus 0000:02
f7d00000-f7d0ffff : 0000:02:00.0
f7d10000-f7d13fff : 0000:02:00.1
f7d10000-f7d13fff : r8169
f7d14000-f7d14fff : 0000:02:00.1
f7d14000-f7d14fff : r8169
f7d15000-f7d15fff : 0000:02:00.0
f7d15000-f7d15fff : rtsx_pci
f7e00000-f7e0ffff : 0000:00:14.0
f7e00000-f7e0ffff : xhci-hcd
f7e10000-f7e17fff : 0000:00:04.0
f7e18000-f7e1bfff : 0000:00:1b.0
f7e18000-f7e1bfff : ICH HD audio
f7e1c000-f7e1ffff : 0000:00:03.0
f7e1c000-f7e1ffff : ICH HD audio
f7e20000-f7e20fff : 0000:00:1f.6
f7e21000-f7e210ff : 0000:00:1f.3
f7e22000-f7e227ff : 0000:00:1f.2
f7e22000-f7e227ff : ahci
f7e23000-f7e233ff : 0000:00:1d.0
f7e23000-f7e233ff : ehci_hcd
f7e25000-f7e2501f : 0000:00:16.0
f7e25000-f7e2501f : mei_me
f7fdf000-f7fdffff : pnp 00:09
f7fe0000-f7feffff : pnp 00:09
f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
f8000000-fbffffff : reserved
f8000000-fbffffff : pnp 00:09
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed03fff : reserved
fed00000-fed003ff : HPET 0
fed00000-fed003ff : PNP0103:00
fed10000-fed17fff : pnp 00:09
fed18000-fed18fff : pnp 00:09
fed19000-fed19fff : pnp 00:09
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:09
fed1f410-fed1f414 : iTCO_wdt
fed20000-fed3ffff : pnp 00:09
fed40000-fed44fff : pnp 00:00
fed45000-fed8ffff : pnp 00:09
fed90000-fed93fff : pnp 00:09
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff000000-ffffffff : reserved
ff000000-ffffffff : INT0800:00
ff000000-ffffffff : pnp 00:09
100000000-21f1fffff : System RAM
21f200000-21fffffff : RAM buffer
[7.5.] sudo lspci -vvv
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4122
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory at f7e1c000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41c3
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
Kernel driver in use: snd_hda_intel
00:04.0 Signal processing controller: Intel Corporation Device 0a03 (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 255
Region 0: Memory at f7e10000 (64-bit, non-prefetchable) [size=32K]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC
(rev 04) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 201f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 40
Region 0: Memory at f7e00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41d3
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation Lynx Point-LP HECI
#0 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f7e25000 (64-bit, non-prefetchable) [size=32]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41a3
Kernel driver in use: mei_me
00:1b.0 Audio device: Intel Corporation Lynx Point-LP HD Audio
Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 11af
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 46
Region 0: Memory at f7e18000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41b3
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable- ID=2 ArbSelect=Fixed TC/VC=04
Status: NegoPending- InProgress-
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root
Port 1 (rev e4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
<1us, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Via
WAKE# ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF
Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 131d
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root
Port 3 (rev e4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: f7d00000-f7dfffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
<512ns, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #2, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not
Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF
Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 131d
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [200 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root
Port 4 (rev e4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f7c00000-f7cfffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
<512ns, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR+, OBFF Not
Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF
Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 131d
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v0] #00
Capabilities: [200 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=40us PortTPowerOnTime=10us
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1
(rev 04) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device 201f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f7e23000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation Lynx Point-LP LPC Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 SATA controller: Intel Corporation Lynx Point-LP SATA
Controller 1 [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 42
Region 0: I/O ports at f0b0 [size=8]
Region 1: I/O ports at f0a0 [size=4]
Region 2: I/O ports at f090 [size=8]
Region 3: I/O ports at f080 [size=4]
Region 4: I/O ports at f060 [size=32]
Region 5: Memory at f7e22000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0500c Data: 41c1
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation Lynx Point-LP SMBus Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 255
Region 0: Memory at f7e21000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at f040 [size=32]
00:1f.6 Signal processing controller: Intel Corporation Lynx Point-LP
Thermal (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 131d
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 255
Region 0: Memory at f7e20000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
Device 5287 (rev 01)
Subsystem: ASUSTeK Computer Inc. Device 202f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 41
Region 0: Memory at f7d15000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at f7d00000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 41b1
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Via
message/WAKE#
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=1 Masked-
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities: [d0] Vital Product Data
Not readable
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [170 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [178 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
Kernel driver in use: rtsx_pci
02:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
Subsystem: ASUSTeK Computer Inc. Device 200f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 43
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at f7d14000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory at f7d10000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41d1
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Via
message/WAKE#
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [160 v1] Device Serial Number 18-72-72-11-68-4c-e0-00
Capabilities: [170 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [178 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
Kernel driver in use: r8169
03:00.0 Network controller: Ralink corp. RT3290 Wireless 802.11n 1T/1R PCIe
Subsystem: Foxconn International, Inc. Device e055
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at f7c10000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF
Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-d5-be-57-30-35-54
Kernel driver in use: rt2800pci
03:00.1 Bluetooth: Ralink corp. RT3290 Bluetooth
Subsystem: Foxconn International, Inc. Device e056
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 255
Region 0: Memory at f7c00000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns, L1 <2us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF
Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-d6-be-57-30-35-54
[7.6.] cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST1000LM024 HN-M Rev: 0001
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Slimtype Model: DVD A DA8A5SH-L Rev: RAA1
Type: CD-ROM ANSI SCSI revision: 05
[7.7.] ls /proc
1 11698 13077 1453 1777 1928 2048 2221 25 2819 2940
41 5393 8 acpi interrupts mounts timer_list
10 11816 13121 1459 1779 1936 2051 2229 2527 2821 298
414 54 818 asound iomem mtrr timer_stats
1018 11821 13395 146 18 1940 2055 2231 2546 2822 3
415 5417 837 buddyinfo ioports net tty
1022 12 13653 1467 1847 1964 2060 2234 2548 2826 304
4189 55 844 bus irq pagetypeinfo uptime
1029 1229 13727 147 1856 1965 2091 2244 2570 2827 3072
42 595 871 cgroups kallsyms partitions version
1030 1272 13729 148 1864 1967 2097 2245 2578 2829 31
43 596 872 cmdline kcore sched_debug vmallocinfo
1033 12749 1386 149 1883 1976 21 2249 26 2849 3180
4391 642 897 consoles keys schedstat vmstat
1095 1275 13929 15 1897 1994 2101 2254 2605 2853 32
44 645 9 cpuinfo key-users scsi zoneinfo
1096 12766 14 150 1898 2 2114 2259 2610 2866 33
45 6544 902 crypto kmsg self
11 12780 14175 151 19 20 2177 2265 2616 2885 34
46 6590 903 devices kpagecount slabinfo
1106 12817 142 1513 1903 2017 2179 2277 2633 2890 35
47 67 909 diskstats kpageflags softirqs
1108 1295 14214 1545 1910 2024 2181 2283 27 29 36
48 688 91 dma loadavg stat
1111 1297 143 156 1914 2028 2193 2292 2738 2921 37 5
69 919 driver locks swaps
1119 13 14337 163 1917 2036 2196 2397 2781 2925 38
50 7 92 execdomains mdstat sys
1136 13019 144 17 1918 2038 22 2398 28 2928 39
509 7031 926 fb meminfo sysrq-trigger
11446 13028 14477 172 1923 2039 2200 24 2809 2933 40
53 71 986 filesystems misc sysvipc
1167 13029 145 173 1924 2041 2212 2402 2818 2936 407
530 749 990 fs modules thread-self
[X.]
Launchpad bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391023
With previous kernels experienced similar issues, but not identical.
For instance, 3.16.0, the trackpad was not recognized at all. A
workaround in this case was to boot the kernel with the option
psmouse.proto=bare, which would give basic touchpad functionality, and
again no multitouch or scrolling.
I have not tested all kernels between 3.16 and 3.18-rc4 to determine
when the change in behaviour occurred... the psmouse.proto=bare
workaround is not required with 3.18-rc4 to have a basic touchpad.
Let me know if you need any more information.
Regards,
Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Vignesh R @ 2014-11-17 4:27 UTC (permalink / raw)
To: Richard Cochran
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Hartmut Knaack, Dmitry Torokhov, Lee Jones,
Sebastian Andrzej Siewior, Lars-Peter Clausen, Peter Meerwald,
Samuel Ortiz, Felipe Balbi, Brad Griffis, Sanjeev Sharma,
Paul Gortmaker, Jan Kardell, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap
In-Reply-To: <20141115192739.GA18766-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Sunday 16 November 2014 12:57 AM, Richard Cochran wrote:
> On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote:
>> From: Brad Griffis <bgriffis-l0cyMroinI0@public.gmane.org>
>>
>> TSC interrupt handler had udelay to avoid reporting of false pen-up
>> interrupt to user space. This patch implements workaround suggesting in
>> Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
>> and touchscreen lag. This also improves performance of touchscreen and
>> eliminates sudden jump of cursor at touch release.
>
> I back ported this series onto v3.15.1 in order to try this out on a
> custom, beaglebone-like board. With this series, the touch is really
> broken. (I had fixed the pen up problem in a totally different way for
> a customer, and so I wanted to try out your solution.)
>
> I will try to port the board code to a more recent kernel to try your
> series again. With which kernel version did you test your patches?
>
> And which board?
>
Thanks for testing these patches.
My patches are based on v3.18rc2. I tested my patches on am335x-evm
using tslib.
If you are encountering false pen-ups, charge-delay parameter needs to
be tuned to your board. In some custom setups charge-delay of 0xB000
provided better performance.
If you are using ts_test (from tslib) for testing try
# ts_test > /dev/null
for better performance.
Please explain "touch is broken"? What is the behaviour of TSC?
Which ADC channels are being used for TSC?
Regards
Vignesh
> Thanks,
> Richard
>
>
^ permalink raw reply
* Re: LEN2006 Synaptics touchpad min max fix
From: Dmitry Torokhov @ 2014-11-17 2:26 UTC (permalink / raw)
To: Ben Sagal; +Cc: linux-input
In-Reply-To: <CAK4AR+_pycN0MCqcjM_svpd5UjMWacXVr5QTWJeU-Ean4sD-Kg@mail.gmail.com>
On Sat, Nov 15, 2014 at 11:09:22PM +0200, Ben Sagal wrote:
> RE bug: https://bugzilla.kernel.org/show_bug.cgi?id=88211
>
> The LEN2006 Synaptics touchpad (as found in my thinkpad E540) returns
> wrong min max values.
>
> touchpad-edge-detector output:
> > Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
> > Move one finger around the touchpad to detect the actual edges
> > Kernel says: x [1472..5674], y [1408..4684]
> > Touchpad sends: x [1264..5675], y [1171..4688]
>
> the patch is against 3.17.2
>
> Signed-off-by: Binyamin Sagal <bensagal@gmail.com>
Applied, thank you.
> ---
>
> diff -uNr linux.org/drivers/input/mouse/synaptics.c
> linux/drivers/input/mouse/synaptics.c
> --- linux.org/drivers/input/mouse/synaptics.c 2014-11-14
> 12:18:39.000000000 +0200
> +++ linux/drivers/input/mouse/synaptics.c 2014-11-14 08:25:05.963395004 +0200
> @@ -143,6 +143,10 @@
> (const char * const []){"LEN2001", NULL},
> 1024, 5022, 2508, 4832
> },
> + {
> + (const char * const []){"LEN2006", NULL},
> + 1264, 5675, 1171, 4688
> + },
> { }
> };
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: atkbd - correct MSC_SCAN events for force_release keys
From: Dmitry Torokhov @ 2014-11-17 2:25 UTC (permalink / raw)
To: Stefan Brüns; +Cc: linux-input
In-Reply-To: <45706882.ZrxtpIdaNX@pebbles.site>
On Sun, Nov 16, 2014 at 11:18:31PM +0100, Stefan Brüns wrote:
> Without the change either no scancode would be reported on release
> of force_release keys, or - if the key is marked as force_release
> erroneously - the release event and the scancode would be reported
> in separate reports to the input layer.
>
> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> ---
>
> Originally sent on 28.9.2014, but somehow got lost.
> Resending as per Dmitrys request from 24.10.2014
Applied, thank you, but please next time don't use Kmail for patches -
it line-wrapped the patch and encoded it as quoted-printable.
Thanks!
>
> drivers/input/keyboard/atkbd.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 2dd1d0d..6375ae6 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -456,8 +456,9 @@ static irqreturn_t atkbd_interrupt(struct serio *serio,
> unsigned char data,
>
> keycode = atkbd->keycode[code];
>
> - if (keycode != ATKBD_KEY_NULL)
> - input_event(dev, EV_MSC, MSC_SCAN, code);
> + if (!(atkbd->release && test_bit(code, atkbd->force_release_mask)))
> + if (keycode != ATKBD_KEY_NULL)
> + input_event(dev, EV_MSC, MSC_SCAN, code);
>
> switch (keycode) {
> case ATKBD_KEY_NULL:
> @@ -511,6 +512,7 @@ static irqreturn_t atkbd_interrupt(struct serio *serio,
> unsigned char data,
> input_sync(dev);
>
> if (value && test_bit(code, atkbd->force_release_mask)) {
> + input_event(dev, EV_MSC, MSC_SCAN, code);
> input_report_key(dev, keycode, 0);
> input_sync(dev);
> }
> --
> 1.8.4.5
>
>
> --
> Stefan Brüns / Bergstraße 21 / 52062 Aachen
> home: +49 241 53809034 mobile: +49 151 50412019
> work: +49 2405 49936-424
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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