* Re: [PATCH 0/5] Input: elantech - support the Fujitsu H730 laptop
From: ulrik.debie-os @ 2014-11-06 19:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Jan Kiszka, Hans de Goede, linux-input, David Herrmann
In-Reply-To: <2794823.jCt3gL1uac@dtor-glaptop>
Ping.
I hope the mux regression problem has settled down a bit in the mean time.
On Thu, Oct 23, 2014 at 11:39:43AM -0700, Dmitry Torokhov wrote:
> Date: Thu, 23 Oct 2014 11:39:43 -0700
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> To: ulrik.debie-os@e2big.org
> Cc: Jan Kiszka <jan.kiszka@web.de>, Hans de Goede <hdegoede@redhat.com>,
> linux-input@vger.kernel.org, David Herrmann <dh.herrmann@gmail.com>
> Subject: Re: [PATCH 0/5] Input: elantech - support the Fujitsu H730 laptop
>
> On Thursday, October 23, 2014 08:36:19 PM ulrik.debie-os@e2big.org wrote:
> > Hi Dmitry,
> >
> > On Sat, Oct 04, 2014 at 11:36:26AM +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 10/04/2014 11:33 AM, Jan Kiszka wrote:
> > > > On 2014-08-30 16:10, Ulrik De Bie wrote:
> > > >> This patch set makes the elantech driver work for the Fujitsu H730
> > > >> laptop. It also adds a sysfs knob to allow other laptops that are
> > > >> facing similar problems as the Fujitsu H730 to have working touchpad.
> > > >>
> > > >> I'm considering adding a WARN_ONCE when the crc_enabled signature check
> > > >> fails. The message would then point the user to the crc_enabled sysfs
> > > >> knob,
> > > >> and kindly ask the user to report the laptop to linux-input mailinglist
> > > >> ?
> > > >> Any suggestions ?
> > > >>
> > > >> Two users have tested the combination of this patchset and confirmed
> > > >> that
> > > >> it makes the H730 touchpad/trackpoint work.
> > > >>
> > > >> Here an overview of the patchset:
> > > >>
> > > >> Patch 1/ : Input: elantech - use elantech_report_trackpoint for
> > > >> hardware v4 too The Fujitsu H730 is the first v4 hardware identified
> > > >> that also sends the trackpoint packets. This patch enables the
> > > >> trackpoint on v4 hardware. With this patch the trackpoint will work.
> > > >>
> > > >> Patch 2/ : Input: elantech - Fix crc_enabled for Fujitsu H730
> > > >> Uses DMI to detect the H730 and ,if detected, will set crc_enabled to
> > > >> 1.
> > > >> With this patch the touchpad and left/right button will start to work.
> > > >>
> > > >> Patch 3/ : Input: elantech - report the middle button of the touchpad
> > > >> The Fujitsu H730 is the first laptop listed in the elantech.c file with
> > > >> 3 touchpad buttons. This patch enables the middle button for all
> > > >> elantech
> > > >> hardware and enables the reporting for v4 hardware.
> > > >> I want to hear feedback here on what preferences exist for the
> > > >> conditions
> > > >> to enable the middle button:
> > > >> - DMI
> > > >> - enable only for v4
> > > >> - enable for all/report for v3+v4
> > > >> ...
> > > >>
> > > >> Patch 4/ : Input: Elantech - provide a sysfs knob for crc_enabled
> > > >> Probably H730 will not remain the only elantech laptop that has this
> > > >> failing detection for the crc_enabled. This provides users with a
> > > >> workaround when the crc_enabled detection fails.
> > > >>
> > > >> Patch 5/ : Elantech - Update the documentation:
> > > >> trackpoint,v3/v4,crc_enabled This provides an update of the elantech
> > > >> documentation.
> > > >>
> > > >> Patch 4 depends on patch 2, and for consistency, patch 5 depends on
> > > >> patch 1-2-4.> >>
> > > >> Ulrik De Bie (5):
> > > >> Input: elantech - use elantech_report_trackpoint for hardware v4 too
> > > >> Input: elantech - Fix crc_enabled for Fujitsu H730
> > > >> Input: elantech - report the middle button of the touchpad
> > > >> Input: elantech - provide a sysfs knob for crc_enabled
> > > >>
> > > >> Input: elantech - Update the documentation:
> > > >> trackpoint,v3/v4,crc_enabled
> > > >>
> > > >> Documentation/input/elantech.txt | 85 ++++++++++++++++++++++++++--
> > > >> drivers/input/mouse/elantech.c | 119
> > > >> ++++++++++++++++++++++++++++++++-------
> > > >> drivers/input/mouse/elantech.h | 2 +-
> > > >> 3 files changed, 179 insertions(+), 27 deletions(-)
> > > >>
> > > >> Best regards,
> > > >> Ulrik De Bie
> > > >
> > > > What's the status of this series? Is it queued for 3.18 already?
> > >
> > > I don't see them in next yet:
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/driver
> > > s/input/mouse/elantech.c
> > >
> > > I agree it would be nice to get these into 3.18.
> > >
> > > Dmitry, what is the plan here ?
> >
> > Ping Dmitry ?
> >
> > Do you want me to resend the patch ?
>
> Hi Ulrik,
>
> No, I have it, didn't have a chance to look at it though. Give me a day or so
> please.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: Help writing a custom HID driver
From: Jose Diez @ 2014-11-06 19:28 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
In-Reply-To: <CAN+gG=HmEvPz0R5+tXJdVaUWyms1pd=LgnO+L+0owYRo2Jx4Uw@mail.gmail.com>
Thanks Benjamin. That fixed the issue. Have a great day.
On 06/11/14 18:57, Benjamin Tissoires wrote:
> Hi Jose,
>
> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>> Hello linux-input,
>>
>> I'm trying to write a custom HID driver. It works fine, and I can send
>> reports just fine, but one of the requirements of this device is that I have
>> to reply to reports with code 62 with another report with code 62, which
>> resets a watchdog in the device.
>>
>> This is my code so far: http://codepad.org/m4QiWhDt
>>
>> The problem is in line 40. It seems like I'm not allowed to call
>> hid_hw_output_report from the raw_event callback handler. I've tried
>> surrounding the call with spin_locks, but I still get the "scheduling while
>> atomic" error.
> Yeah, when you are in the .event callback, you are basically called by
> an IRQ, so you can not schedule a potentially blocking operation.
>
>> I'm not sure how to approach this - can someone help? It would be much
>> appreciated. Thanks.
> I would use a worker to do what you are trying to do. You can have a
> look at the reset_worker we have in drivers/hid/hid-rmi.c.
> When the event is not one we expected, we schedule a worker thread
> which then sends an output report to the device. This way, the
> blocking operation is sent from a different thread than the IRQ one.
> It is kind of what you are willing to do.
> There are many other examples of workers in the hid subtree, or you
> can refer to the doc to find out more.
>
> Cheers,
> Benjamin
> --
> 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: Help writing a custom HID driver
From: Jose Diez @ 2014-11-06 20:18 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
In-Reply-To: <545BCBE9.6040309@mediacru.sh>
Okay, so I've solved the watchdog issue, and now I want the driver to be
loaded automatically. I've copied the module to /lib/modules/<kernel>/
and run depmod -a, and I can see it in modules.alias, but it looks like
hid_generic grabs it first upon boot - my module is loaded correctly,
but it doesn't grab the HID device.
If I `modprobe -r hid_generic` and then load my module, everything works
correctly.
On 06/11/14 19:28, Jose Diez wrote:
> Thanks Benjamin. That fixed the issue. Have a great day.
>
> On 06/11/14 18:57, Benjamin Tissoires wrote:
>> Hi Jose,
>>
>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>>> Hello linux-input,
>>>
>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>> reports just fine, but one of the requirements of this device is
>>> that I have
>>> to reply to reports with code 62 with another report with code 62,
>>> which
>>> resets a watchdog in the device.
>>>
>>> This is my code so far: http://codepad.org/m4QiWhDt
>>>
>>> The problem is in line 40. It seems like I'm not allowed to call
>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>> surrounding the call with spin_locks, but I still get the
>>> "scheduling while
>>> atomic" error.
>> Yeah, when you are in the .event callback, you are basically called by
>> an IRQ, so you can not schedule a potentially blocking operation.
>>
>>> I'm not sure how to approach this - can someone help? It would be much
>>> appreciated. Thanks.
>> I would use a worker to do what you are trying to do. You can have a
>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>> When the event is not one we expected, we schedule a worker thread
>> which then sends an output report to the device. This way, the
>> blocking operation is sent from a different thread than the IRQ one.
>> It is kind of what you are willing to do.
>> There are many other examples of workers in the hid subtree, or you
>> can refer to the doc to find out more.
>>
>> Cheers,
>> Benjamin
>> --
>> 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
>
> --
> 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: Help writing a custom HID driver
From: Benjamin Tissoires @ 2014-11-06 20:22 UTC (permalink / raw)
To: Jose Diez; +Cc: linux-input
In-Reply-To: <545BD794.7090002@mediacru.sh>
On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez <jose@mediacru.sh> wrote:
> Okay, so I've solved the watchdog issue, and now I want the driver to be
> loaded automatically. I've copied the module to /lib/modules/<kernel>/ and
> run depmod -a, and I can see it in modules.alias, but it looks like
> hid_generic grabs it first upon boot - my module is loaded correctly, but it
> doesn't grab the HID device.
>
> If I `modprobe -r hid_generic` and then load my module, everything works
> correctly.
Yep. You need to add your device VendorID/ProductID in
hid_have_special_driver[] in hid-core.c.
This will tell hid-generic not to grab your device, and your custom
module will take over.
Cheers,
Benjamin
>
> On 06/11/14 19:28, Jose Diez wrote:
>>
>> Thanks Benjamin. That fixed the issue. Have a great day.
>>
>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>
>>> Hi Jose,
>>>
>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>>>>
>>>> Hello linux-input,
>>>>
>>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>>> reports just fine, but one of the requirements of this device is that I
>>>> have
>>>> to reply to reports with code 62 with another report with code 62, which
>>>> resets a watchdog in the device.
>>>>
>>>> This is my code so far: http://codepad.org/m4QiWhDt
>>>>
>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>> surrounding the call with spin_locks, but I still get the "scheduling
>>>> while
>>>> atomic" error.
>>>
>>> Yeah, when you are in the .event callback, you are basically called by
>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>
>>>> I'm not sure how to approach this - can someone help? It would be much
>>>> appreciated. Thanks.
>>>
>>> I would use a worker to do what you are trying to do. You can have a
>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>> When the event is not one we expected, we schedule a worker thread
>>> which then sends an output report to the device. This way, the
>>> blocking operation is sent from a different thread than the IRQ one.
>>> It is kind of what you are willing to do.
>>> There are many other examples of workers in the hid subtree, or you
>>> can refer to the doc to find out more.
>>>
>>> Cheers,
>>> Benjamin
>>> --
>>> 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
>>
>>
>> --
>> 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: Help writing a custom HID driver
From: Jose Diez @ 2014-11-06 20:56 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
In-Reply-To: <CAN+gG=EZDBsRMgm7gmw3f0N88wPJEp2xADCwpcQivK88eiJthg@mail.gmail.com>
Ah, I was hoping there would be a way to avoid having to patch the
kernel itself.
Thanks again,
Jose
On 06/11/14 20:22, Benjamin Tissoires wrote:
> On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez<jose@mediacru.sh> wrote:
>> Okay, so I've solved the watchdog issue, and now I want the driver to be
>> loaded automatically. I've copied the module to /lib/modules/<kernel>/ and
>> run depmod -a, and I can see it in modules.alias, but it looks like
>> hid_generic grabs it first upon boot - my module is loaded correctly, but it
>> doesn't grab the HID device.
>>
>> If I `modprobe -r hid_generic` and then load my module, everything works
>> correctly.
> Yep. You need to add your device VendorID/ProductID in
> hid_have_special_driver[] in hid-core.c.
> This will tell hid-generic not to grab your device, and your custom
> module will take over.
>
> Cheers,
> Benjamin
>
>> On 06/11/14 19:28, Jose Diez wrote:
>>> Thanks Benjamin. That fixed the issue. Have a great day.
>>>
>>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>> Hi Jose,
>>>>
>>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez<jose@mediacru.sh> wrote:
>>>>> Hello linux-input,
>>>>>
>>>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>>>> reports just fine, but one of the requirements of this device is that I
>>>>> have
>>>>> to reply to reports with code 62 with another report with code 62, which
>>>>> resets a watchdog in the device.
>>>>>
>>>>> This is my code so far:http://codepad.org/m4QiWhDt
>>>>>
>>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>>> surrounding the call with spin_locks, but I still get the "scheduling
>>>>> while
>>>>> atomic" error.
>>>> Yeah, when you are in the .event callback, you are basically called by
>>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>>
>>>>> I'm not sure how to approach this - can someone help? It would be much
>>>>> appreciated. Thanks.
>>>> I would use a worker to do what you are trying to do. You can have a
>>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>>> When the event is not one we expected, we schedule a worker thread
>>>> which then sends an output report to the device. This way, the
>>>> blocking operation is sent from a different thread than the IRQ one.
>>>> It is kind of what you are willing to do.
>>>> There are many other examples of workers in the hid subtree, or you
>>>> can refer to the doc to find out more.
>>>>
>>>> Cheers,
>>>> Benjamin
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>>> the body of a message tomajordomo@vger.kernel.org
>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>> the body of a message tomajordomo@vger.kernel.org
>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message tomajordomo@vger.kernel.org
> More majordomo info athttp://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problems with Wacom Intuos PT M (CTH680) on FreeBSD
From: Ping Cheng @ 2014-11-07 1:30 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Hans Petter Selasky, Denis Akiyakov, linux-input,
nox@jelal.kn-bremen.de >> Juergen Lock
In-Reply-To: <20141104180648.GA440@dtor-ws>
On Tue, Nov 4, 2014 at 10:06 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Nov 04, 2014 at 09:38:38AM -0800, Ping Cheng wrote:
>> Hi Dmitry,
>>
>> On Tue, Nov 4, 2014 at 12:08 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Sat, Nov 01, 2014 at 08:40:19AM +0100, Hans Petter Selasky wrote:
>> >> On 11/01/14 00:27, Ping Cheng wrote:
>> >> >If touch_input is NULL on FreeBSD, you need to figure out the root
>> >> >cause. Checking on touch_input itself would not fix the root cause...
>> >>
>> >> Right.
>> >>
>> >> The root cause is that FreeBSD launches two instances of the driver,
>> >> running in two different userland processes, for the two different
>> >> Wacom interfaces on a common USB device. In Linux the wacom
>> >> interface drivers are running from the same kernel, and can share
>> >> the data in question, but in FreeBSD's webcamd emulation, this
>> >> doesn't work. Then the first wacom probe call would have to grab the
>> >> second interface.
>> >>
>> >> Technically speaking this is a FreeBSD only problem and I plan to
>> >> deliver a patch with the webcamd software to fix this, like already
>> >> suggested to you guys. This situation can also happen on Linux in
>> >> case of a "BadUSB" device. That's why I think that the NULL check
>> >> should be upstreamed.
>> >
>> > Hmm, looking at this again it seems that we just cross our fingers and
>> > hope that both interfaces are enumerated by the time we get event data
>> > from the device. I do not think this is quite safe. We probably should
>> > be checking the overall state of probing (i.e. whether we are done
>> > probing both interfaces) before processing data for the device.
>>
>> Are you going to make a patch to address the issue?
>
> Not in the nearest future, sorry.
No problem. I just want to make sure we don't duplicate the work...
>> > Or maybe we should just forcibly try claiming secondary interface
>> > while probing primary instead of messing with shared data item.
I looked into the code. It is not a simple task to claim secondary
interface while probing the primary one. For some devices, there is no
easy way to tell if they have multi-interfaces or not before accessing
the data,
>> If we incorporate the above idea into a patch, we need to keep in mind
>> that not all tablets support touch data. So, not all tablets have two
>> interfaces.
>
> Right, but we do know the models that use multiple interfaces, right?
Some models may have same product ID but can have pen or pen and touch
interfaces. We'll have to request the device to be sure...
Since touch_input is the only shared data/pointer that should not be
called before all interlaces are probed, checking on touch_input when
it is called, as suggested by Hans, is a feasible solution. As a
by-product, it also fixes the FreeBSD issue.
I'll post my patch here soon.
Ping
^ permalink raw reply
* [PATCH] HID: wacom - make sure touch_input is valid before using it
From: Ping Cheng @ 2014-11-07 1:30 UTC (permalink / raw)
To: jkosina; +Cc: dmitry.torokhov, linux-input, Ping Cheng
touch_input is stored in wacom_shared for pen data to report touch
switch status. It is possible, although we didn't see it happen on
Linux yet, that pen data is procesed before touch interface is
fully probed.
As a by-product of this patch, it fixes the FreeBSD issue reported
by Denis Akiyakov http://www.spinics.net/lists/linux-input/msg33971.html
Reviewed-by: Hans Petter Selasky <hps@selasky.org>
Tested-by: Denis Akiyakov <d.akiyakov@gmail.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
---
drivers/hid/wacom_wac.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 8ce7fab..1048295 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1681,7 +1681,9 @@ static int wacom_bpt_pen(struct wacom_wac *wacom)
return 0;
if (data[0] == WACOM_REPORT_USB) {
- if (features->type == INTUOSHT && features->touch_max) {
+ if (features->type == INTUOSHT &&
+ wacom->shared->touch_input &&
+ features->touch_max) {
input_report_switch(wacom->shared->touch_input,
SW_MUTE_DEVICE, data[8] & 0x40);
input_sync(wacom->shared->touch_input);
@@ -1774,7 +1776,8 @@ static int wacom_wireless_irq(struct wacom_wac *wacom, size_t len)
int pid, battery, ps_connected;
if ((wacom->shared->type == INTUOSHT) &&
- wacom->shared->touch_max) {
+ wacom->shared->touch_input &&
+ wacom->shared->touch_max) {
input_report_switch(wacom->shared->touch_input,
SW_MUTE_DEVICE, data[5] & 0x40);
input_sync(wacom->shared->touch_input);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Vignesh R @ 2014-11-07 5:34 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,
Dmitry Torokhov, devicetree, Lars-Peter Clausen, Samuel Ortiz,
Jan Kardell, linux-iio, Sebastian Andrzej Siewior, linux-input,
linux-kernel, Felipe Balbi, Paul Gortmaker, Peter Meerwald,
Hartmut Knaack, linux-omap, Lee Jones
In-Reply-To: <20141106141916.GA17151@netboy>
On Thursday 06 November 2014 07:49 PM, Richard Cochran wrote:
> On Mon, Oct 27, 2014 at 04:38:28PM +0530, Vignesh R wrote:
>
> ...
>
>> @@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>> unsigned int read, diff;
>> unsigned int i, channel;
>> unsigned int creads = ts_dev->coordinate_readouts;
>> + unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
>>
>> *z1 = *z2 = 0;
>> if (fifocount % (creads * 2 + 2))
>> @@ -226,7 +232,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>>
>> channel = (read & 0xf0000) >> 16;
>> read &= 0xfff;
>> - if (channel < creads) {
>> + if (channel > first_step + creads + 2) {
>> diff = abs(read - prev_val_x);
>> if (diff < prev_diff_x) {
>> prev_diff_x = diff;
>> @@ -234,19 +240,19 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>> }
>> prev_val_x = read;
>>
>> - } else if (channel < creads * 2) {
>> + } else if (channel == first_step + creads + 1) {
>> + *z1 = read;
>> +
>> + } else if (channel == first_step + creads + 2) {
>> + *z2 = read;
>> +
>> + } else if (channel > first_step) {
>> diff = abs(read - prev_val_y);
>> if (diff < prev_diff_y) {
>> prev_diff_y = diff;
>> *y = read;
>
> While you are at it, please get rid of the this "delta filter"
> nonsense.
Currently, there is too much noise in the TSC hardware that is being
removed by delta filtering. I tested TSC unit by removing filtering
logic, the performance was not at all satisfactory. The cursor jumps
wayward and smooth circles cannot be drawn. Looks like delta filtering
cannot be removed as of now. May be I will try and address it in future.
Regards
Vignesh
>
> Thanks,
> Richard
>
>> }
>> prev_val_y = read;
>> -
>> - } else if (channel < creads * 2 + 1) {
>> - *z1 = read;
>> -
>> - } else if (channel < creads * 2 + 2) {
>> - *z2 = read;
>> }
>> }
>> }
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Vignesh R @ 2014-11-07 5:48 UTC (permalink / raw)
To: Hartmut Knaack, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Benoit Cousson, Tony Lindgren,
Russell King, Jonathan Cameron, Dmitry Torokhov
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Lee Jones,
Felipe Balbi, Sebastian Andrzej Siewior, Jan Kardell,
Paul Gortmaker, Brad Griffis, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <5453F935.10007@gmx.de>
On Saturday 01 November 2014 02:33 AM, Hartmut Knaack wrote:
> Vignesh R schrieb am 27.10.2014 12:08:
>> From: Brad Griffis <bgriffis@ti.com>
>>
>> This patch makes the initial changes required to workaround TSC-false
>> pen-up interrupts. It is required to implement these changes in order to
>> remove udelay in the TSC interrupt handler and false pen-up events.
>> The charge step is to be executed immediately after sampling X+. Hence
>> TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate
>> readouts, 4 wire TSC configuration) and ADC to use lower ones. Further
>> X co-ordinate readouts must be the last to be sampled, thus co-ordinates
>> are sampled in the order Y-Z-X.
>>
>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>> [vigneshr@ti.com: Ported the patch from v3.12 to v3.18rc2]
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>> drivers/iio/adc/ti_am335x_adc.c | 2 +-
>> drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++++++++++++++++++-------------
>> 2 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
>> index b730864731e8..3f530ed6bd80 100644
>> --- a/drivers/iio/adc/ti_am335x_adc.c
>> +++ b/drivers/iio/adc/ti_am335x_adc.c
>> @@ -98,7 +98,7 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
>> * needs to be given to ADC to digitalize data.
>> */
>>
>> - steps = TOTAL_STEPS - adc_dev->channels;
>> + steps = 0;
> You could even initialize it with zero during variable definition. And I think the above comment could need an update now.
Ok, Will update the comment and initialization
>> if (iio_buffer_enabled(indio_dev))
>> stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
>> | STEPCONFIG_MODE_SWCNT;
>> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
>> index 2ce649520fe0..1aeac9675fe7 100644
>> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
>> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
>> @@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev)
>> {
>> unsigned int config;
>> int i;
>> - int end_step;
>> + int end_step, first_step, tsc_steps;
>> u32 stepenable;
>>
>> config = STEPCONFIG_MODE_HWSYNC |
>> @@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev)
>> break;
>> }
>>
>> - /* 1 … coordinate_readouts is for X */
>> - end_step = ts_dev->coordinate_readouts;
>> - for (i = 0; i < end_step; i++) {
>> + tsc_steps = ts_dev->coordinate_readouts * 2 + 2;
>> + first_step = TOTAL_STEPS - tsc_steps;
>> + /* Steps 16 to 16-coordinate_readouts is for X */
>> + 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);
>> }
>> @@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev)
>> break;
>> }
>>
>> - /* coordinate_readouts … coordinate_readouts * 2 is for Y */
>> - end_step = ts_dev->coordinate_readouts * 2;
>> - for (i = ts_dev->coordinate_readouts; i < end_step; i++) {
>> + /* 1 ... coordinate_readouts is for Y */
>> + 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);
>> }
>> @@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev)
>> titsc_writel(ts_dev, REG_CHARGECONFIG, config);
>> titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
>>
>> - /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
>> + /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
>> config = STEPCONFIG_MODE_HWSYNC |
>> STEPCONFIG_AVG_16 | ts_dev->bit_yp |
>> ts_dev->bit_xn | STEPCONFIG_INM_ADCREFM |
>> @@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev)
>> titsc_writel(ts_dev, REG_STEPDELAY(end_step),
>> STEPCONFIG_OPENDLY);
>>
>> - /* The steps1 … end and bit 0 for TS_Charge */
>> - stepenable = (1 << (end_step + 2)) - 1;
>> + /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
>> + stepenable = 1;
>> + for (i = 0; i < tsc_steps; i++)
>> + stepenable |= 1 << (first_step + i + 1);
>> +
>> ts_dev->step_mask = stepenable;
>> am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
>> }
>> @@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>> unsigned int read, diff;
>> unsigned int i, channel;
>> unsigned int creads = ts_dev->coordinate_readouts;
>> + unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
>>
>> *z1 = *z2 = 0;
>> if (fifocount % (creads * 2 + 2))
>> @@ -226,7 +232,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>>
>> channel = (read & 0xf0000) >> 16;
>> read &= 0xfff;
>> - if (channel < creads) {
>> + if (channel > first_step + creads + 2) {
>> diff = abs(read - prev_val_x);
>> if (diff < prev_diff_x) {
>> prev_diff_x = diff;
>> @@ -234,19 +240,19 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
>> }
>> prev_val_x = read;
>>
>> - } else if (channel < creads * 2) {
>> + } else if (channel == first_step + creads + 1) {
>> + *z1 = read;
>> +
>> + } else if (channel == first_step + creads + 2) {
>> + *z2 = read;
>> +
>> + } else if (channel > first_step) {
>> diff = abs(read - prev_val_y);
>> if (diff < prev_diff_y) {
>> prev_diff_y = diff;
>> *y = read;
>> }
>> prev_val_y = read;
>> -
>> - } else if (channel < creads * 2 + 1) {
>> - *z1 = read;
>> -
>> - } else if (channel < creads * 2 + 2) {
>> - *z2 = read;
>> }
>> }
>> }
>>
>
> --
> 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
* [PATCH 1/5] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <1415339350-17679-1-git-send-email-vigneshr@ti.com>
From: Brad Griffis <bgriffis@ti.com>
This patch makes the initial changes required to workaround TSC-false
pen-up interrupts. It is required to implement these changes in order to
remove udelay in the TSC interrupt handler and false pen-up events.
The charge step is to be executed immediately after sampling X+. Hence
TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate
readouts, 4 wire TSC configuration) and ADC to use lower ones. Further
X co-ordinate readouts must be the last to be sampled, thus co-ordinates
are sampled in the order Y-Z-X.
Signed-off-by: Brad Griffis <bgriffis@ti.com>
[vigneshr@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/iio/adc/ti_am335x_adc.c | 5 ++--
drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++++++++++++++++++-------------
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b730864731e8..adba23246474 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -86,19 +86,18 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
unsigned int stepconfig;
- int i, steps;
+ int i, steps = 0;
/*
* There are 16 configurable steps and 8 analog input
* lines available which are shared between Touchscreen and ADC.
*
- * Steps backwards i.e. from 16 towards 0 are used by ADC
+ * Steps forwards i.e. from 0 towards 16 are used by ADC
* depending on number of input lines needed.
* Channel would represent which analog input
* needs to be given to ADC to digitalize data.
*/
- steps = TOTAL_STEPS - adc_dev->channels;
if (iio_buffer_enabled(indio_dev))
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
| STEPCONFIG_MODE_SWCNT;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2ce649520fe0..1aeac9675fe7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev)
{
unsigned int config;
int i;
- int end_step;
+ int end_step, first_step, tsc_steps;
u32 stepenable;
config = STEPCONFIG_MODE_HWSYNC |
@@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* 1 … coordinate_readouts is for X */
- end_step = ts_dev->coordinate_readouts;
- for (i = 0; i < end_step; i++) {
+ tsc_steps = ts_dev->coordinate_readouts * 2 + 2;
+ first_step = TOTAL_STEPS - tsc_steps;
+ /* Steps 16 to 16-coordinate_readouts is for X */
+ 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);
}
@@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* coordinate_readouts … coordinate_readouts * 2 is for Y */
- end_step = ts_dev->coordinate_readouts * 2;
- for (i = ts_dev->coordinate_readouts; i < end_step; i++) {
+ /* 1 ... coordinate_readouts is for Y */
+ 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);
}
@@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
- /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
+ /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev->bit_yp |
ts_dev->bit_xn | STEPCONFIG_INM_ADCREFM |
@@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
STEPCONFIG_OPENDLY);
- /* The steps1 … end and bit 0 for TS_Charge */
- stepenable = (1 << (end_step + 2)) - 1;
+ /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
+ stepenable = 1;
+ for (i = 0; i < tsc_steps; i++)
+ stepenable |= 1 << (first_step + i + 1);
+
ts_dev->step_mask = stepenable;
am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
}
@@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
unsigned int read, diff;
unsigned int i, channel;
unsigned int creads = ts_dev->coordinate_readouts;
+ unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
*z1 = *z2 = 0;
if (fifocount % (creads * 2 + 2))
@@ -226,7 +232,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
channel = (read & 0xf0000) >> 16;
read &= 0xfff;
- if (channel < creads) {
+ if (channel > first_step + creads + 2) {
diff = abs(read - prev_val_x);
if (diff < prev_diff_x) {
prev_diff_x = diff;
@@ -234,19 +240,19 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
}
prev_val_x = read;
- } else if (channel < creads * 2) {
+ } else if (channel == first_step + creads + 1) {
+ *z1 = read;
+
+ } else if (channel == first_step + creads + 2) {
+ *z2 = read;
+
+ } else if (channel > first_step) {
diff = abs(read - prev_val_y);
if (diff < prev_diff_y) {
prev_diff_y = diff;
*y = read;
}
prev_val_y = read;
-
- } else if (channel < creads * 2 + 1) {
- *z1 = read;
-
- } else if (channel < creads * 2 + 2) {
- *z2 = read;
}
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <1415339350-17679-1-git-send-email-vigneshr@ti.com>
From: Brad Griffis <bgriffis@ti.com>
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.
IDLECONFIG and CHARGECONFIG registers are to be configured
with same values in order to eliminate false pen-up events. This
workaround may result in false pen-down to be detected, hence considerable
charge step delay needs to be added. The charge delay is set to 0xB000
(in terms of ADC clock cycles) by default.
TSC steps are disabled at the end of every sampling cycle and EOS bit is
set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
next sampling cycle.
Signed-off-by: Brad Griffis <bgriffis@ti.com>
[vigneshr@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/input/touchscreen/ti_am335x_tsc.c | 56 ++++++++++++-------------------
include/linux/mfd/ti_am335x_tscadc.h | 3 +-
2 files changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 1aeac9675fe7..483fd97c0e0c 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -173,11 +173,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- /* Charge step configuration */
- config = ts_dev->bit_xp | ts_dev->bit_yn |
- STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
- STEPCHARGE_INM_AN1 | STEPCHARGE_INP(ts_dev->inp_yp);
+ /* Make CHARGECONFIG same as IDLECONFIG */
+ config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
@@ -264,9 +262,26 @@ static irqreturn_t titsc_irq(int irq, void *dev)
unsigned int status, irqclr = 0;
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
- unsigned int fsm;
- status = titsc_readl(ts_dev, REG_IRQSTATUS);
+ status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
+ if (status & IRQENB_HW_PEN) {
+ ts_dev->pen_down = true;
+ titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+ titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ irqclr |= IRQENB_HW_PEN;
+ }
+
+ if (status & IRQENB_PENUP) {
+ ts_dev->pen_down = false;
+ input_report_key(input_dev, BTN_TOUCH, 0);
+ input_report_abs(input_dev, ABS_PRESSURE, 0);
+ input_sync(input_dev);
+ irqclr |= IRQENB_PENUP;
+ }
+
+ if (status & IRQENB_EOS)
+ irqclr |= IRQENB_EOS;
+
/*
* ADC and touchscreen share the IRQ line.
* FIFO1 interrupts are used by ADC. Handle FIFO0 IRQs here only
@@ -297,34 +312,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
}
irqclr |= IRQENB_FIFO0THRES;
}
-
- /*
- * Time for sequencer to settle, to read
- * correct state of the sequencer.
- */
- udelay(SEQ_SETTLE);
-
- status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
- if (status & IRQENB_PENUP) {
- /* Pen up event */
- fsm = titsc_readl(ts_dev, REG_ADCFSM);
- if (fsm == ADCFSM_STEPID) {
- ts_dev->pen_down = false;
- input_report_key(input_dev, BTN_TOUCH, 0);
- input_report_abs(input_dev, ABS_PRESSURE, 0);
- input_sync(input_dev);
- } else {
- ts_dev->pen_down = true;
- }
- irqclr |= IRQENB_PENUP;
- }
-
- if (status & IRQENB_HW_PEN) {
-
- titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
- titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
- }
-
if (irqclr) {
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
@@ -417,6 +404,7 @@ static int titsc_probe(struct platform_device *pdev)
}
titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
+ titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
err = titsc_config_wires(ts_dev);
if (err) {
dev_err(&pdev->dev, "wrong i/p wire configuration\n");
diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
index e2e70053470e..c99be5dc0f5c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -52,6 +52,7 @@
/* IRQ enable */
#define IRQENB_HW_PEN BIT(0)
+#define IRQENB_EOS BIT(1)
#define IRQENB_FIFO0THRES BIT(2)
#define IRQENB_FIFO0OVRRUN BIT(3)
#define IRQENB_FIFO0UNDRFLW BIT(4)
@@ -107,7 +108,7 @@
/* Charge delay */
#define CHARGEDLY_OPEN_MASK (0x3FFFF << 0)
#define CHARGEDLY_OPEN(val) ((val) << 0)
-#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1)
+#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(0xB000)
/* Control register */
#define CNTRLREG_TSCSSENB BIT(0)
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415339350-17679-1-git-send-email-vigneshr-l0cyMroinI0@public.gmane.org>
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(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d877e777cce6..94ef8992f46b 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 & (!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 c99be5dc0f5c..fcce182e4a35 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
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/5] input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <1415339350-17679-1-git-send-email-vigneshr@ti.com>
This patch reads charge delay from tsc DT node and writes to
REG_CHARGEDELAY register. If the charge delay is not specified in DT
then default value of 0xB000(CHARGEDLY_OPENDLY) is used.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
drivers/input/touchscreen/ti_am335x_tsc.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
index 483fd97c0e0c..20ce76b1b6e7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -52,6 +52,7 @@ struct titsc {
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
+ u32 charge_delay;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -177,7 +178,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
- titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
+ titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev->charge_delay);
/* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
@@ -361,6 +362,11 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err < 0)
return err;
+ err = of_property_read_u32(node, "ti,charge-delay",
+ &ts_dev->charge_delay);
+ if (err < 0)
+ ts_dev->charge_delay = CHARGEDLY_OPENDLY;
+
return of_property_read_u32_array(node, "ti,wire-config",
ts_dev->config_inp, ARRAY_SIZE(ts_dev->config_inp));
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/4] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Vignesh R @ 2014-11-07 5:48 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Dmitry Torokhov, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Sebastian Andrzej Siewior, Jan Kardell, Paul Gortmaker,
Brad Griffis, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio
In-Reply-To: <20141103150526.GI4538@x1>
On Monday 03 November 2014 08:35 PM, Lee Jones wrote:
> On Mon, 27 Oct 2014, Vignesh R wrote:
>> From: Brad Griffis <bgriffis@ti.com>
>>
>> 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.
>>
>> IDLECONFIG and CHARGECONFIG registers are to be configured
>> with same values in order to eliminate false pen-up events. This
>> workaround may result in false pen-down to be detected, hence considerable
>> charge step delay needs to be added. The charge delay is set to 0xB000
>> (in terms of ADC clock cycles) by default.
>>
>> TSC steps are disabled at the end of every sampling cycle and EOS bit is
>> set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
>> next sampling cycle.
>>
>> 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.
>>
>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>> [vigneshr@ti.com: Ported patch from v3.12 to v3.18rc2]
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>> drivers/input/touchscreen/ti_am335x_tsc.c | 56 ++++++++++++-------------------
>> drivers/mfd/ti_am335x_tscadc.c | 7 ++--
>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++-
>> 3 files changed, 30 insertions(+), 37 deletions(-)
>
> [...]
>
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>> index d877e777cce6..94ef8992f46b 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 & (!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);
>
> I believe all of these changes can, and therefor should live in a
> separate patch.
I will split this patch accordingly.
>
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> index e2e70053470e..fcce182e4a35 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -52,6 +52,7 @@
>>
>> /* IRQ enable */
>> #define IRQENB_HW_PEN BIT(0)
>> +#define IRQENB_EOS BIT(1)
>> #define IRQENB_FIFO0THRES BIT(2)
>> #define IRQENB_FIFO0OVRRUN BIT(3)
>> #define IRQENB_FIFO0UNDRFLW BIT(4)
>> @@ -107,7 +108,7 @@
>> /* Charge delay */
>> #define CHARGEDLY_OPEN_MASK (0x3FFFF << 0)
>> #define CHARGEDLY_OPEN(val) ((val) << 0)
>> -#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1)
>> +#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(0xB000)
>>
>> /* Control register */
>> #define CNTRLREG_TSCSSENB BIT(0)
>> @@ -127,6 +128,7 @@
>>
>> /* Sequencer Status */
>> #define SEQ_STATUS BIT(5)
>> +#define CHARGE_STEP 0x11
>>
>> #define ADC_CLK 3000000
>> #define TOTAL_STEPS 16
>
> The header changes should be split between the two Input and MFD
> patches.
>
^ permalink raw reply
* Re: [PATCH 3/4] arm: boot: dts: am335x-evm: Make charge delay a DT parameter for tsc
From: Vignesh R @ 2014-11-07 5:48 UTC (permalink / raw)
To: Hartmut Knaack, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Benoit Cousson, Tony Lindgren,
Russell King, Jonathan Cameron, Dmitry Torokhov
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Lee Jones,
Felipe Balbi, Sebastian Andrzej Siewior, Jan Kardell,
Paul Gortmaker, Brad Griffis, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <5453FA8E.3080204@gmx.de>
On Saturday 01 November 2014 02:39 AM, Hartmut Knaack wrote:
> Vignesh R schrieb am 27.10.2014 12:08:
>> The charge delay value is by default 0xB000. But it can be set to lower
>> values on some boards as long as false pen-ups are avoided. Lowering the
>> value increases the sampling rate (though current sampling rate is
>> sufficient for tsc operation). Hence charge delay has been made a DT
>> parameter.
>>
> I would recommend to use a few colons to separate some thoughts. Also, limit to 80 chars per line would be beneficial. See inline.
I will address this in v2
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>> .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 13 +++++++++++++
>> arch/arm/boot/dts/am335x-evm.dts | 1 +
>> 2 files changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> index 878549ba814d..ac62769e70e4 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
>> @@ -28,6 +28,18 @@ Required properties:
>> ti,adc-channels: List of analog inputs available for ADC.
>> AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
>>
>> +Optional properties:
>> +- child "tsc"
>> + ti,charge-delay: Length of touch screen charge delay step in terms of
>> + ADC clock cycles. Charge delay value should be large in order
>> + to avoid false pen-up events. This value affects the overall
>> + sampling speed hence need to be kept as low as possible while
> <...> speed, hence needs to be <...>
>> + avoiding false pen-up event. Start from a lower value say 0x400
> <...> pen-up events. Start from a lower value, like 0x400, and increase <...>
>> + and increase value until false pen-up events are avoided. The
>> + pen-up detection happens immediately after the charge step
> <...> charge step, so this <...>
>> + so this does in fact function as a hardware knob for adjusting
>> + the amount of "settling time".
>> +
>> Example:
>> tscadc: tscadc@44e0d000 {
>> compatible = "ti,am3359-tscadc";
>> @@ -36,6 +48,7 @@ Example:
>> ti,x-plate-resistance = <200>;
>> ti,coordiante-readouts = <5>;
>> ti,wire-config = <0x00 0x11 0x22 0x33>;
>> + ti,charge-delay = <0xB000>;
>> };
>>
>> adc {
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
>> index e2156a583de7..80be0462298b 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -641,6 +641,7 @@
>> ti,x-plate-resistance = <200>;
>> ti,coordinate-readouts = <5>;
>> ti,wire-config = <0x00 0x11 0x22 0x33>;
>> + ti,charge-delay = <0xB000>;
>> };
>>
>> adc {
>>
>
^ permalink raw reply
* [PATCH v2 0/5] Touchscreen performance related fixes
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio, linux-input
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. 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). 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.
A DT parameter to configure the duration of tsc charge step. It represents
number of ADC clock cycles to wait between applying the step configuration
registers and going back to the IDLE state. The charge delay value can vary
across boards. Configuring correct value of charge delay is important to avoid
false pen-up events. Hence it is necessary to expose charge-delay value as
DT parameter. The pen-up detection happens immediately after the charge step
so this does in fact function as a hardware knob for adjusting the amount of
settling time.
After applying these changes false pen-up events have not be observed and
smooth circles can be drawn on touch screen. The performance is much better
in recognizing quick movement across the screen. No lag or cursor jump is
observed.
Change log:
v2:
- Addressed comments by Hartmut Knaack
- patch 2 was split into two as per Lee Jones comment
Brad Griffis (2):
input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC
steps
input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
Vignesh R (3):
mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
ARM: dts: AM335x: Make charge delay a DT parameter for tsc
input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter
.../bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++
arch/arm/boot/dts/am335x-evm.dts | 1 +
drivers/iio/adc/ti_am335x_adc.c | 5 +-
drivers/input/touchscreen/ti_am335x_tsc.c | 106 ++++++++++-----------
drivers/mfd/ti_am335x_tscadc.c | 7 +-
include/linux/mfd/ti_am335x_tscadc.h | 4 +-
6 files changed, 79 insertions(+), 59 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 4/5] ARM: dts: AM335x: Make charge delay a DT parameter for tsc
From: Vignesh R @ 2014-11-07 5:49 UTC (permalink / raw)
To: 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
Cc: Lars-Peter Clausen, Peter Meerwald, Samuel Ortiz, Felipe Balbi,
Vignesh R, Brad Griffis, Sanjeev Sharma, Paul Gortmaker,
Jan Kardell, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-iio, linux-input
In-Reply-To: <1415339350-17679-1-git-send-email-vigneshr@ti.com>
The charge delay value is by default 0xB000. But it can be set to lower
values on some boards as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for tsc operation). Hence charge delay has been made a DT
parameter.
Signed-off-by: Vignesh R <vigneshr@ti.com>
---
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++++++++++++++
arch/arm/boot/dts/am335x-evm.dts | 1 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..b87574bae009 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -28,6 +28,20 @@ Required properties:
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Optional properties:
+- child "tsc"
+ ti,charge-delay: Length of touch screen charge delay step in terms of
+ ADC clock cycles. Charge delay value should be large
+ in order to avoid false pen-up events. This value
+ affects the overall sampling speed, hence need to be
+ kept as low as possible, while avoiding false pen-up
+ event. Start from a lower value, say 0x400, and
+ increase value until false pen-up events are avoided.
+ The pen-up detection happens immediately after the
+ charge step, so this does in fact function as a
+ hardware knob for adjusting the amount of "settling
+ time".
+
Example:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
@@ -36,6 +50,7 @@ Example:
ti,x-plate-resistance = <200>;
ti,coordiante-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
+ ti,charge-delay = <0xB000>;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a583de7..80be0462298b 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -641,6 +641,7 @@
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
+ ti,charge-delay = <0xB000>;
};
adc {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Richard Cochran @ 2014-11-07 8:00 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,
Dmitry Torokhov, devicetree, Lars-Peter Clausen, Samuel Ortiz,
Jan Kardell, linux-iio, Sebastian Andrzej Siewior, linux-input,
linux-kernel, Felipe Balbi, Paul Gortmaker, Peter Meerwald,
Hartmut Knaack, linux-omap, Lee Jones, linux-arm
In-Reply-To: <545C59CD.3070707@ti.com>
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote:
>
> Currently, there is too much noise in the TSC hardware that is being
> removed by delta filtering.
The so called "filter" was only programmed because the fifo entries
were being mixed up. Sebastian fixed that.
> I tested TSC unit by removing filtering
> logic, the performance was not at all satisfactory. The cursor jumps
> wayward and smooth circles cannot be drawn. Looks like delta filtering
> cannot be removed as of now. May be I will try and address it in future.
The "filter" code is nonsensical. It picks the two values in seqeunce
that are closest to one and another. How is that supposed to work?
Did you look at the "noise"? What kind of properties did you see?
A median filter makes more sense. Or sort, remove outliers, and
average. But choosing the two closest in series is silly.
Thanks,
Richard
^ permalink raw reply
* Re: About Dell Inspiron 3442 touchpad
From: Luiz Carlos Ramos @ 2014-11-07 9:33 UTC (permalink / raw)
To: Andrew Duggan, Benjamin Tissoires; +Cc: linux-input
In-Reply-To: <207925.414b6a6d6a6b514141424f4a5646725736517067514375537a5551@popretr.messagingengine.com>
Hello, Andrew and Benjamin,
I managed to sync the working directory with git, and noticed there were
some experiments I've made which were "live" in the working directory.
So, I was wrong when I told the kernel was pure vanilla 3.16.3. One of
the changes may explain what happened with the touchpad.
After resync'ing the working directory with git, rebuilding the kernel
and
restarting the laptop, I could make the touchpad work for the first
time.
Now there are problems with the right button, but much probably it is
some kind of Xorg configuration issue.
So, the main issue is solved.
I'd like to thank you for the assistance, and apologize somehow for that
mistake.
Thanks,
Luiz
On Thu, Nov 6, 2014, at 00:03, Andrew Duggan wrote:
> On Wed, Nov 5, 2014 at 3:09 PM, Luiz Carlos Ramos
> <lramos.prof@yahoo.com.br> wrote:
> > Hi, Benjamin.
> >
> > I'm just using vanilla 3.16.3, no patches, with .config built from the
> > one from Slackware stable (kernel 3.10.17). Anyway, I'll try to upgrade
> > it to the lastest 3.16.
> >
>
> I pulled 3.16.3 from linux-stable and tested with a similar touchpad.
> Everything worked as expected and the touchpad was assigned to
> HID_GROUP_RMI and hid-rmi bound to it. The touchpad in this Dell
> system looks like it should be similar to the touchpads in other Dell
> systems which we have tested with hid-rmi. Like those other systems it
> does also have a PS/2 interface. But, I don't think that this is
> significant because i2c_hid is talking to the touchpad and is
> successfully reading the report descriptor. That would not interfere
> with the group assignment.
>
> The only thing that I can think of is either the hid module is being
> loaded with the ignore_special_drivers parameter set, or somehow an
> entry got added to the hid_have_special_driver list. I would guess the
> ignore_special_drivers parameter is set since there would not be an
> entry for our VID in hid_have_special_driver in a vanilla kernel.
>
> > As soon as I have something to inform, I'll keep you informed.
> >
> > Let me ask you one thing. What exactly is the "g" number in the device
> > id? The comments at the file include/linux/hid.h suggest it is a kind of
> > "group", but this "group" seems to be a special word in HID world, with
> > a meaning different than the common sense.
> >
>
> The hid-core driver parses the HID report descriptor and assigns the
> device a group based on the fields in the descriptor. Later, hid-core
> uses the group to determine which subdriver to bind to the device and
> the group number is included in modalias. Since, your touchpad has the
> Synaptics vendor id hid_scan_report should be assigning it the group
> HID_GROUP_RMI (g0100 in modalias since HID_GROUP_RMI is defined as
> 0x0100 in include/linux/hid.h). But, according to your modalias no
> group is being assigned.
>
> > Thanks again,
> >
> > Luiz
> >
> >
> > On Wed, Nov 5, 2014, at 13:35, Benjamin Tissoires wrote:
> >> Hi Luiz,
> >>
> >> On Wed, Nov 5, 2014 at 3:09 AM, Luiz Carlos Ramos
> >> <lramos.prof@yahoo.com.br> wrote:
> >> > Hi, Benjamin,
> >> >
> >> > Thanks again!
> >> >
> >> > Here it is an excerpt from $(udevadm info --export-db), I think the
> >> > relevant one:
> >> >
> >> > P:
> >> > /devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> >> > E:
> >> > DEVPATH=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0005
> >> > E: HID_ID=0018:000006CB:00002985
> >> > E: HID_NAME=DLL0652:00 06CB:2985
> >> > E: MODALIAS=hid:b0018g0000v000006CBp00002985
> >> > E: SUBSYSTEM=hid
> >> > E: UDEV_LOG=3
> >> >
> >> > Also, this is the same information, from
> >> > /sys/bus/hid/devices/0018:06CB:2985.0005/modalias:
> >> >
> >> > root@giustizia:/sys/bus/hid/devices/0018:06CB:2985.0005# cat modalias
> >> > hid:b0018g0000v000006CBp00002985
> >>
> >> So this is definitively wrong. g0000 means that your device has not
> >> been scanned for the reports. However, there is no way a vanilla
> >> kernel will not scan a Synaptics HID device.
> >> My guess is that your arch kernel has some crappy patches which
> >> prevent your touchpad to be bound to hid-rmi.
> >>
> >> Can you point out to the patches that has been added to the kernel
> >> tree by your distribution? (I never managed to find this information
> >> for arch)
> >>
> >> >
> >> > And, finally, the device descriptor:
> >> >
> >> > root@giustizia:/sys/kernel/debug/hid/0018:06CB:2985.0005# cat rdesc
> >> > 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01
> >> > 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06
> >> > c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02
> >> > 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00
> >> > 75 08 95 1d 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 1d 81 02 85 0f 09
> >> > 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
> >>
> >> Thanks. So after injecting this in my boxes, (which are currently a
> >> plain 3.16.3-200.fc20 from fedora 20, and a somewhat vanilla 3.18-rc3
> >> + Jiri's upstream hid patches for 3.19), hid-rmi picks up the device.
> >>
> >> Please try to use a vanilla kernel and see if things are better.
> >>
> >> >
> >> > Yesterday, after sending my reply, I figured out that vendor 06CB means
> >> > Synaptics; am I right?
> >>
> >> You are right.
> >>
> >> >
> >> > Also, again, if you'd like to me to code/patch/test anything, fell free
> >> > to ask me.
> >>
> >> Well, please try a vanilla kernel (3.16.7 if you want to keep your
> >> current config file, or a 3.17.2), and check if it does not magically
> >> works.
> >>
> >> Cheers,
> >> Benjamin
> >>
> >> >>
> >> >> On Tue, Nov 4, 2014 at 8:11 PM, Luiz Carlos Ramos
> >> >> <lramos.prof@yahoo.com.br> wrote:
> >> >> > Hi, Benjamin,
> >> >> >
> >> >> > I think I just wrote the email below in a way it suggests everything had
> >> >> > gone well and the issue was resolved... but unfortunately it's not the
> >> >> > case. In my reply, I wrote some remarks in the text body in that email,
> >> >> > but I think they weren't noticed at all given the first paragraph.
> >> >>
> >> >> Apologies for that. I read it, thought about it, and forgot it.
> >> >>
> >> >> >
> >> >> > Only to recall, the problem is with a Dell Inspiron 3442, that has a
> >> >> > touchpad which doesn't show up. It seems like it is a Synaptics I2C
> >> >> > device. Your last advice was to insmod hid-rmi, which would hopefully
> >> >> > make things go on after I2C basic device handshake. However, it didn't
> >> >> > happen.
> >> >>
> >> >> Yeah, so given the state of the 3.16 kernel and your tests, the group
> >> >> associated to the device is simply not the RMI one.
> >> >> Which is weird.
> >> >>
> >> >> >
> >> >> > I managed also to put some "printk" at the beginning and at the end of
> >> >> > the "probe" function of hid-rmi, and it seems both were not called. I
> >> >> > don't know if some kind of ioctl() should be issued, or if udevd should
> >> >> > be configured some special way, but my feeling is that I am missing
> >> >> > something really really important and obvious.
> >> >> >
> >> >>
> >> >> No, I think your device is in a black hole. If the device declares
> >> >> nothing special, it should be handled by hid-rmi. But given that it is
> >> >> not the case, it might declares itself as a multitouch capable, and
> >> >> should be handled by hid-multitouch. But if hid-multitouch does not
> >> >> drive it properly, that is weird.
> >> >>
> >> >> Can you provide the modalias of the HID device: in "udevadm info
> >> >> --export-db", look for the device attached to i2c_hid, and find its
> >> >> son which has a modalias in the form of
> >> >> MODALIAS=hid:b0018gXXXXv000006cbp00002985. I am interested in what is
> >> >> after the "g".
> >> >>
> >> >> Also, can you export the content of the report descriptor of your
> >> >> device. You can find it in
> >> >> /sys/kernel/debug/hid/0018\:06CB\:2985.*/rdesc assuming you have
> >> >> debugfs mounted under /sys/kernel/debug
> >> >>
> >> >> Cheers,
> >> >> Benjamin
> >> >>
> >> >> >
> >> >> >
> >> >> > On Thu, Oct 30, 2014, at 08:06, Luiz Carlos Ramos wrote:
> >> >> >> Hi Benjamin,
> >> >> >>
> >> >> >> Thanks for the assistance and quick reply.
> >> >> >>
> >> >> >> On Tue, Oct 28, 2014, at 23:40, Benjamin Tissoires wrote:
> >> >> >> > Hi Luiz,
> >> >> >> >
> >> >> >> > On Tue, Oct 28, 2014 at 9:00 PM, Luiz Carlos Ramos
> >> >> >> > <lramos.prof@yahoo.com.br> wrote:
> >> >> >> > > Hello,
> >> >> >> > >
> >> >> >> > > I'm trying to make a touchpad from a Dell Inspiron I14-3442 laptop work.
> >> >> >> > >
> >> >> >> > > Some details:
> >> >> >> > >
> >> >> >> > > - I'm using plain Slackware64 14.1, but raised the kernel to 3.16.3 for
> >> >> >> > > tests
> >> >> >> > >
> >> >> >> > > - xinput ignores the touchpad; it shows only a USB mouse/keyboard
> >> >> >> > > adapter and the laptop's keyboard:
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/hid/devices# xinput
> >> >> >> > > Virtual core pointer id=2 [master pointer
> >> >> >> > > (3)]
> >> >> >> > > Virtual core XTEST pointer id=4 [slave
> >> >> >> > > pointer (2)]
> >> >> >> > > Generic USB K/B id=12 [slave
> >> >> >> > > pointer (2)]
> >> >> >> > > Virtual core keyboard id=3 [master
> >> >> >> > > keyboard (2)]
> >> >> >> > > Virtual core XTEST keyboard id=5 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Power Button id=6 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Video Bus id=7 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Power Button id=9 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Sleep Button id=10 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Integrated_Webcam_HD id=13 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > AT Translated Set 2 keyboard id=14 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Dell WMI hotkeys id=15 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Video Bus id=8 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > > Generic USB K/B id=11 [slave
> >> >> >> > > keyboard (3)]
> >> >> >> > >
> >> >> >> > > - it seems Ubuntu certified this machine (check
> >> >> >> > > http://www.ubuntu.com/certification/hardware/201402-14674/components/),
> >> >> >> > > but it assumes the touchpad is PS/2. I haven't found it as a PS/2 thing,
> >> >> >> > > even loading psmouse.ko, or doing other tricks
> >> >> >> > >
> >> >> >> > > - some articles lists some tips for making it work (like
> >> >> >> > > http://askubuntu.com/questions/134627/how-do-i-get-the-touchpad-settings-working-on-a-dell-xps-13-ultrabook,
> >> >> >> > > or https://bugzilla.redhat.com/show_bug.cgi?id=1048314#c2), but I read
> >> >> >> > > them carefully, made some tests, and they didn't work. One article says
> >> >> >> > > I could blacklist i2c_hid or like in order to make the bring up the
> >> >> >> > > touchpad in PS/2 mode, but I couldn't succeed doing so
> >> >> >> > >
> >> >> >> > > - at Dell's site, it is offered a driver for Ubuntu 12.04, but it's
> >> >> >> > > almost obsolete. It seems to be just merged into the kernel
> >> >> >> > >
> >> >> >> > > - from Windows 8.1, which runs in the same machine (dual boot), I
> >> >> >> > > concluded the proper way of making it work is to use HID over I2C. It
> >> >> >> > > seems that there are two components loaded; one I2CHID, and a Synaptics
> >> >> >> > > HID. This makes me hint it may be a Synaptics device
> >> >> >> >
> >> >> >> > Well, if this is a Synaptics HID over I2C device, it should be handled
> >> >> >> > by hid-rmi in recent kernels (or hid-multitouch but I would say
> >> >> >> > hid-rmi in your case).
> >> >> >> > Is the hid-rmi module loaded? Can we get a dmesg output so we can see
> >> >> >> > if there is any problem?
> >> >> >> >
> >> >> >> > >
> >> >> >> > > - it seems there are two I2C busses in the machine. One is related to
> >> >> >> > > the Intel video graphics subsystem (i801). The other seems to be linked
> >> >> >> > > to the touchpad (i2c_designware_platform). I'm not sure that latest kmod
> >> >> >> > > (i2c_designware_platform) is the right one to be used in this case, but
> >> >> >> > > it appears to be working:
> >> >> >> >
> >> >> >> > Yeah, i2c_designware_platform is pretty common for Haswell processors.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/i2c/devices# ls -l /sys/bus/i2c/devices
> >> >> >> > > total 0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-0 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C2:00/i2c-0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-1 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-2 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-2
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-3 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-3
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-4 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-4
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-5 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-5
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-6 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-6
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-7 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-7
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-8 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:02.0/i2c-8
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 18 17:26 i2c-DLL0652:00 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00
> >> >> >> >
> >> >> >> > This one is the touchpad.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/i2c/devices# lsmod | grep i2c
> >> >> >> > > i2c_hid 10682 0
> >> >> >> > > hid 94632 3 i2c_hid,hid_generic,usbhid
> >> >> >> > > i2c_dev 5739 0
> >> >> >> > > i2c_designware_platform 3189 0
> >> >> >> > > i2c_i801 13732 0
> >> >> >> > > i2c_designware_core 6045 1 i2c_designware_platform
> >> >> >> > > i2c_algo_bit 5351 1 i915
> >> >> >> > > i2c_core 35216 11
> >> >> >> > > drm,i915,i2c_i801,i2c_dev,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,v4l2_common,synaptics_i2c,videodev
> >> >> >> > >
> >> >> >> > > - in the HID /sys directory, there are three devices. Two are related to
> >> >> >> > > a keyboard/mouse USB adapter. The third seems to be the linked to the
> >> >> >> > > touchpad:
> >> >> >> > >
> >> >> >> > > root@pace:/sys/bus/hid/devices# ls -l /sys/bus/hid/devices
> >> >> >> > > total 0
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.004F ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:13BA:0017.004F
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0003:13BA:0017.0050 ->
> >> >> >> > > ../../../devices/pci0000:00/0000:00:1d.0/usb3/3-1/3-1.3/3-1.3:1.1/0003:13BA:0017.0050
> >> >> >> > > lrwxrwxrwx 1 root root 0 Out 28 22:40 0018:06CB:2985.0052 ->
> >> >> >> > > ../../../devices/pci0000:00/INT33C3:00/i2c-1/i2c-DLL0652:00/0018:06CB:2985.0052
> >> >> >> >
> >> >> >> > This is the HID over I2C touchpad.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > - when I load the kernel module i2c-hid.ko (with debug=1), I read this
> >> >> >> > > in dmesg:
> >> >> >> > >
> >> >> >> > > [146172.568787] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> >> > > [146172.568791] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> >> > > [146172.574806] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> >> > > 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> >> > > 00
> >> >> >> > > [146172.574845] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> >> > > [146172.574847] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> >> > > [146172.574849] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> > > [146172.574850] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> > > 08
> >> >> >> > > [146172.575436] i2c_hid i2c-DLL0652:00: resetting...
> >> >> >> > > [146172.575442] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> > > 01
> >> >> >> > > [146172.576113] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> >> > > [146172.577414] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> >> > > [146172.577417] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> >> > > [146172.577419] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> >> > > [146172.581072] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> >> > > a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> >> > > 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> >> > > ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> >> > > [146172.581126] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> > > [146172.581129] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> >> > > 08
> >> >> >> >
> >> >> >> > Everything is fine, this is the normal behavior while connecting a
> >> >> >> > i2c_hid device.
> >> >> >> > Normally, we should have then hid-rmi asking for more things and then
> >> >> >> > it will eventually set up the input device.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > I am aware this information probably is not sufficient to draw any
> >> >> >> > > conclusions, but I'd appreciate to hear from someone who knows i2c_hid
> >> >> >> > > in detail what steps I should take next. For me the last command timed
> >> >> >> > > out or got stuck, but I haven't checked the code to see if it's the
> >> >> >> > > case. Anyway, if it was a timeout case, it should have something logged
> >> >> >> > > after the time expired.
> >> >> >> >
> >> >> >> > There is no answer from the device when a SET_POWER is emitted. So
> >> >> >> > this is not a timeout problem.
> >> >> >> >
> >> >> >> > If hid-rmi is compiled and is not taking the device, we have a big
> >> >> >> > problem, but for now, the symptoms look like you do not have this
> >> >> >> > driver compiled and hid-generic does not bind the device because it
> >> >> >> > waits for hid-rmi to handle it.
> >> >> >> >
> >> >> >>
> >> >> >> Well, I tried to insmod hid-rmi, and nothing special happened. Here is a
> >> >> >> dmesg output (relevant lines):
> >> >> >>
> >> >> >> [158885.774386] i2c_hid i2c-DLL0652:00: Fetching the HID descriptor
> >> >> >> [158885.774391] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=20 00
> >> >> >> [158885.785853] i2c_hid i2c-DLL0652:00: HID Descriptor: 1e 00 00 01 85
> >> >> >> 00 21 00 24 00 20 00 25 00 17 00 22 00 23 00 cb 06 85 29 00 00 00 00 00
> >> >> >> 00
> >> >> >> [158885.785924] i2c_hid i2c-DLL0652:00: entering i2c_hid_parse
> >> >> >> [158885.785926] i2c_hid i2c-DLL0652:00: i2c_hid_hwreset
> >> >> >> [158885.785927] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> [158885.785928] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> 08
> >> >> >> [158885.786494] i2c_hid i2c-DLL0652:00: resetting...
> >> >> >> [158885.786497] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 00
> >> >> >> 01
> >> >> >> [158885.787285] i2c_hid i2c-DLL0652:00: __i2c_hid_command: waiting...
> >> >> >> [158885.788496] i2c_hid i2c-DLL0652:00: __i2c_hid_command: finished.
> >> >> >> [158885.788499] i2c_hid i2c-DLL0652:00: asking HID report descriptor
> >> >> >> [158885.788501] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=21 00
> >> >> >> [158885.792194] i2c_hid i2c-DLL0652:00: Report Descriptor: 05 01 09 02
> >> >> >> a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02
> >> >> >> 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00
> >> >> >> ff 09 01 a1 01 85 09 09 02 15 00 26
> >> >> >> [158885.792252] i2c_hid i2c-DLL0652:00: i2c_hid_set_power
> >> >> >> [158885.792254] i2c_hid i2c-DLL0652:00: __i2c_hid_command: cmd=22 00 01
> >> >> >> 08
> >> >> >>
> >> >> >> I included lines like:
> >> >> >>
> >> >> >> printk(KERN_ERR "hid_rmi_probe(): called\n");
> >> >> >> printk(KERN_ERR "hid_rmi_probe(): ret=0\n");
> >> >> >>
> >> >> >> in the beginning and at the end of the routine rmi_probe(). These lines
> >> >> >> didn't
> >> >> >> appear in dmesg (those pictured above). I don't know if "probe" is to be
> >> >> >> called
> >> >> >> in this case, or not. Is there any other condition to make hid-rmi be
> >> >> >> "instantiated",
> >> >> >> I mean, other kmod to be loaded, or a special ioctl() coming to the hid
> >> >> >> from userland,
> >> >> >> or even echoing something to the "bind" file at /sys/...?
> >> >> >>
> >> >> >> Well, here's the "directory" /sys/bus/hid/drivers/hid-rmi:
> >> >> >>
> >> >> >> root@pace:/sys/bus/hid/drivers/hid-rmi# ls -l
> >> >> >> /sys/bus/hid/drivers/hid-rmi/
> >> >> >> total 0
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 bind
> >> >> >> lrwxrwxrwx 1 root root 0 Out 30 08:03 module ->
> >> >> >> ../../../../module/hid_rmi
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 new_id
> >> >> >> --w------- 1 root root 4096 Out 30 07:48 uevent
> >> >> >> --w------- 1 root root 4096 Out 30 08:03 unbind
> >> >> >>
> >> >> >> One thing I didn't still did is to reboot the machine. I found it was
> >> >> >> not the case,
> >> >> >> but this type of action use to work a lot in IT/IS, right? :-)
> >> >> >>
> >> >> >> > >
> >> >> >> > > I have some programming skills, and so if it's the case of applying any
> >> >> >> > > patches, or recompiling the kernel or any subsystem to make tests, I'm
> >> >> >> > > up to.
> >> >> >> >
> >> >> >> > Cool, thanks.
> >> >> >> >
> >> >> >> > Cheers,
> >> >> >> > Benjamin
> >> >> >>
> >> >> >> Many thanks,
> >> >> >>
> >> >> >> Luiz
^ permalink raw reply
* Re: [PATCH 1/4] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Richard Cochran @ 2014-11-07 10:17 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,
Dmitry Torokhov, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Samuel Ortiz, Jan Kardell,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Sebastian Andrzej Siewior,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi, Paul Gortmaker,
Peter Meerwald, Hartmut Knaack, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Lee Jones, linux-arm
In-Reply-To: <545C59CD.3070707-l0cyMroinI0@public.gmane.org>
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote:
> Currently, there is too much noise in the TSC hardware that is being
> removed by delta filtering. I tested TSC unit by removing filtering
> logic, the performance was not at all satisfactory. The cursor jumps
> wayward and smooth circles cannot be drawn. Looks like delta filtering
> cannot be removed as of now. May be I will try and address it in future.
FWIW, on the boards that I tested, I printed the measured values out,
and I found that with 5 repetitions, I got the same value 5 times,
plus or minus a very small delta.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] HID: wacom - make sure touch_input is valid before using it
From: Jiri Kosina @ 2014-11-07 15:42 UTC (permalink / raw)
To: Ping Cheng; +Cc: dmitry.torokhov, linux-input, Ping Cheng
In-Reply-To: <1415323851-16453-1-git-send-email-pingc@wacom.com>
On Thu, 6 Nov 2014, Ping Cheng wrote:
> touch_input is stored in wacom_shared for pen data to report touch
> switch status. It is possible, although we didn't see it happen on
> Linux yet, that pen data is procesed before touch interface is
> fully probed.
>
> As a by-product of this patch, it fixes the FreeBSD issue reported
> by Denis Akiyakov http://www.spinics.net/lists/linux-input/msg33971.html
>
> Reviewed-by: Hans Petter Selasky <hps@selasky.org>
> Tested-by: Denis Akiyakov <d.akiyakov@gmail.com>
> Signed-off-by: Ping Cheng <pingc@wacom.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Help writing a custom HID driver
From: Jose Diez @ 2014-11-07 17:18 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input
In-Reply-To: <545BE060.7020600@mediacru.sh>
Hi, it's me again.
So I'm trying to use the Linux input system to report key events from
the device.
This is my code so far: http://sprunge.us/KfhF
As you can see, I'm trying to send event 1 whenever the watchdog work is
executed.
I can see from dmesg that the task is actually being executed, but when
I run evtest
to check if I actually receive the messages, I see nothing.
Any help would be much appreciated.
Thanks,
Jose
On 06/11/14 20:56, Jose Diez wrote:
> Ah, I was hoping there would be a way to avoid having to patch the
> kernel itself.
>
> Thanks again,
> Jose
> On 06/11/14 20:22, Benjamin Tissoires wrote:
>> On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez<jose@mediacru.sh> wrote:
>>> Okay, so I've solved the watchdog issue, and now I want the driver
>>> to be
>>> loaded automatically. I've copied the module to
>>> /lib/modules/<kernel>/ and
>>> run depmod -a, and I can see it in modules.alias, but it looks like
>>> hid_generic grabs it first upon boot - my module is loaded
>>> correctly, but it
>>> doesn't grab the HID device.
>>>
>>> If I `modprobe -r hid_generic` and then load my module, everything
>>> works
>>> correctly.
>> Yep. You need to add your device VendorID/ProductID in
>> hid_have_special_driver[] in hid-core.c.
>> This will tell hid-generic not to grab your device, and your custom
>> module will take over.
>>
>> Cheers,
>> Benjamin
>>
>>> On 06/11/14 19:28, Jose Diez wrote:
>>>> Thanks Benjamin. That fixed the issue. Have a great day.
>>>>
>>>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>>> Hi Jose,
>>>>>
>>>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez<jose@mediacru.sh> wrote:
>>>>>> Hello linux-input,
>>>>>>
>>>>>> I'm trying to write a custom HID driver. It works fine, and I can
>>>>>> send
>>>>>> reports just fine, but one of the requirements of this device is
>>>>>> that I
>>>>>> have
>>>>>> to reply to reports with code 62 with another report with code
>>>>>> 62, which
>>>>>> resets a watchdog in the device.
>>>>>>
>>>>>> This is my code so far:http://codepad.org/m4QiWhDt
>>>>>>
>>>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>>>> surrounding the call with spin_locks, but I still get the
>>>>>> "scheduling
>>>>>> while
>>>>>> atomic" error.
>>>>> Yeah, when you are in the .event callback, you are basically
>>>>> called by
>>>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>>>
>>>>>> I'm not sure how to approach this - can someone help? It would be
>>>>>> much
>>>>>> appreciated. Thanks.
>>>>> I would use a worker to do what you are trying to do. You can have a
>>>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>>>> When the event is not one we expected, we schedule a worker thread
>>>>> which then sends an output report to the device. This way, the
>>>>> blocking operation is sent from a different thread than the IRQ one.
>>>>> It is kind of what you are willing to do.
>>>>> There are many other examples of workers in the hid subtree, or you
>>>>> can refer to the doc to find out more.
>>>>>
>>>>> Cheers,
>>>>> Benjamin
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-input" in
>>>>> the body of a message tomajordomo@vger.kernel.org
>>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-input" in
>>>> the body of a message tomajordomo@vger.kernel.org
>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-input" in
>> the body of a message tomajordomo@vger.kernel.org
>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PROBLEM: Lenovo ThinkPad X1 Carbon Wireless switch key doesn't work
From: Sergei Serdyuk @ 2014-11-07 17:23 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: platform-driver-x86, linux-input
In-Reply-To: <CAN+gG=FsASrEvxgFfddHeMOR0eMWQcBSWA2KebXTVkGUzOcyFA@mail.gmail.com>
I am reporting it in hope to make other Thinkpad users' experience
better, especially the first-time ones. I am very new to this all, in
fact my first time reporting a bug, and I'm just following the
protocol. If there's anywhere else I need to email or post to, please
let me know.
--
Regards, Sergei Serdyuk
RedLeaf Software LLC
web: http://redleafsoft.com
email: sergei@redleafsoft.com
phone: 802-7350730
On Thu, Nov 6, 2014 at 10:17 AM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi,
>
> not that we can not help here on linux-input, but this file is managed
> by the platform tree.
> Adding them in CC in case somebody already fixed the problem.
>
> Cheers,
> Benjamin
>
> On Thu, Nov 6, 2014 at 8:07 AM, Sergei Serdyuk <sergei@redleafsoft.com> wrote:
>> [1] [Lenovo ThinkPad X1 Carbon 20A8] Wireless switch key doesn't work
>>
>> [2] On my X1 Carbon laptop the wireless switch key doesn't work. It
>> appears that the code in charge of handling the X1 Carbon adaptive
>> keyboard is here and rfkill handling is there:
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/jic23/iio/+/refs/heads/togreg/drivers/platform/x86/thinkpad_acpi.c
>>
>> Pressing the key generates no events (see below) and thus has no
>> effect. So, it's either my stock kernel doesn't have it, or something
>> else is broken. Nothing ever fires when I press all extra buttons
>> including the wireless one.
>>
>> This may be not specific to the adaptive keyboard too. While I was
>> googling for a solution, I saw similar complaints for other Thinkpad
>> models.
>>
>> ls /dev/input/by-path/platform-thinkpad_acpi-event -lh
>> lrwxrwxrwx 1 root root 9 Nov 2 19:45
>> /dev/input/by-path/platform-thinkpad_acpi-event -> ../event7
>>
>> input-events 7
>> /dev/input/event7
>> bustype : BUS_HOST
>> vendor : 0x17aa
>> product : 0x5054
>> version : 16641
>> name : "ThinkPad Extra Buttons"
>> phys : "thinkpad_acpi/input0"
>> bits ev : EV_SYN EV_KEY EV_MSC EV_SW
>>
>> waiting for events
>> timeout, quitting
>>
>> # acpi events fire for all extra buttons except the wireless one!
>>
>> root@x1:~# acpi_listen -t 100
>> ibm/hotkey LEN0068:00 00000080 00001105
>> ibm/hotkey LEN0068:00 00000080 00001106
>> ibm/hotkey LEN0068:00 00000080 00001108
>> ibm/hotkey LEN0068:00 00000080 0000110a
>> ibm/hotkey LEN0068:00 00000080 00001101
>> ibm/hotkey LEN0068:00 00000080 00001101
>> ibm/hotkey LEN0068:00 00000080 00001101
>> video/switchmode VMOD 00000080 00000000
>> ibm/hotkey LEN0068:00 00000080 0000110e
>>
>> So, since nothing fires on both channels, it seems I can't manually
>> bind the button to rfkill either.
>>
>> [3]
>>
>> [4] $cat /proc/version
>>
>> Linux version 3.18.0-031800rc3-generic (apw@tangerine) (gcc version
>> 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411022335 SMP Sun Nov 2
>> 23:36:52 UTC 2014
>>
>> [5]
>>
>> [6]
>>
>> [7] $lsb_release -rd
>>
>> Description: Ubuntu 14.10
>> Release: 14.10
>>
>> [7.1] $/usr/src/linux-headers-3.18.0-031800rc3/scripts/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 x1 3.18.0-031800rc3-generic #201411022335 SMP Sun Nov 2 23:36:52
>> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Gnu C 4.9.1
>> Gnu make 4.0
>> binutils 2.24.90.20141014
>> util-linux 2.25.1
>> mount debug
>> module-init-tools 18
>> e2fsprogs 1.42.10
>> 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.23
>> wireless-tools 30
>> Modules Loaded ctr ccm acpi_call uvcvideo videobuf2_vmalloc
>> videobuf2_memops videobuf2_core v4l2_common videodev media
>> hid_multitouch btusb arc4 iwlmvm mac80211 intel_rapl
>> x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi kvm rfcomm
>> joydev bnep serio_raw bluetooth cfg80211 snd_hda_codec_hdmi mei_me
>> lpc_ich snd_hda_codec_realtek snd_hda_codec_generic mei shpchp
>> thinkpad_acpi snd_hda_intel snd_hda_controller i2c_designware_platform
>> i2c_designware_core nvram snd_hda_codec snd_hwdep snd_pcm mac_hid
>> snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device
>> snd_timer parport_pc snd ppdev soundcore nls_iso8859_1 lp parport
>> dm_crypt usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
>> i915 aesni_intel aes_x86_64 lrw gf128mul e1000e glue_helper
>> i2c_algo_bit ablk_helper ahci cryptd libahci ptp pps_core psmouse
>> drm_kms_helper drm wmi video
>>
>> [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 : 0x1c
>> cpu MHz : 1299.949
>> 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 : 4589.44
>> 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 : 0x1c
>> cpu MHz : 974.625
>> 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 : 4589.44
>> 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 : 0x1c
>> cpu MHz : 1299.769
>> 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 : 4589.44
>> 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 : 0x1c
>> cpu MHz : 1359.425
>> 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 : 4589.44
>> clflush size : 64
>> cache_alignment : 64
>> address sizes : 39 bits physical, 48 bits virtual
>> power management:
>>
>> [7.3] $cat /proc/modules
>>
>> ctr 13193 3 - Live 0xffffffffc08b0000
>> ccm 17856 3 - Live 0xffffffffc08aa000
>> acpi_call 12714 0 - Live 0xffffffffc08a5000 (OE)
>> uvcvideo 86723 0 - Live 0xffffffffc0a4c000
>> videobuf2_vmalloc 13216 1 uvcvideo, Live 0xffffffffc0885000
>> videobuf2_memops 13362 1 videobuf2_vmalloc, Live 0xffffffffc088a000
>> videobuf2_core 51547 1 uvcvideo, Live 0xffffffffc0897000
>> v4l2_common 15715 1 videobuf2_core, Live 0xffffffffc086a000
>> videodev 163831 3 uvcvideo,videobuf2_core,v4l2_common, Live 0xffffffffc09e5000
>> media 22008 2 uvcvideo,videodev, Live 0xffffffffc087e000
>> hid_multitouch 17657 0 - Live 0xffffffffc0891000
>> btusb 32691 0 - Live 0xffffffffc0875000
>> arc4 12573 2 - Live 0xffffffffc07d3000
>> iwlmvm 254598 0 - Live 0xffffffffc09a5000
>> mac80211 697143 1 iwlmvm, Live 0xffffffffc0a84000
>> intel_rapl 19196 0 - Live 0xffffffffc086f000
>> x86_pkg_temp_thermal 14312 0 - Live 0xffffffffc07db000
>> intel_powerclamp 19099 0 - Live 0xffffffffc0864000
>> coretemp 13638 0 - Live 0xffffffffc0746000
>> iwlwifi 193774 1 iwlmvm, Live 0xffffffffc0a1b000
>> kvm 475233 0 - Live 0xffffffffc092f000
>> rfcomm 75066 0 - Live 0xffffffffc07bf000
>> joydev 17587 0 - Live 0xffffffffc07a9000
>> bnep 23980 2 - Live 0xffffffffc074b000
>> serio_raw 13483 0 - Live 0xffffffffc0729000
>> bluetooth 486890 11 btusb,rfcomm,bnep, Live 0xffffffffc08b7000
>> cfg80211 520257 3 iwlmvm,mac80211,iwlwifi, Live 0xffffffffc07e3000
>> snd_hda_codec_hdmi 52670 1 - Live 0xffffffffc07b1000
>> mei_me 19565 0 - Live 0xffffffffc0776000
>> lpc_ich 21176 0 - Live 0xffffffffc06d8000
>> snd_hda_codec_realtek 76099 1 - Live 0xffffffffc0791000
>> snd_hda_codec_generic 69995 1 snd_hda_codec_realtek, Live 0xffffffffc077e000
>> mei 88473 1 mei_me, Live 0xffffffffc075f000
>> shpchp 37216 0 - Live 0xffffffffc0754000
>> thinkpad_acpi 82101 1 - Live 0xffffffffc0730000
>> snd_hda_intel 30783 5 - Live 0xffffffffc0720000
>> snd_hda_controller 32234 1 snd_hda_intel, Live 0xffffffffc070f000
>> i2c_designware_platform 13025 0 - Live 0xffffffffc070a000
>> i2c_designware_core 14990 1 i2c_designware_platform, Live 0xffffffffc071b000
>> nvram 14462 1 thinkpad_acpi, Live 0xffffffffc06d3000
>> snd_hda_codec 144641 5
>> snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller,
>> Live 0xffffffffc06e5000
>> snd_hwdep 17709 1 snd_hda_codec, Live 0xffffffffc06df000
>> snd_pcm 106273 4
>> snd_hda_codec_hdmi,snd_hda_intel,snd_hda_controller,snd_hda_codec,
>> Live 0xffffffffc06b8000
>> mac_hid 13275 0 - Live 0xffffffffc05b5000
>> snd_seq_midi 13564 0 - Live 0xffffffffc05b0000
>> snd_seq_midi_event 14899 1 snd_seq_midi, Live 0xffffffffc059f000
>> snd_rawmidi 31197 1 snd_seq_midi, Live 0xffffffffc05a7000
>> snd_seq 63540 2 snd_seq_midi,snd_seq_midi_event, Live 0xffffffffc058e000
>> snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0xffffffffc048d000
>> snd_timer 30118 2 snd_pcm,snd_seq, Live 0xffffffffc057a000
>> parport_pc 32909 0 - Live 0xffffffffc0584000
>> snd 84025 22 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,thinkpad_acpi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
>> Live 0xffffffffc0564000
>> ppdev 17711 0 - Live 0xffffffffc055e000
>> soundcore 15091 2 snd_hda_codec,snd, Live 0xffffffffc0528000
>> nls_iso8859_1 12713 1 - Live 0xffffffffc04e8000
>> lp 17799 0 - Live 0xffffffffc0522000
>> parport 42481 3 parport_pc,ppdev,lp, Live 0xffffffffc054e000
>> dm_crypt 23456 1 - Live 0xffffffffc0486000
>> usbhid 53155 0 - Live 0xffffffffc04da000
>> hid 110572 2 hid_multitouch,usbhid, Live 0xffffffffc0532000
>> crct10dif_pclmul 14268 0 - Live 0xffffffffc051d000
>> crc32_pclmul 13180 0 - Live 0xffffffffc052d000
>> ghash_clmulni_intel 13230 0 - Live 0xffffffffc0433000
>> i915 1031913 6 - Live 0xffffffffc05bb000
>> aesni_intel 169686 8 - Live 0xffffffffc04ef000
>> aes_x86_64 17131 1 aesni_intel, Live 0xffffffffc0497000
>> lrw 13323 1 aesni_intel, Live 0xffffffffc042e000
>> gf128mul 14951 1 lrw, Live 0xffffffffc0481000
>> e1000e 230020 0 - Live 0xffffffffc04a0000
>> glue_helper 14095 1 aesni_intel, Live 0xffffffffc03cf000
>> i2c_algo_bit 13564 1 i915, Live 0xffffffffc0492000
>> ablk_helper 13597 1 aesni_intel, Live 0xffffffffc03b6000
>> ahci 34220 3 - Live 0xffffffffc0439000
>> cryptd 20531 4 ghash_clmulni_intel,aesni_intel,ablk_helper, Live
>> 0xffffffffc03c8000
>> libahci 32446 1 ahci, Live 0xffffffffc0425000
>> ptp 19534 1 e1000e, Live 0xffffffffc03c2000
>> pps_core 19381 1 ptp, Live 0xffffffffc0443000
>> psmouse 118117 0 - Live 0xffffffffc0463000
>> drm_kms_helper 99802 1 i915, Live 0xffffffffc0449000
>> drm 323675 5 i915,drm_kms_helper, Live 0xffffffffc03d4000
>> wmi 19379 0 - Live 0xffffffffc03bc000
>> video 20649 1 i915, Live 0xffffffffc03af000
>>
>> [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
>> 0061-0061 : PNP0800:00
>> 0062-0062 : PNP0C09:00
>> 0062-0062 : EC data
>> 0064-0064 : keyboard
>> 0066-0066 : PNP0C09:00
>> 0066-0066 : EC cmd
>> 0070-0071 : rtc0
>> 0080-008f : dma page reg
>> 00a0-00a1 : pic2
>> 00c0-00df : dma2
>> 00f0-00ff : fpu
>> 00f0-00f0 : PNP0C04:00
>> 0800-087f : pnp 00:01
>> 0880-08ff : pnp 00:01
>> 0900-097f : pnp 00:01
>> 0980-09ff : pnp 00:01
>> 0a00-0a7f : pnp 00:01
>> 0a80-0aff : pnp 00:01
>> 0b00-0b7f : pnp 00:01
>> 0b80-0bff : pnp 00:01
>> 0cf8-0cff : PCI conf1
>> 0d00-ffff : PCI Bus 0000:00
>> 15e0-15ef : pnp 00:01
>> 1600-167f : pnp 00:01
>> 1640-165f : 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
>> 1860-187f : iTCO_wdt
>> 1880-189f : ACPI GPE0_BLK
>> 2000-2fff : PCI Bus 0000:02
>> 3000-303f : 0000:00:02.0
>> 3060-307f : 0000:00:1f.2
>> 3060-307f : ahci
>> 3080-309f : 0000:00:19.0
>> 30a0-30a7 : 0000:00:1f.2
>> 30a0-30a7 : ahci
>> 30a8-30af : 0000:00:1f.2
>> 30a8-30af : ahci
>> 30b0-30b3 : 0000:00:1f.2
>> 30b0-30b3 : ahci
>> 30b4-30b7 : 0000:00:1f.2
>> 30b4-30b7 : ahci
>> efa0-efbf : 0000:00:1f.3
>>
>> $cat /proc/iomem
>>
>> 00000000-00000fff : reserved
>> 00001000-00057fff : System RAM
>> 00058000-00058fff : reserved
>> 00059000-0009bfff : System RAM
>> 0009c000-0009cfff : reserved
>> 0009d000-0009dfff : System RAM
>> 0009e000-000bffff : 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
>> 000e0000-000e3fff : PCI Bus 0000:00
>> 000e4000-000e7fff : PCI Bus 0000:00
>> 000e8000-000ebfff : PCI Bus 0000:00
>> 000ec000-000effff : PCI Bus 0000:00
>> 000f0000-000fffff : System ROM
>> 00100000-b1851fff : System RAM
>> 02000000-027ae357 : Kernel code
>> 027ae358-02d1997f : Kernel data
>> 02e80000-02fc8fff : Kernel bss
>> b1852000-b1a53fff : reserved
>> b1a54000-bbf6cfff : System RAM
>> bbf6d000-bc16cfff : reserved
>> bc16d000-bcd3efff : reserved
>> bcd3f000-bce7efff : ACPI Non-volatile Storage
>> bce7f000-bcefefff : ACPI Tables
>> bceff000-bcefffff : System RAM
>> bcf00000-febfffff : reserved
>> bda00000-bf9fffff : Graphics Stolen Memory
>> bfa00000-febfffff : PCI Bus 0000:00
>> bfb00000-bfcfffff : PCI Bus 0000:02
>> bfd00000-bfefffff : PCI Bus 0000:02
>> c0000000-dfffffff : 0000:00:02.0
>> e0000000-e03fffff : 0000:00:02.0
>> e0400000-e04fffff : PCI Bus 0000:03
>> e0400000-e0401fff : 0000:03:00.0
>> e0400000-e0401fff : iwlwifi
>> e0500000-e051ffff : 0000:00:19.0
>> e0500000-e051ffff : e1000e
>> e0520000-e052ffff : 0000:00:14.0
>> e0520000-e052ffff : xhci-hcd
>> e0530000-e0533fff : 0000:00:03.0
>> e0530000-e0533fff : ICH HD audio
>> e0534000-e0537fff : 0000:00:1b.0
>> e0534000-e0537fff : ICH HD audio
>> e0538000-e05380ff : 0000:00:1f.3
>> e0539000-e053901f : 0000:00:16.0
>> e0539000-e053901f : mei_me
>> e053c000-e053c7ff : 0000:00:1f.2
>> e053c000-e053c7ff : ahci
>> e053d000-e053d3ff : 0000:00:1d.0
>> e053d000-e053d3ff : ehci_hcd
>> e053e000-e053efff : 0000:00:19.0
>> e053e000-e053efff : e1000e
>> f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
>> f80f8000-f80f8fff : reserved
>> fe101000-fe112fff : reserved
>> fe105000-fe105fff : INT33C3:00
>> fe105000-fe105fff : INT33C3:00
>> fec00000-fec003ff : IOAPIC 0
>> fed00000-fed003ff : HPET 0
>> fed00000-fed003ff : PNP0103:00
>> fed10000-fed13fff : pnp 00:01
>> fed18000-fed18fff : pnp 00:01
>> fed19000-fed19fff : pnp 00:01
>> fed1c000-fed1ffff : reserved
>> fed1c000-fed1ffff : pnp 00:01
>> fed1f410-fed1f414 : iTCO_wdt
>> fed40000-fed4bfff : PCI Bus 0000:00
>> fed45000-fed4bfff : pnp 00:01
>> fed4c000-ffffffff : pnp 00:00
>> fee00000-fee00fff : Local APIC
>> 100000000-23f5fffff : System RAM
>> 23f600000-23fffffff : RAM buffer
>>
>> [7.5] $lspci -vvv
>>
>> 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 09)
>> Subsystem: Lenovo Device 2218
>> 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
>> Capabilities: [e0] Vendor Specific Information: Len=0c <?>
>>
>> 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT
>> Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
>> Subsystem: Lenovo Device 2218
>> 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 43
>> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
>> Region 2: Memory at c0000000 (64-bit, prefetchable) [size=512M]
>> Region 4: I/O ports at 3000 [size=64]
>> Expansion ROM at <unassigned> [disabled]
>> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> Address: fee0f00c 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: Lenovo Device 2218
>> 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 45
>> Region 0: Memory at e0530000 (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: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> Address: fee0f00c Data: 4172
>> 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:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev
>> 04) (prog-if 30 [XHCI])
>> Subsystem: Lenovo Device 2218
>> 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 e0520000 (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: 4191
>> Kernel driver in use: xhci_hcd
>>
>> 00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
>> Subsystem: Lenovo Device 2218
>> 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 46
>> Region 0: Memory at e0539000 (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: 4182
>> Kernel driver in use: mei_me
>>
>> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection
>> I218-V (rev 04)
>> Subsystem: Lenovo Device 2214
>> 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-
>> Interrupt: pin A routed to IRQ 42
>> Region 0: Memory at e0500000 (32-bit, non-prefetchable) [disabled] [size=128K]
>> Region 1: Memory at e053e000 (32-bit, non-prefetchable) [disabled] [size=4K]
>> Region 2: I/O ports at 3080 [disabled] [size=32]
>> Capabilities: [c8] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=1 PME-
>> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000fee0f00c Data: 41b2
>> Capabilities: [e0] PCI Advanced Features
>> AFCap: TP+ FLR+
>> AFCtrl: FLR-
>> AFStatus: TP-
>> Kernel driver in use: e1000e
>>
>> 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
>> Subsystem: Lenovo Device 2218
>> 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 44
>> Region 0: Memory at e0534000 (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: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000fee0f00c Data: 4162
>> 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 8 Series PCI Express Root Port 6
>> (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: 00002000-00002fff
>> Memory behind bridge: bfb00000-bfcfffff
>> Prefetchable memory behind bridge: 00000000bfd00000-00000000bfefffff
>> 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 #6, 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-
>> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
>> Slot #0, PowerLimit 0.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 Via
>> WAKE# ARIFwd-
>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF
>> Disabled ARIFwd-
>> 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: -3.5dB, EqualizationComplete-,
>> EqualizationPhase1-
>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>> Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
>> Address: 00000000 Data: 0000
>> Capabilities: [90] Subsystem: Lenovo Device 2218
>> 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.1 PCI bridge: Intel Corporation 8 Series 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=03, subordinate=03, sec-latency=0
>> I/O behind bridge: 0000f000-00000fff
>> Memory behind bridge: e0400000-e04fffff
>> 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 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-
>> 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: Lenovo Device 2218
>> 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 8 Series USB EHCI #1 (rev
>> 04) (prog-if 20 [EHCI])
>> Subsystem: Lenovo Device 2218
>> 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 e053d000 (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 8 Series LPC Controller (rev 04)
>> Subsystem: Lenovo Device 2218
>> 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 8 Series SATA Controller 1
>> [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
>> Subsystem: Lenovo Device 2218
>> 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 41
>> Region 0: I/O ports at 30a8 [size=8]
>> Region 1: I/O ports at 30b4 [size=4]
>> Region 2: I/O ports at 30a0 [size=8]
>> Region 3: I/O ports at 30b0 [size=4]
>> Region 4: I/O ports at 3060 [size=32]
>> Region 5: Memory at e053c000 (32-bit, non-prefetchable) [size=2K]
>> Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> Address: fee0c00c 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 8 Series SMBus Controller (rev 04)
>> Subsystem: Lenovo Device 2218
>> 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 e0538000 (64-bit, non-prefetchable) [size=256]
>> Region 4: I/O ports at efa0 [size=32]
>>
>> 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
>> Subsystem: Intel Corporation Dual Band Wireless-N 7260
>> 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 e0400000 (64-bit, non-prefetchable) [size=8K]
>> Capabilities: [c8] 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: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> Address: 00000000fee0100c Data: 4192
>> Capabilities: [40] Express (v2) Endpoint, MSI 00
>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+ FLReset-
>> MaxPayload 128 bytes, MaxReadReq 128 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
>> L0s <4us, L1 <32us
>> 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 x1, TrErr- Train- SlotClk+ DLActive-
>> BWMgmt- ABWMgmt-
>> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via WAKE#
>> DevCtl2: Completion Timeout: 16ms to 55ms, 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: -3.5dB, 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 e8-b1-fc-ff-ff-16-c7-59
>> Capabilities: [14c v1] Latency Tolerance Reporting
>> Max snoop latency: 3145728ns
>> Max no snoop latency: 3145728ns
>> Capabilities: [154 v1] Vendor Specific Information: ID=cafe Rev=1 Len=014 <?>
>> Kernel driver in use: iwlwifi
>>
>> [7.6] $cat /proc/scsi/scsi
>>
>> Attached devices:
>> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>> Vendor: ATA Model: LITEONIT LGT-128 Rev: 201
>> Type: Direct-Access ANSI SCSI revision: 05
>>
>> [7.7] $ls /proc
>>
>> 1 1672 264 282 3039 3423 4096 669 cmdline modules
>> 10 1676 265 2825 3049 3442 41 67 consoles mounts
>> 1020 169 266 2827 3074 3456 4134 68 cpuinfo mtrr
>> 1065 17 267 2830 3089 3457 4135 69 crypto net
>> 1079 1708 2670 2836 3093 3462 42 695 devices pagetypeinfo
>> 11 1793 2672 2843 3099 3468 422 7 diskstats partitions
>> 137 1795 2731 2863 31 3484 4225 701 dma sched_debug
>> 14 18 2741 2864 3103 3499 43 704 driver schedstat
>> 1404 1847 2742 2866 3147 35 4343 715 execdomains scsi
>> 1409 19 2755 2867 3173 3544 4347 716 fb self
>> 1410 1926 2762 2871 3181 3591 438 742 filesystems slabinfo
>> 1416 1931 2763 2873 3182 3599 44 749 fs softirqs
>> 1417 2 2764 2874 3184 36 45 751 interrupts stat
>> 1422 2051 2767 2875 3185 3665 46 752 iomem swaps
>> 1430 21 2769 2889 3189 37 460 756 ioports sys
>> 1458 2170 2775 29 3190 3716 47 8 irq sysrq-trigger
>> 1462 2173 2779 2924 3192 38 479 88 kallsyms sysvipc
>> 15 22 278 2928 32 3830 48 886 kcore thread-self
>> 155 2323 2781 2954 3231 3834 492 89 keys timer_list
>> 158 2362 2789 2971 3242 3835 5 9 key-users timer_stats
>> 159 24 279 2974 3258 3885 50 939 kmsg tty
>> 160 25 28 2989 3285 3886 503 970 kpagecount uptime
>> 1601 2567 2806 2990 3296 39 53 999 kpageflags version
>> 161 2571 281 2992 33 390 54 acpi loadavg vmallocinfo
>> 1620 2572 2810 2993 3323 3902 55 asound locks vmstat
>> 163 2573 2813 3 3355 391 597 buddyinfo mdstat zoneinfo
>> 164 26 2817 302 34 4 643 bus meminfo
>> 1656 263 2819 303 3415 40 650 cgroups misc
>>
>> [X.] Launchpad report
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1389268
>> --
>> 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 1/1] Input: xpad - update docs to reflect current state
From: Jonathan Corbet @ 2014-11-07 18:48 UTC (permalink / raw)
To: Daniel Dressler
Cc: Dmitry Torokhov, Tommi Rantala, Ted Mielczarek, Paul Gortmaker,
Frank Razenberg, Benjamin Valentin, Petr Sebor,
Thomaz de Oliveira dos Reis, open list:DOCUMENTATION, open list,
linux-input
In-Reply-To: <1415004836-22871-1-git-send-email-danieru.dressler@gmail.com>
On Mon, 3 Nov 2014 17:53:06 +0900
Daniel Dressler <danieru.dressler@gmail.com> wrote:
> The last time this documentation was accurate was
> just over 8 years ago. In this time we've added
> support for two new generations of Xbox console
> controllers and dozens of third-party controllers.
>
> This patch unifies terminology and makes it explicit
> which model of controller a sentence refers to.
So this seems like a useful update, and I was looking at pulling it into
the docs tree. But this hunk:
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 2ed7905..7e2e047 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -40,8 +40,8 @@
> *
> * TODO:
> * - fine tune axes (especially trigger axes)
> - * - fix "analog" buttons (reported as digital now)
> - * - get rumble working
> + * - add original xbox rumble pack support
> + * - add xbox one rumble support
> * - need USB IDs for other dance pads
> *
> * History:
Seems like a different change that shouldn't be mixed up with the doc
update. Send me a version without that change and, in the absence
of complaints, I'll apply it.
Thanks,
jon
^ permalink raw reply
* [PATCH] Input: gpio_keys: Make sure wake-up buttons work.
From: NeilBrown @ 2014-11-07 23:37 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, GTA04 owners
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
If a key is to be used for wake-up, we must not disable
the interrupt during suspend.
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 8c98e97f8e41..0b5e54ae343e 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -526,6 +526,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
*/
if (!button->can_disable)
irqflags |= IRQF_SHARED;
+ if (button->wakeup)
+ irqflags |= IRQF_NO_SUSPEND;
error = devm_request_any_context_irq(&pdev->dev, bdata->irq,
isr, irqflags, desc, bdata);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
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