Trouble

[A13 tablet] Looking for some help with touchscreen

10 2561
Edited by destroyedlolo at Jan 07, 2016 17:35

Hello,

I know I'm out of topic with this forum, but I take my chance here as nobody replying on SunXI group

So, I resurrected a bricked tablet (http://linux-sunxi.org/index.php?title=MID-KLIPAD_HC-913) making it running under Gentoo/Linux. Unfortunately, I'm facing some issues with its touch screen (Silead GSL3680).

The original Andoid FEX is containing :
        
  1. [ctp_para]
  2.           ctp_used = 1
  3.           ctp_name = "ft5x_ts"
  4.           ctp_twi_id = 1
  5.           ctp_twi_addr = 0x3f
  6.           ctp_screen_max_x = 800
  7.           ctp_screen_max_y = 480
  8.           ctp_revert_x_flag = 0
  9.           ctp_revert_y_flag = 0
  10.           ctp_exchange_x_y_flag = 0
  11.           ctp_int_port =port:PG11<6><default><default><default>
  12.           ctp_wakeup =port:PB03<1><default><default><1>
  13.           ctp_io_port =port:PG11<0><default><default><default>
  14.           ctp_light =port:PA05<1><default><default><0>

  15. [autotp5]
  16.           tpaddr = 64
  17.           tpname = "gslx680"
  18.           tpreset = 0
  19.           tpdelay = 200
  20.           tpreg = 0
  21.           tpvaule = 0
  22.           tpupdate = 0
  23.           tpselect = 0
Copy the Code
         and I changed it as per the instructions I found on the driver's webpage:
               
  1. [ctp_para]
  2.           ctp_used = 1
  3.           ctp_name = "gslx680"
  4.           ctp_twi_id = 1
  5.           ctp_twi_addr = 0x40
  6.           ctp_screen_max_x = 800
  7.           ctp_screen_max_y = 480
  8.           ctp_revert_x_flag = 0
  9.           ctp_revert_y_flag = 0
  10.           ctp_exchange_x_y_flag = 0
  11.           ctp_int_port =port:PG11<6><default><default><default>
  12.           ctp_wakeup =port:PB03<1><default><default><1>
  13.           ctp_io_port =port:PG11<0><default><default><default>
  14.           ctp_light =port:PA05<1><default><default><0>
  15.           ctp_firmware = "actif.fw"
Copy the Code


But, if I'm trying to load the module, I got the following trace :        
      
  1. [91.338172]===========================gslx680_ts_init=====================
  2. [   91.338191] _fetch_sysconfig_para.
  3. [   91.338216] gslx680 firmware actif.fw.
  4. [   91.338228] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe
  5. [   91.338239] _fetch_sysconfig_para: ctp_twi_id is 1.
  6. [   91.338248] _fetch_sysconfig_para: screen_max_x = 800.
  7. [   91.338256] _fetch_sysconfig_para: screen_max_y = 480.
  8. [   91.338264] _fetch_sysconfig_para: revert_x_flag = 0.
  9. [   91.338272] _fetch_sysconfig_para: revert_y_flag = 0.
  10. [   91.338283] _fetch_sysconfig_para: exchange_x_y_flag = 0.
  11. [   91.339294] i2c-core: driver [gslx680] using legacy suspend method
  12. [   91.339309] i2c-core: driver [gslx680] using legacy resume method
  13. [   91.339337] ctp_detect: Detected chip gslx680 at adapter 1,  address 0x40
  14. [   91.340318] ====gslx680_ts_probe begin=====.  
  15. [   91.340334] ==kzalloc success=
  16. [   91.340340] [GSLX680] Enter gsl_ts_init_ts
  17. [   91.340362] ctp_set_irq_mode: config gpio to int mode.
  18. [   91.340389] ctp_set_irq_mode, 854: gpio_int_info, port = 7, port_num = 11.
  19. [   91.340396]  INTERRUPT CONFIG
  20. [   91.341055] input: gslx680 as /devices/platform/sunxi-i2c.1/i2c-1/1-0040/input/input1
  21. [   91.366514] incomplete xfer (0xff)
  22. [   91.366532] reset_chip: gsl_ts_write 1 fail!
  23. [   91.366541] init_chip: reset_chip fail: -70
  24. [   91.366552] gslx680 1-0040: init_chip failed
  25. [   91.366582] gslx680: probe of 1-0040 failed with error -70
  26.          
Copy the Code

        
        and as you  can see the chip is present on the I2C bus :
        
      
  1. Tablette ~ # i2cdetect 1

  2.         WARNING! This program can confuse your I2C bus, cause data loss
  3.         and worse!
  4.         I will probe file /dev/i2c-1.
  5.         I will probe address range 0x03-0x77.
  6.         Continue? [Y/n] y

  7.              0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
  8.         00:          -- -- -- -- -- -- -- -- -- -- -- -- --
  9.         10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  10.         20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  11.         30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  12.         40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  13.         50: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
  14.         60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Copy the Code

        Does someone having  any clue how I can make it working ?
        
        Thanks
        
        Laurent
        
Not sure if it'll help but could you try running the bus at 400kHz....would require a kernel compile.

And the firmware is correct I presume.
Have you extracted it from the Android system or are using the one with the driver?

sashijoseph replied at Jan 08, 2016 08:00
Not sure if it'll help but could you try running the bus at 400kHz....would require a kernel compile ...

Not an issue to re-build a kernel, but I wasn't aware I can change the speed of the I2C buses (I tought it is always 400 khz). Do you know which is the parameter to change ?

And the firmware is correct I presume.
Have you extracted it from the Android system or are using the one with the driver?

I had a discuss with "Joe" who ported the driver to Sunxi : the problem seems at reset stage of the chip, so before it is trying to load the firmware.


Not an issue to re-build a kernel, but I wasn't aware I can change the speed of the I2C buses (I tought it is always 400 khz). Do you know which is the parameter to change ?

It's the "i2c.h" in /arch/arm/plat-sunxi/include/plat/

  1. #define I2C0_TRANSFER_SPEED     (400000)
  2. #define I2C1_TRANSFER_SPEED     (100000)
  3. #define I2C2_TRANSFER_SPEED     (100000)
  4. #define I2C3_TRANSFER_SPEED     (100000)
  5. #define I2C4_TRANSFER_SPEED     (100000)
Copy the Code


Only i2c0 is 400kHz by default.

have you looked at /proc/interrupts ?
does it show proper interrupt activity for the ts module?

Ok, thanks for the information.
As per exchanges I had with Joe, it should be linked with reset signal, so I'll first investigate this way and in parallel check for I2C speed.

Will keep you updated.

Yes,tracing from the reset_chip code the error seems to point to
/* Bus error during master or slave mode due to illegal level condition */

Yes,tracing from the reset_chip code the error seems to point to
/* Bus error during master or slave mode due to illegal level condition */

Hello,

I didn't progressed so much
I found only a Chinese datasheet from SunXI web site (all other links are pointing to it), and I requested some friend of I to (unfortunately) partially translate it for me : you know, my Chinese is not as it should be

So :
  • They are saying the chip is compatible with 400Khz slave mode (but does it mean it isn't compatible w/ 100 khz). Anyway, as said previously, I'll recompile my kernel.
  • They explained the format of write cycle (address, then data as it is explained on SunXI's about 1680) ... but not how to initiate the write cycle.
  • The pin used on the 1680 to initiate writing ... is not present on the 3680 (or it has another name).

So, all in all, I'm not so sure that gslx680 driver can even work with this ship

I sent a mail to Silead  for additionnal documentation w/o to much hope ...

Bye
Laurent

So I almost totally translated the GSL3680 datasheet :
  • it seems playing with control line is not needed to upload anything to the chip : it follows standard I2C write cycle
  • this datasheet only explain general information about the chip ... but not which register to read and which one to configure ... I need "GSL3680 application guide"

seems the i2c_sunxi module is not able to write to the bus.
it is commanded by the gslx680 code to write 0x88 to the gsl's 0xe0 register(part of reset chip procedure)

it starts by putting out the START signal on the bus and then proceeds to read the STATUS register of the sunxi i2c controller.
The STATUS register shows error code 0xff which is reported with the incomplete xfer message.
the error code stands for "Bus error during master or slave mode due to illegal level condition"

can't say what the illegal level condition is pointing at.

you must enable i2c debugging in the kernel to see if any more information is obtained.

You have to log in before you can reply Login | Sign Up

Points Rules