[DEV] Beware of the touchscreen

Search This thread

sp3dev

Senior Member
Jul 11, 2006
554
675
Kaluga/Moscow
Ok, in this thread I will describe one problem that I have faced with my Iconia and that was also reported by one other user on a forum.

Basically, Iconia uses Atmel mxt1386 touchscreen controller. The same controller is used in Asus EEE Transformer and Motorola Xoom and even Samsung Galaxy Tab 10.1. So far, there are a lot of reports of EEE Transformer's and Xoom's touchscreens suddenly stopping working and starting working after a full battery discharge.

One day after a reboot my Iconia stopped booting - it keeped hanging on the Acer logo and when I tried entering recovery it was hanging at "booting recovery kernel image". However, that only happened with Acer kernels. With my own kernel, ported from EEE Transformer, the tablet could boot. I have recompiled the acer kernel with framebuffer console and found out it got stuck at the touchscreen interrupt handler while EEE's driver just printed an error and stopped working.. Basically, the response I got from from the touchscreen was [1, 0x80, 0, 0, 0, 0, 0, 0]. And it was not detected with i2cdetect

At first, I thought my touchscreen cable was damaged. I have disassembled the tablet and tried twisting the cable to see if it gives any result. My result was that if I disconnect and reconnect the cable, an interrupt comes. Btw, the cable has sharp 'teeth' and you can crimp it pretty much like ethernet.

Ok, so then I added some printks to the driver. Turns out, when some data coming from the touchscreen was incorrect, the driver hanged (deadlocked) because the semaphore was pushed down two times and never upped. So, I have commented out semaphores and bingo - it continued booting. Although there were a lot of warn_slowpath errors and CRC error, it reported correct coordinates. I flashed Acer's kernel after it and it booted fine. Looks like a proper init by Acer driver reset the controller.

The archive in the link contains tegra i2c driver from the chromium tree (in case it finds i2c errors like nak, it retries the transmission several times) and the touchscreen driver. You need to comment out "#define USE_SEMA" to disable semaphores and build the kernel with it in case you encounter the problem..
http://www.mediafire.com/?jt6b19nr7rsy70s

I do not have another 'brick' to test if my solution works in all cases but I'm just leaving the stuff here in case anyone faces the trouble. To flash when your tablet is not booting you'll probably some help from sc2k..

What's the moral of the story? The moral is that as touchscreen is not used in recovery, it may be a good idea to add the 'hacked and buggy' driver to the recovery kernel to allow to recover the device by just booting recovery in case anyone faces the problem.. Of course it's better to fix the driver properly or even use the driver from mainline linux and patch it.

EDIT 29-oct-2011:
here is a link to the cwm recovery image with the 'hacked' driver. Boots just fine.
http://www.mediafire.com/?39jk1j15wkpr57o
 
Last edited:

sp3dev

Senior Member
Jul 11, 2006
554
675
Kaluga/Moscow
This is a combined problem. It is a hardware problem as the touchscreen stops getting recognized by i2cdetect, probably due to firmware bugs.. It is a software problem because the driver behaves incorrectly when the hardware fails.
 

sp3dev

Senior Member
Jul 11, 2006
554
675
Kaluga/Moscow
Ok, I will post the reply from sc2k who investigated the issue a bit. Let's keep it here for reference. I think it will be nice to patch the mainline driver (from chromium or mainline linux) and use it instead of acer's driver but I won't probably do it unless I hit the issue again or make some progress with my chromium kernel

sc2k said:
Ok.. I finally understand the issue:

Your tochscreen always responded with [1, 0x80, 0, 0, 0, 0, 0, 0]
buffer[1].bit7 seems to be some kind of "message incomplete" bit. As this is always transmitted, the worker thread never releases the semaphore which causes the ATMEL_Initial to stop at ATMEL_SyncWithThreadToReadMsg.

After you disabled the semaphore, ATMEL_Initial continues. ConfigError is probably 0, so next function to be called will be ATMEL_CheckConfig.

This function first calls ATMEL_SendCMDgetCRC. As semaphores are disabled, this will probably not be able to receive the checksum (due to timing) so that ConfigChecksumError=1.

If ConfigChecksumError==1, ATMEL_CheckConfig will call ATMEL_WriteConfig and ATMEL_Backup that will probably be successful and thus fixes the configuration issue. Even if it does not complete succesfully, the whole recovery process is repeated until all conditions are satisfied.

Conclusion:
- Somehow the configuration in your touchscreen controller got messed up.
- Removing the semaphores triggered ATMEL_WriteConfig + ATMEL_Backup which probably fixed the issue.

I believe, a good fix would be to add a check "if (counts > 20) { up(&mxt->sema); goto fail; }" or similar to mxt_worker for irq_type == ATMEL_ReadResponseMsg_Noaddress. This would prevent these endless interrupt loop and allow the driver to fix the configuration.

Really nice bug that you have found in this driver
 
  • Like
Reactions: sc2k

andrearesti

Member
May 18, 2005
9
4
Link to cwm recovery image invalid

Hi sp3dev,
sorry to ask but could you pls reupload your cwm recovery image? Mediafire says the file is not available any more.
I am not an expert in ROMs and I know nothing about cooking them or kernels. But I think I am having a problem similar to that described in your thread: after a sw update the touchscreen became unsensitive. Shutdown, reset, factory reset do not solve the problem. When I flash a new ROM to try and "reset" the screen controller, I get stuck at the "ACER" logo after flashing with CWM and rebooting the system. If I shut down and restart again, the machine starts but the touchscreen is still unresponsive. Luckily enough, I can use a USB mouse to interact with the device.
I am currently running HC 3.1 (stock), rooted. I took a full nandroid backup with CWM. Do you think it is safe to flash your recovery with the modified touchscreen driver (that is, if you are kind enough to re-upload it for me...)?
Thanks a lot for any advice you can provide.
Best, Andrea
 

qwertylesh

Senior Member
May 4, 2010
423
39
Melbourne
I see that thor2002ro has seen this thread, but will we see the driver implemented in the next CWM release?
If it can help people recover from a known brick and if the stack does not introduce problems then I hope that we see something, at least a recovery instruction for the touchscreen added to CWM or the whole stack. aferall this could be something that ends up happening to alot of us :S
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.

I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device

So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.

I tried adding a reset. No change. Disconnected the battery overnight. Also no change.

Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.

I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.

http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..

Whew. It's good to have the toy back working.
 

OTAw

Senior Member
May 27, 2012
264
64
Chicago
I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.

I always had this failure showing up in dmesg:
[ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
[ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
[ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
[ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
[ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device

So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.

I tried adding a reset. No change. Disconnected the battery overnight. Also no change.

Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.

I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.

http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..

Whew. It's good to have the toy back working.

Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.

Sent from my GT-P7510 using xda app-developers app
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
Though I don't have this problem, and hope never to, it is a scary scenario. Thanks for investing your time to come up with a fix for ppl who have this problem.

Thanks. I've also sent a patch to the person who I thing maintains the driver. If they'll accept the fix, it'll automatically correct this problem regardless of the type of device being used. That'd be a good thing.
 

DIZAZTER

Member
Sep 18, 2007
5
1
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.

When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.

So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.
 

Moscow Desire

Retired Senior Moderator
I have the common problem with my Acer Iconia A500.
The tablet's touchscreen suddenly stopping working. And didn't start working after reset, shutdown, deattaching the battery, or any firmware upgrades/downgrades.
Custom bootloaders and restores also didn't help.
It is starting working only when I shutdown the tablet and don't use it for a while.
When I turn on the tablet after 2-3 hours, the touchscreen works. But after 10-15 minutes of usage(or even idle), touchscreen stop working again.
I tried many ways to solve this problem, but nothing works for me.

When I tryed to figure out this issue, I found only a few topics in the internet, but all of them was leading to this thread.

So, tell me please, is there any workaround to this touchscreen problem?
I suggest, this is the hardware problem. But if there is any software fix, it would be good.

Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.

If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.

I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)

You can google for 500 breakdown videos. Plenty of them out there.

As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.

I'd bet on the connectors. Then check the board with a magnifying glass.

MD
 

DIZAZTER

Member
Sep 18, 2007
5
1
Well, if you have done a rollback using TD's V4 rollback tool, and the problem still persists, then it's likely a hardware issue.

If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.

I would suggest, if you are no longer under warranty, to pop off the cover, and start checking connections. More than likely a connection is failing. (cold expands, heat contracts). Might explain why it works when it's cool. (this is why we put old HDD's in the freezer, sounds strange, but can't deny physics)

You can google for 500 breakdown videos. Plenty of them out there.

As a test in the temp theory, just play with the tab till it fails. Toss it in the fridge for 15 minutes or so. If it works, then it's mechanical.

I'd bet on the connectors. Then check the board with a magnifying glass.

MD
You're right about the temp.
Actually, I put the tablet in the fridge even before I saw you reply.
After that procedure, touchscreen works fine for a while. And after freezing it works much longer period. I guess, it works just before getting warm.
I wanted to mention about the temperature dependence, but you did it first.

My warranty is expired. So I'm already has disassembled and taken the tablet apart. But I saw nothing noticeably wrong there.
I guess, there is some kind of connection failure, but it's microscopically small. Or it's situated inside of a board or a chip.
Anyway, thanks a lot.
At least I figured out that this is only hardware issue and there is no way to fix it with software patch.
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
If it were software, the TS would either work, or it wouldn't. The fact there's a time limit involved, indicates some component heating up and causing the issue.
..
I'd bet on the connectors. Then check the board with a magnifying glass.

I agree. Your problem has nothing in common with the issue that was causing my touchscreen to not work. That was a software problem with a reliable software fix.

I have seen a Galaxy Tab with a flaky touchscreen, but when I took it apart to look at what was wrong I found that the connector for the touchscreen had been ripped completely off the motherboard. The induhvidual responsible tried to fix it by taping the touchscreen connector to the motherboard! Needless to say, that wasn't a very reliable fix. :laugh:
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I've pulled the kernel that had my patch off of my web site because it's only usable on the P7510 (WiFi) device and caused a 3G tablet to hang.
 

switchgott

Senior Member
Jan 22, 2007
1,238
120
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:

mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!

Any idea?
Why?

On boot, dmesg write this:

mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready

How can we fix it?
Please devs!Help us!!!
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
Could someone please explain what went wrong?
I use a acer a700 and get everytime i make display on such errors:

mXT1386E: mxt_late_resume
<4>[ 1641.027524] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.027938] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.028178] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.045244] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
<4>[ 1641.045398] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
<4>[ 1641.045670] tegra-i2c tegra-i2c.1: Packet status 0x00010009
<4>[ 1641.069140] mXT1386E i2c write 3 time
<4>[ 1641.069539] mXT1386E: ATMEL_Resume OK!

Any idea?
Why?

On boot, dmesg write this:

mXT1386E: reenter_count: 0
mXT1386E: Config has errors
mXT1386E: The status is 0x90
mXT1386E: reenter_count: 1
mXT1386E: Config status is ready

How can we fix it?
Please devs!Help us!!!

That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
 

Elibl

Senior Member
Dec 20, 2011
686
448
That "no acknowledge from address 0x4c" means that your touchscreen chip is not responding. It's possible that it's just dead, or possible that it's stuck in firmware update mode (in update mode, the address changes to 0x26). If you can point me to kernel source for your A700, I can modify it try to recover the touchscreen. (Of course, I'm assuming that it's just dead and that the touchscreen never works. If it works some of the time but fails later, it's probably just a hardware problem.)
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...

Thanks in advance
 
Last edited:

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
Hi @k1mu got a question regarding this discussion. Would there also be benefits from this fix if it's only a unresponsiveness in runtime? I assume also djsven has it within runtime and the ts recovers itself... what I get from this thread is that it's regarded to the tab being unrecoverably stuck on firmware update mode? If not and it could fix hangs for some seconds in runtime it would be awesome if you could make a patch for this driver or just point me to a diff...

Thanks in advance

If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
 

Elibl

Senior Member
Dec 20, 2011
686
448
If it's just slow to respond, then the touchscreen is basically working and isn't going to be helped by this fix.
That (slow, jerky response to screen input) is caused by CPU hogging processes keeping the tablet too busy, or too many applications running at once, keeping the OS busy shuffling memory around (that's called thrashing).
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated :)
 

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated :)

No, the system doesn't hang, it works just fine if you plug in a keyboard.

Here's the diff:
Code:
diff -c drivers/input/touchscreen/orig/atmel_mxt1386.c drivers/input/touchscreen/atmel_mxt1386.c
*** drivers/input/touchscreen/orig/atmel_mxt1386.c      2012-10-10 08:11:10.543325982 -0400
--- drivers/input/touchscreen/atmel_mxt1386.c   2012-10-10 08:35:30.545044039 -0400
***************
*** 22,27 ****
--- 22,29 ----
   *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
   */

+ #define FIX_CHIP_HANG
+
  #define       DEBUG_INFO      1
  #define       DEBUG_VERBOSE   2
  #define       DEBUG_MESSAGES  5
***************
*** 2539,2544 ****
--- 2541,2550 ----
  /* Initialization of driver                                                   */
  /******************************************************************************/

+ #ifdef FIX_CHIP_HANG
+ extern int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn);
+ #endif
+
  static int __devinit mxt_identify(struct i2c_client *client,
                                  struct mxt_data *mxt)
  {
***************
*** 2559,2564 ****
--- 2565,2585 ----
                msleep(30);
                goto retry_i2c;
        }
+ #ifdef FIX_CHIP_HANG
+       /* If we tried twice and no response, maybe it's in firmware
+        * load mode. Try to upload firmware.
+        */
+       if (mxt->read_fail_counter == 2) {
+               printk(KERN_DEBUG "Trying firmware reload.");
+               mxt->last_read_addr = -1;
+
+               mxt_do_firmware_load(mxt, MXT1386_FIRMWARE);
+
+               reset_chip(mxt, RESET_TO_NORMAL);
+               msleep(300);
+               goto retry_i2c;
+       }
+ #endif
                dev_err(&client->dev, "Failure accessing maXTouch device\n");
                return -EIO;
        }
diff -c drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c drivers/input/touchscreen/atmel_mxt1386_cfg.c
*** drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c  2012-10-10 08:12:43.773952501 -0400
--- drivers/input/touchscreen/atmel_mxt1386_cfg.c       2012-10-10 08:36:55.704576439 -0400
***************
*** 408,417 ****

        return 0;
  }
- int mxt_load_firmware(struct device *dev, const char *fn)
- {
-       struct mxt_data *mxt = dev_get_drvdata(dev);

        unsigned int frame_size;
        unsigned int pos = 0;
        unsigned int retry;
--- 408,416 ----

        return 0;
  }

+ int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn)
+ {
        unsigned int frame_size;
        unsigned int pos = 0;
        unsigned int retry;
***************
*** 518,520 ****
--- 517,526 ----
        return ret;
  }

+ int mxt_load_firmware(struct device *dev, const char *fn)
+ {
+       struct mxt_data *mxt = dev_get_drvdata(dev);
+
+       return mxt_do_firmware_load(mxt, fn);
+ }
+
 
  • Like
Reactions: Elibl

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    Ok, in this thread I will describe one problem that I have faced with my Iconia and that was also reported by one other user on a forum.

    Basically, Iconia uses Atmel mxt1386 touchscreen controller. The same controller is used in Asus EEE Transformer and Motorola Xoom and even Samsung Galaxy Tab 10.1. So far, there are a lot of reports of EEE Transformer's and Xoom's touchscreens suddenly stopping working and starting working after a full battery discharge.

    One day after a reboot my Iconia stopped booting - it keeped hanging on the Acer logo and when I tried entering recovery it was hanging at "booting recovery kernel image". However, that only happened with Acer kernels. With my own kernel, ported from EEE Transformer, the tablet could boot. I have recompiled the acer kernel with framebuffer console and found out it got stuck at the touchscreen interrupt handler while EEE's driver just printed an error and stopped working.. Basically, the response I got from from the touchscreen was [1, 0x80, 0, 0, 0, 0, 0, 0]. And it was not detected with i2cdetect

    At first, I thought my touchscreen cable was damaged. I have disassembled the tablet and tried twisting the cable to see if it gives any result. My result was that if I disconnect and reconnect the cable, an interrupt comes. Btw, the cable has sharp 'teeth' and you can crimp it pretty much like ethernet.

    Ok, so then I added some printks to the driver. Turns out, when some data coming from the touchscreen was incorrect, the driver hanged (deadlocked) because the semaphore was pushed down two times and never upped. So, I have commented out semaphores and bingo - it continued booting. Although there were a lot of warn_slowpath errors and CRC error, it reported correct coordinates. I flashed Acer's kernel after it and it booted fine. Looks like a proper init by Acer driver reset the controller.

    The archive in the link contains tegra i2c driver from the chromium tree (in case it finds i2c errors like nak, it retries the transmission several times) and the touchscreen driver. You need to comment out "#define USE_SEMA" to disable semaphores and build the kernel with it in case you encounter the problem..
    http://www.mediafire.com/?jt6b19nr7rsy70s

    I do not have another 'brick' to test if my solution works in all cases but I'm just leaving the stuff here in case anyone faces the trouble. To flash when your tablet is not booting you'll probably some help from sc2k..

    What's the moral of the story? The moral is that as touchscreen is not used in recovery, it may be a good idea to add the 'hacked and buggy' driver to the recovery kernel to allow to recover the device by just booting recovery in case anyone faces the problem.. Of course it's better to fix the driver properly or even use the driver from mainline linux and patch it.

    EDIT 29-oct-2011:
    here is a link to the cwm recovery image with the 'hacked' driver. Boots just fine.
    http://www.mediafire.com/?39jk1j15wkpr57o
    3
    I had this problem with my Galaxy Tab and tried the fixes mentioned but it just didn't work for me. I have, however, figured out what's really going wrong.

    I always had this failure showing up in dmesg:
    [ 1.707677] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
    [ 1.707913] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
    [ 1.708080] tegra-i2c tegra-i2c.1: Packet status 0x00010009
    [ 1.709363] Warning: To wake up touch-ic in deep sleep, retry i2c communication!
    [ 1.748037] tegra-i2c tegra-i2c.1: I2c error status 0x00000008
    [ 1.748355] tegra-i2c tegra-i2c.1: no acknowledge from address 0x4c
    [ 1.748523] tegra-i2c tegra-i2c.1: Packet status 0x00010009
    [ 1.749788] sec_touch 1-004c: Failure accessing maXTouch device

    So, it can't read from the touchscreen controller at address 0x4c. The fix mentioned in this thread was to re-write the configuration, with the assumption that the device was somehow wedged. That doesn't work either, since you can't write to 0x4c - same lack of acknowledgement.

    I tried adding a reset. No change. Disconnected the battery overnight. Also no change.

    Then, I realized what's going on. The MXT1386 has a "Firmware Update" mode. When you put it into update mode, the device address changes from 0x4c to 0x26! Once it gets into that mode, it doesn't respond to the original address. Since I don't have the docs for the device, I just called the driver function that updates the firmware. Once that process is complete and the chip reset, it reverts to its original address. At that point (after a final reboot), all is well.

    I have a replacement kernel that you can install and boot which re-enables the touchpad. I'd suggest making a nandroid backup first, installing my kernel, then restoring the nandroid once it's fixed.

    http://www.rickmurphy.net/mxt1386_fixer.zip. While this is a p4wifi (Gtab 10.1 Wifi-only) it'll probably fix the problem on a 3G tablet as well as long as you restore the correct kernel once it's done..

    Whew. It's good to have the toy back working.
    1
    So just to clarify this is a software/recovery problem not a hardware problem?
    1
    Ok, I will post the reply from sc2k who investigated the issue a bit. Let's keep it here for reference. I think it will be nice to patch the mainline driver (from chromium or mainline linux) and use it instead of acer's driver but I won't probably do it unless I hit the issue again or make some progress with my chromium kernel

    sc2k said:
    Ok.. I finally understand the issue:

    Your tochscreen always responded with [1, 0x80, 0, 0, 0, 0, 0, 0]
    buffer[1].bit7 seems to be some kind of "message incomplete" bit. As this is always transmitted, the worker thread never releases the semaphore which causes the ATMEL_Initial to stop at ATMEL_SyncWithThreadToReadMsg.

    After you disabled the semaphore, ATMEL_Initial continues. ConfigError is probably 0, so next function to be called will be ATMEL_CheckConfig.

    This function first calls ATMEL_SendCMDgetCRC. As semaphores are disabled, this will probably not be able to receive the checksum (due to timing) so that ConfigChecksumError=1.

    If ConfigChecksumError==1, ATMEL_CheckConfig will call ATMEL_WriteConfig and ATMEL_Backup that will probably be successful and thus fixes the configuration issue. Even if it does not complete succesfully, the whole recovery process is repeated until all conditions are satisfied.

    Conclusion:
    - Somehow the configuration in your touchscreen controller got messed up.
    - Removing the semaphores triggered ATMEL_WriteConfig + ATMEL_Backup which probably fixed the issue.

    I believe, a good fix would be to add a check "if (counts > 20) { up(&mxt->sema); goto fail; }" or similar to mxt_worker for irq_type == ATMEL_ReadResponseMsg_Noaddress. This would prevent these endless interrupt loop and allow the driver to fix the configuration.

    Really nice bug that you have found in this driver
    1
    Sure that's only system hangs... I ment does your fix help for input lags/death regarding 0x4c address/firmware update mode... If you show me the diff I could just test it... Would be highly appreciated :)

    No, the system doesn't hang, it works just fine if you plug in a keyboard.

    Here's the diff:
    Code:
    diff -c drivers/input/touchscreen/orig/atmel_mxt1386.c drivers/input/touchscreen/atmel_mxt1386.c
    *** drivers/input/touchscreen/orig/atmel_mxt1386.c      2012-10-10 08:11:10.543325982 -0400
    --- drivers/input/touchscreen/atmel_mxt1386.c   2012-10-10 08:35:30.545044039 -0400
    ***************
    *** 22,27 ****
    --- 22,29 ----
       *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
       */
    
    + #define FIX_CHIP_HANG
    +
      #define       DEBUG_INFO      1
      #define       DEBUG_VERBOSE   2
      #define       DEBUG_MESSAGES  5
    ***************
    *** 2539,2544 ****
    --- 2541,2550 ----
      /* Initialization of driver                                                   */
      /******************************************************************************/
    
    + #ifdef FIX_CHIP_HANG
    + extern int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn);
    + #endif
    +
      static int __devinit mxt_identify(struct i2c_client *client,
                                      struct mxt_data *mxt)
      {
    ***************
    *** 2559,2564 ****
    --- 2565,2585 ----
                    msleep(30);
                    goto retry_i2c;
            }
    + #ifdef FIX_CHIP_HANG
    +       /* If we tried twice and no response, maybe it's in firmware
    +        * load mode. Try to upload firmware.
    +        */
    +       if (mxt->read_fail_counter == 2) {
    +               printk(KERN_DEBUG "Trying firmware reload.");
    +               mxt->last_read_addr = -1;
    +
    +               mxt_do_firmware_load(mxt, MXT1386_FIRMWARE);
    +
    +               reset_chip(mxt, RESET_TO_NORMAL);
    +               msleep(300);
    +               goto retry_i2c;
    +       }
    + #endif
                    dev_err(&client->dev, "Failure accessing maXTouch device\n");
                    return -EIO;
            }
    diff -c drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c drivers/input/touchscreen/atmel_mxt1386_cfg.c
    *** drivers/input/touchscreen/orig/atmel_mxt1386_cfg.c  2012-10-10 08:12:43.773952501 -0400
    --- drivers/input/touchscreen/atmel_mxt1386_cfg.c       2012-10-10 08:36:55.704576439 -0400
    ***************
    *** 408,417 ****
    
            return 0;
      }
    - int mxt_load_firmware(struct device *dev, const char *fn)
    - {
    -       struct mxt_data *mxt = dev_get_drvdata(dev);
    
            unsigned int frame_size;
            unsigned int pos = 0;
            unsigned int retry;
    --- 408,416 ----
    
            return 0;
      }
    
    + int mxt_do_firmware_load(struct mxt_data *mxt, const char *fn)
    + {
            unsigned int frame_size;
            unsigned int pos = 0;
            unsigned int retry;
    ***************
    *** 518,520 ****
    --- 517,526 ----
            return ret;
      }
    
    + int mxt_load_firmware(struct device *dev, const char *fn)
    + {
    +       struct mxt_data *mxt = dev_get_drvdata(dev);
    +
    +       return mxt_do_firmware_load(mxt, fn);
    + }
    +