[Gta04-owner] Linux 3.2-rc4 - touchscreen issues (was: Re: Linux 3.2-rc4 - now with wifi)

Klaus 'mrmoku' Kurzmann mok at mnet-online.de
Tue Dec 6 08:43:55 CET 2011


On Tue, 06 Dec 2011, Christoph Mair wrote:

> On Mon, Dec 5, 2011 at 10:35 PM, Klaus 'mrmoku' Kurzmann
> <mok at mnet-online.de> wrote:
> > On Tue, 06 Dec 2011, NeilBrown wrote:
> >
> >> On Mon, 5 Dec 2011 17:20:45 +0100 Klaus 'mrmoku' Kurzmann
> >> <mok at mnet-online.de> wrote:

> >> > I have one problem with rc4. Touchsreen stopped working:
> >> >
> >> > root at om-gta04:~# cat /dev/input/event0
> >> > [  739.782196] omap_i2c omap_i2c.2: controller timed out
> >> > [  739.813537] tsc2007 2-0048: i2c io error: -110
> >
> >> 110 is ETIMEDOUT
> >
> >> >
> >> >
> >> > any hint?
> >
> >> Not really.  I don't have a real touch screen attached yet so I might have
> >> trouble testing.  I'll have a look though.
> >
> >> My guess is that it is related to runtime-power-management, but that is just
> >> because the last two weird bugs were.
> >
> > I enabled debug for the i2c and this is what I get when touching the
> > screen:
> >
> > [  119.375213] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.380828] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.386566] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.393798] omap_i2c omap_i2c.2: IRQ (ISR = 0x1010)
> > [  119.398895] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.404022] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.411315] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.416381] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.421478] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.426605] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.432281] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.437927] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.445098] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.450195] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.455322] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.462615] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.467712] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.472778] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.477935] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.483551] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.489227] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.496429] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.501525] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.506622] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.513916] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.519012] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.524078] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> > [  119.529235] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.534881] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> > [  119.540527] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> > [  119.547729] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> > [  119.552856] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> > [  119.557983] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> > [  119.565277] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> > [  119.570343] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> > [  119.575439] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)

> The kernel can write to and read from the device as expected. I can't
> see any error in there. Did the timeouts you mentioned earlier go
> away?
> A transaction on the I2C bus can timeout if the device does not
> respond. The log from above seemś to be fine. I'll try to explain the
> last few lines.

> Warning: this is a complete guesswork, I did noch actually trace the
> debug messages in the kernel code...

> > [  119.580566] i2c i2c-2: master_xfer[0] W, addr=0x48, len=1
> > [  119.586212] i2c i2c-2: master_xfer[1] R, addr=0x48, len=2
> The I2C subsystem was asked to write one byte to the device at address
> 0x48 and then read two bytes from it within one transaction.

> > [  119.591857] omap_i2c omap_i2c.2: addr: 0x0048, len: 1, flags: 0x0, stop: 0
> The subsystem will first issue a I2C start condition and then transfer
> the address and one data byte.

> > [  119.599029] omap_i2c omap_i2c.2: IRQ (ISR = 0x0010)
> The IRQ handler gets called because the address byte was sent. Now the
> data byte follows.

> > [  119.604156] omap_i2c omap_i2c.2: IRQ (ISR = 0x1004)
> The data byte was sent (which implies that the device ack'ed the
> address send before).

> > [  119.609252] omap_i2c omap_i2c.2: addr: 0x0048, len: 2, flags: 0x1, stop: 1
> To switch from writing to reading, the I2C bus controller will issue a
> repeated start condition and send the address again.

> > [  119.616577] omap_i2c omap_i2c.2: IRQ (ISR = 0x1008)
> Address was ack'ed. Now start reading the first databyte.

> > [  119.621673] omap_i2c omap_i2c.2: IRQ (ISR = 0x0108)
> First data byte is here, read the second one.

> > [  119.626739] omap_i2c omap_i2c.2: IRQ (ISR = 0x0004)
> The second byte was read and the device(?) nack'ed this byte
> indicating that it does not have more data to read. This is fine
> because we didn't want to read more anyway.


> > no idea if that is of any help...
> > /me already regrets to not have attended Christoph's talk about i2c in
> > the kernel :/

> I'm not sure if that would have helped here..

See my other mail. It works now and somehow was my fault.
Thanks for looking :-)

> Best regards,
>   Christoph

-- 
Klaus 'mrmoku' Kurzmann


More information about the Gta04-owner mailing list