Re: xps 15 9560 touchpad high interrupts

Re: xps 15 9560 touchpad high interrupts

[Baruch Siach]

Hi Javad Karabi,

Added linux-i2c to Cc.

On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > Added linux-input list to Cc.
> >
> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
> > > im trying to figure out why i get like 7000 interrupts a second simply by
> > > resting my finger on the touchpad (not even moving it)
> > > this is on a xps 15 9560
> > > and the touchpad is at
> > > DLL07BE:01 06CB:7A13 Touchpad as
> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
> > >
> > > could you provide me with any advice as to where i should look to figure
> > > this out?
> > > i have already tried adding code to i2c-designware-platdrv.c
> > > i added
> > > dev->clk_freq = 100000;
> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
> > > second (and they are apparently spurious interrupts, atleast accoding
> > > to /proc/irq/17/spurious
> > >
> > > could you provide any guidance at all? would be much appreciated.. i
> > > would love to fix this issue and get it upstreamed in the kernel if 
> > > possible.
> > > thank you
> >
> > i2c_designware is a I2C bus master driver. It allows the host to
> > communicate with various devices. Your touchpad is apparently one such 
> > device. But each device on the I2C bus needs its own driver. I have no 
> > idea which driver handles your touchpad device. Maybe someone on the 
> > linux-input list knows.
> >
> > Specifically, the interrupts handling has nothing to do with the I2C bus.
> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
> > devices usually use a separate dedicated interrupt line. So the spurious 
> > interrupts that you see must be handled at the touchpad input driver 
> > level.
> >
> > One thing that might help others help you is the version of the kernel you
> > are running. Please provide the output of 'uname -rv' on your machine.
> 
> uname -rv
> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
> 
> for what its worth, i think it might be hid_multitouch that is handling the
> touchpad, since when i rmmod it, my touchpad is no longer active.

The hid-multitouch driver handles USB devices, not I2C. The code at 
drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS 
(0x06cb) devices, but the 0x7a13 device ID does not appear there as of 
v4.15-rc6. Maybe your kernel is patched to add support for that device.

I guess that i2c_designware appears on the device hierarchy because the 
"smart" USB hub on your system is controlled over the I2C bus.

> when you say that the touchpad driver handles the irq stuff... i am a
> little confused because i2c-designware-platdrv.c contains this line:
> irq = platform_get_irq(pdev, 0);

Do you have an indication that irq 17 belongs to i2c-designware?

The i2c-designware driver uses an interrupt to handle its hardware buffer, and 
to receive transactions status. I2C is a slow protocol, so most controller 
implementations are asynchronous. If this irq misbehaves, then there is most 
likely a problem with the i2c-designware driver.

> i would assume that hid_multitouch would contain irq related code if i am
> understanding you correctly?
> am i misunderstanding?

Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus 
driver.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: xps 15 9560 touchpad high interrupts

[Javad Karabi]

On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Javad Karabi,
>
> Added linux-i2c to Cc.
>
> On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
>> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > Added linux-input list to Cc.
>> >
>> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
>> > > im trying to figure out why i get like 7000 interrupts a second simply by
>> > > resting my finger on the touchpad (not even moving it)
>> > > this is on a xps 15 9560
>> > > and the touchpad is at
>> > > DLL07BE:01 06CB:7A13 Touchpad as
>> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
>> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
>> > >
>> > > could you provide me with any advice as to where i should look to figure
>> > > this out?
>> > > i have already tried adding code to i2c-designware-platdrv.c
>> > > i added
>> > > dev->clk_freq = 100000;
>> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
>> > > second (and they are apparently spurious interrupts, atleast accoding
>> > > to /proc/irq/17/spurious
>> > >
>> > > could you provide any guidance at all? would be much appreciated.. i
>> > > would love to fix this issue and get it upstreamed in the kernel if
>> > > possible.
>> > > thank you
>> >
>> > i2c_designware is a I2C bus master driver. It allows the host to
>> > communicate with various devices. Your touchpad is apparently one such
>> > device. But each device on the I2C bus needs its own driver. I have no
>> > idea which driver handles your touchpad device. Maybe someone on the
>> > linux-input list knows.
>> >
>> > Specifically, the interrupts handling has nothing to do with the I2C bus.
>> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
>> > devices usually use a separate dedicated interrupt line. So the spurious
>> > interrupts that you see must be handled at the touchpad input driver
>> > level.
>> >
>> > One thing that might help others help you is the version of the kernel you
>> > are running. Please provide the output of 'uname -rv' on your machine.
>>
>> uname -rv
>> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
>>
>> for what its worth, i think it might be hid_multitouch that is handling the
>> touchpad, since when i rmmod it, my touchpad is no longer active.
>
> The hid-multitouch driver handles USB devices, not I2C. The code at
> drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
> (0x06cb) devices, but the 0x7a13 device ID does not appear there as of
> v4.15-rc6. Maybe your kernel is patched to add support for that device.
>
> I guess that i2c_designware appears on the device hierarchy because the
> "smart" USB hub on your system is controlled over the I2C bus.
>
>> when you say that the touchpad driver handles the irq stuff... i am a
>> little confused because i2c-designware-platdrv.c contains this line:
>> irq = platform_get_irq(pdev, 0);
>
> Do you have an indication that irq 17 belongs to i2c-designware?
>
> The i2c-designware driver uses an interrupt to handle its hardware buffer, and
> to receive transactions status. I2C is a slow protocol, so most controller
> implementations are asynchronous. If this irq misbehaves, then there is most
> likely a problem with the i2c-designware driver.
>
>> i would assume that hid_multitouch would contain irq related code if i am
>> understanding you correctly?
>> am i misunderstanding?
>
> Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
> driver.
>
> baruch
>
> --
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


uname -rv:
4.15.0-rc5-00248-gf39d7d78b70e #2 SMP Sun Dec 31 18:17:25 CST 2017

the git commit i am at is f39d7d78b70e0f39facb1e4fab77ad3df5c52a35

> Do you have an indication that irq 17 belongs to i2c-designware?
from /proc/interrupts:
  17:   47105193          0          0          0          0
0          0          0  IR-IO-APIC   17-fasteoi   idma64.1,
i2c_designware.1

if i rmmod idma64, the behavior remains the same, so im assuming this
is all i2c_designware thats causing this problem.

> then there is most likely a problem with the i2c-designware driver.
do you have any idea what the problem might be? i know i should look
in the code for i2c-designware, but why would a touchpad be shooting
off interrupts like that with my finger simply resting on it?

i have a theory, could you tell me if this makes sense?
perhaps the touchpad hardware is configured with a very high
sensitivity. so in theory if the sensitivity was decreased, then
resting my finger would not trigger interrupts until i move it a
larger amount?

Re: xps 15 9560 touchpad high interrupts

[Baruch Siach]

Hi Javad Karabi,

On Mon, Jan 01, 2018 at 05:18:00PM -0600, Javad Karabi wrote:
> On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
> >> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> >> > Added linux-input list to Cc.
> >> >
> >> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
> >> > > im trying to figure out why i get like 7000 interrupts a second simply by
> >> > > resting my finger on the touchpad (not even moving it)
> >> > > this is on a xps 15 9560
> >> > > and the touchpad is at
> >> > > DLL07BE:01 06CB:7A13 Touchpad as
> >> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
> >> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
> >> > >
> >> > > could you provide me with any advice as to where i should look to figure
> >> > > this out?
> >> > > i have already tried adding code to i2c-designware-platdrv.c
> >> > > i added
> >> > > dev->clk_freq = 100000;
> >> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
> >> > > second (and they are apparently spurious interrupts, atleast accoding
> >> > > to /proc/irq/17/spurious
> >> > >
> >> > > could you provide any guidance at all? would be much appreciated.. i
> >> > > would love to fix this issue and get it upstreamed in the kernel if
> >> > > possible.
> >> > > thank you
> >> >
> >> > i2c_designware is a I2C bus master driver. It allows the host to
> >> > communicate with various devices. Your touchpad is apparently one such
> >> > device. But each device on the I2C bus needs its own driver. I have no
> >> > idea which driver handles your touchpad device. Maybe someone on the
> >> > linux-input list knows.
> >> >
> >> > Specifically, the interrupts handling has nothing to do with the I2C bus.
> >> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
> >> > devices usually use a separate dedicated interrupt line. So the spurious
> >> > interrupts that you see must be handled at the touchpad input driver
> >> > level.
> >> >
> >> > One thing that might help others help you is the version of the kernel you
> >> > are running. Please provide the output of 'uname -rv' on your machine.
> >>
> >> uname -rv
> >> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
> >>
> >> for what its worth, i think it might be hid_multitouch that is handling the
> >> touchpad, since when i rmmod it, my touchpad is no longer active.
> >
> > The hid-multitouch driver handles USB devices, not I2C. The code at
> > drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
> > (0x06cb) devices, but the 0x7a13 device ID does not appear there as of
> > v4.15-rc6. Maybe your kernel is patched to add support for that device.
> >
> > I guess that i2c_designware appears on the device hierarchy because the
> > "smart" USB hub on your system is controlled over the I2C bus.
> >
> >> when you say that the touchpad driver handles the irq stuff... i am a
> >> little confused because i2c-designware-platdrv.c contains this line:
> >> irq = platform_get_irq(pdev, 0);
> >
> > Do you have an indication that irq 17 belongs to i2c-designware?
> >
> > The i2c-designware driver uses an interrupt to handle its hardware buffer, and
> > to receive transactions status. I2C is a slow protocol, so most controller
> > implementations are asynchronous. If this irq misbehaves, then there is most
> > likely a problem with the i2c-designware driver.
> >
> >> i would assume that hid_multitouch would contain irq related code if i am
> >> understanding you correctly?
> >> am i misunderstanding?
> >
> > Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
> > driver.
> 
> uname -rv:
> 4.15.0-rc5-00248-gf39d7d78b70e #2 SMP Sun Dec 31 18:17:25 CST 2017
> 
> the git commit i am at is f39d7d78b70e0f39facb1e4fab77ad3df5c52a35
> 
> > Do you have an indication that irq 17 belongs to i2c-designware?
> from /proc/interrupts:
>   17:   47105193          0          0          0          0
> 0          0          0  IR-IO-APIC   17-fasteoi   idma64.1,
> i2c_designware.1
> 
> if i rmmod idma64, the behavior remains the same, so im assuming this
> is all i2c_designware thats causing this problem.
> 
> > then there is most likely a problem with the i2c-designware driver.
> do you have any idea what the problem might be? i know i should look
> in the code for i2c-designware, but why would a touchpad be shooting
> off interrupts like that with my finger simply resting on it?

It is not the touchpad that shoots the interrupts. It is the i2c-designware 
hardware module.

> i have a theory, could you tell me if this makes sense?
> perhaps the touchpad hardware is configured with a very high
> sensitivity. so in theory if the sensitivity was decreased, then
> resting my finger would not trigger interrupts until i move it a
> larger amount?

I don't think that the touchpad sensitivity has anything to do with this 
interrupts storm.

There is another possibility. The USB hub controller driver might be shooting 
i2c transactions at the USB hub. In this case the bug is not in the i2c master 
driver.

Can you identify the driver that initiates the i2c transactions?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: xps 15 9560 touchpad high interrupts

[Javad Karabi]

On Tue, Jan 2, 2018 at 7:46 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Javad Karabi,
>
> On Mon, Jan 01, 2018 at 05:18:00PM -0600, Javad Karabi wrote:
>> On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
>> >> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> >> > Added linux-input list to Cc.
>> >> >
>> >> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
>> >> > > im trying to figure out why i get like 7000 interrupts a second simply by
>> >> > > resting my finger on the touchpad (not even moving it)
>> >> > > this is on a xps 15 9560
>> >> > > and the touchpad is at
>> >> > > DLL07BE:01 06CB:7A13 Touchpad as
>> >> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
>> >> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
>> >> > >
>> >> > > could you provide me with any advice as to where i should look to figure
>> >> > > this out?
>> >> > > i have already tried adding code to i2c-designware-platdrv.c
>> >> > > i added
>> >> > > dev->clk_freq = 100000;
>> >> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
>> >> > > second (and they are apparently spurious interrupts, atleast accoding
>> >> > > to /proc/irq/17/spurious
>> >> > >
>> >> > > could you provide any guidance at all? would be much appreciated.. i
>> >> > > would love to fix this issue and get it upstreamed in the kernel if
>> >> > > possible.
>> >> > > thank you
>> >> >
>> >> > i2c_designware is a I2C bus master driver. It allows the host to
>> >> > communicate with various devices. Your touchpad is apparently one such
>> >> > device. But each device on the I2C bus needs its own driver. I have no
>> >> > idea which driver handles your touchpad device. Maybe someone on the
>> >> > linux-input list knows.
>> >> >
>> >> > Specifically, the interrupts handling has nothing to do with the I2C bus.
>> >> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
>> >> > devices usually use a separate dedicated interrupt line. So the spurious
>> >> > interrupts that you see must be handled at the touchpad input driver
>> >> > level.
>> >> >
>> >> > One thing that might help others help you is the version of the kernel you
>> >> > are running. Please provide the output of 'uname -rv' on your machine.
>> >>
>> >> uname -rv
>> >> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
>> >>
>> >> for what its worth, i think it might be hid_multitouch that is handling the
>> >> touchpad, since when i rmmod it, my touchpad is no longer active.
>> >
>> > The hid-multitouch driver handles USB devices, not I2C. The code at
>> > drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
>> > (0x06cb) devices, but the 0x7a13 device ID does not appear there as of
>> > v4.15-rc6. Maybe your kernel is patched to add support for that device.
>> >
>> > I guess that i2c_designware appears on the device hierarchy because the
>> > "smart" USB hub on your system is controlled over the I2C bus.
>> >
>> >> when you say that the touchpad driver handles the irq stuff... i am a
>> >> little confused because i2c-designware-platdrv.c contains this line:
>> >> irq = platform_get_irq(pdev, 0);
>> >
>> > Do you have an indication that irq 17 belongs to i2c-designware?
>> >
>> > The i2c-designware driver uses an interrupt to handle its hardware buffer, and
>> > to receive transactions status. I2C is a slow protocol, so most controller
>> > implementations are asynchronous. If this irq misbehaves, then there is most
>> > likely a problem with the i2c-designware driver.
>> >
>> >> i would assume that hid_multitouch would contain irq related code if i am
>> >> understanding you correctly?
>> >> am i misunderstanding?
>> >
>> > Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
>> > driver.
>>
>> uname -rv:
>> 4.15.0-rc5-00248-gf39d7d78b70e #2 SMP Sun Dec 31 18:17:25 CST 2017
>>
>> the git commit i am at is f39d7d78b70e0f39facb1e4fab77ad3df5c52a35
>>
>> > Do you have an indication that irq 17 belongs to i2c-designware?
>> from /proc/interrupts:
>>   17:   47105193          0          0          0          0
>> 0          0          0  IR-IO-APIC   17-fasteoi   idma64.1,
>> i2c_designware.1
>>
>> if i rmmod idma64, the behavior remains the same, so im assuming this
>> is all i2c_designware thats causing this problem.
>>
>> > then there is most likely a problem with the i2c-designware driver.
>> do you have any idea what the problem might be? i know i should look
>> in the code for i2c-designware, but why would a touchpad be shooting
>> off interrupts like that with my finger simply resting on it?
>
> It is not the touchpad that shoots the interrupts. It is the i2c-designware
> hardware module.
>
>> i have a theory, could you tell me if this makes sense?
>> perhaps the touchpad hardware is configured with a very high
>> sensitivity. so in theory if the sensitivity was decreased, then
>> resting my finger would not trigger interrupts until i move it a
>> larger amount?
>
> I don't think that the touchpad sensitivity has anything to do with this
> interrupts storm.
>
> There is another possibility. The USB hub controller driver might be shooting
> i2c transactions at the USB hub. In this case the bug is not in the i2c master
> driver.
>
> Can you identify the driver that initiates the i2c transactions?
>
> baruch
>
> --
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

> The USB hub controller driver might be shooting
> i2c transactions at the USB hub. In this case the bug is not in the i2c master
> driver.
im still rather confused about the relationship between the i2c bus
and the usb bus.
from what i understand, you have the i2c bus, which has a touchpad,
and the touchpad sends i2c transactions
when an event has occured, e.g. i moved my finger on the touchpad...
is that correct?

> Can you identify the driver that initiates the i2c transactions?
i would be more than happy to identify that driver if you could point
me in the right direction to figure that out

Re: xps 15 9560 touchpad high interrupts

[Baruch Siach]

Hi Javad Karabi,

On Tue, Jan 02, 2018 at 06:24:54PM -0600, Javad Karabi wrote:
> On Tue, Jan 2, 2018 at 7:46 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Jan 01, 2018 at 05:18:00PM -0600, Javad Karabi wrote:
> >> On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> >> > On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
> >> >> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> >> >> > Added linux-input list to Cc.
> >> >> >
> >> >> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
> >> >> > > im trying to figure out why i get like 7000 interrupts a second simply by
> >> >> > > resting my finger on the touchpad (not even moving it)
> >> >> > > this is on a xps 15 9560
> >> >> > > and the touchpad is at
> >> >> > > DLL07BE:01 06CB:7A13 Touchpad as
> >> >> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
> >> >> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
> >> >> > >
> >> >> > > could you provide me with any advice as to where i should look to figure
> >> >> > > this out?
> >> >> > > i have already tried adding code to i2c-designware-platdrv.c
> >> >> > > i added
> >> >> > > dev->clk_freq = 100000;
> >> >> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
> >> >> > > second (and they are apparently spurious interrupts, atleast accoding
> >> >> > > to /proc/irq/17/spurious
> >> >> > >
> >> >> > > could you provide any guidance at all? would be much appreciated.. i
> >> >> > > would love to fix this issue and get it upstreamed in the kernel if
> >> >> > > possible.
> >> >> > > thank you
> >> >> >
> >> >> > i2c_designware is a I2C bus master driver. It allows the host to
> >> >> > communicate with various devices. Your touchpad is apparently one such
> >> >> > device. But each device on the I2C bus needs its own driver. I have no
> >> >> > idea which driver handles your touchpad device. Maybe someone on the
> >> >> > linux-input list knows.
> >> >> >
> >> >> > Specifically, the interrupts handling has nothing to do with the I2C bus.
> >> >> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
> >> >> > devices usually use a separate dedicated interrupt line. So the spurious
> >> >> > interrupts that you see must be handled at the touchpad input driver
> >> >> > level.
> >> >> >
> >> >> > One thing that might help others help you is the version of the kernel you
> >> >> > are running. Please provide the output of 'uname -rv' on your machine.
> >> >>
> >> >> uname -rv
> >> >> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
> >> >>
> >> >> for what its worth, i think it might be hid_multitouch that is handling the
> >> >> touchpad, since when i rmmod it, my touchpad is no longer active.
> >> >
> >> > The hid-multitouch driver handles USB devices, not I2C. The code at
> >> > drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
> >> > (0x06cb) devices, but the 0x7a13 device ID does not appear there as of
> >> > v4.15-rc6. Maybe your kernel is patched to add support for that device.
> >> >
> >> > I guess that i2c_designware appears on the device hierarchy because the
> >> > "smart" USB hub on your system is controlled over the I2C bus.
> >> >
> >> >> when you say that the touchpad driver handles the irq stuff... i am a
> >> >> little confused because i2c-designware-platdrv.c contains this line:
> >> >> irq = platform_get_irq(pdev, 0);
> >> >
> >> > Do you have an indication that irq 17 belongs to i2c-designware?
> >> >
> >> > The i2c-designware driver uses an interrupt to handle its hardware buffer, and
> >> > to receive transactions status. I2C is a slow protocol, so most controller
> >> > implementations are asynchronous. If this irq misbehaves, then there is most
> >> > likely a problem with the i2c-designware driver.
> >> >
> >> >> i would assume that hid_multitouch would contain irq related code if i am
> >> >> understanding you correctly?
> >> >> am i misunderstanding?
> >> >
> >> > Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
> >> > driver.
> >>
> >> uname -rv:
> >> 4.15.0-rc5-00248-gf39d7d78b70e #2 SMP Sun Dec 31 18:17:25 CST 2017
> >>
> >> the git commit i am at is f39d7d78b70e0f39facb1e4fab77ad3df5c52a35
> >>
> >> > Do you have an indication that irq 17 belongs to i2c-designware?
> >> from /proc/interrupts:
> >>   17:   47105193          0          0          0          0
> >> 0          0          0  IR-IO-APIC   17-fasteoi   idma64.1,
> >> i2c_designware.1
> >>
> >> if i rmmod idma64, the behavior remains the same, so im assuming this
> >> is all i2c_designware thats causing this problem.
> >>
> >> > then there is most likely a problem with the i2c-designware driver.
> >> do you have any idea what the problem might be? i know i should look
> >> in the code for i2c-designware, but why would a touchpad be shooting
> >> off interrupts like that with my finger simply resting on it?
> >
> > It is not the touchpad that shoots the interrupts. It is the i2c-designware
> > hardware module.
> >
> >> i have a theory, could you tell me if this makes sense?
> >> perhaps the touchpad hardware is configured with a very high
> >> sensitivity. so in theory if the sensitivity was decreased, then
> >> resting my finger would not trigger interrupts until i move it a
> >> larger amount?
> >
> > I don't think that the touchpad sensitivity has anything to do with this
> > interrupts storm.
> >
> > There is another possibility. The USB hub controller driver might be shooting
> > i2c transactions at the USB hub. In this case the bug is not in the i2c master
> > driver.
> >
> > Can you identify the driver that initiates the i2c transactions?

> > The USB hub controller driver might be shooting
> > i2c transactions at the USB hub. In this case the bug is not in the i2c master
> > driver.
> im still rather confused about the relationship between the i2c bus
> and the usb bus.
> from what i understand, you have the i2c bus, which has a touchpad,
> and the touchpad sends i2c transactions
> when an event has occured, e.g. i moved my finger on the touchpad...
> is that correct?

No. On the I2C bus only the master initiates transactions. Slaves can only 
respond to master queries. But there might be a bug in the USB hub driver that 
results in a flood of I2C transactions.

> > Can you identify the driver that initiates the i2c transactions?
> i would be more than happy to identify that driver if you could point
> me in the right direction to figure that out

You can add a rate limited dump_stack() call in i2c_dw_xfer(). This would tell 
you where transactions are coming from, and whether their rate is too high.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -