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

Christoph Mair christoph.mair at gmail.com
Tue Dec 6 08:27:36 CET 2011


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..

Best regards,
  Christoph


More information about the Gta04-owner mailing list