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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx - tel: +972.52.368.4656, http://www.tkos.co.il -
