Touchscreen from CHUWI Vi10: ATMEL_MXT_TS and Ft5x0x_ts = what is this and how to?

[sergk...@gmail.com]

Hiya All!

New tablet ;-) old problems.
Goal - to tun Linux on Chuwi Vi10 rev 11: Current problem: Make it working touchscreen!
There are Android with i2c-tools on it and Windows 8. - for digging and researching hardware.

What I have discovered in Android:

lsmod shows loaded atmel_mxt_ts
at the same time under /sys/bus/i2c/i2c-4/i2c-4:0038 is present (name) ft5x0x_ts.

In Android also detected

atmel_mxt_ts.idc
ft5x0x_ts.idc

which consists of nothing:

cat atmel_mxt_ts.idc ft5x0x_ts.idc

touch.deviceType = touchScreen
touch.orientationAware = 1

touch.deviceType = touchScreen
touch.orientationAware = 1

No any other firmware detected. Looks like is built in in kernel module but ExeCut does not shows any usefull symbols that looks like firmware. (module  attached).

QUESTIONS:

1) How to determine which exactly touch screen is used?
2) What is correlation between atmel_mxt_ts module and ft5x0x_ts  touchscreen? This looks very strange! Why and how it is possible to use atmel driver for focaltech?
3) Lets assume that this is ft5x0x_ts - what is the sequence and logic of its initialization and using?

Is it so:

1) Wake up TS controller with setup gpio to 1 (high level)

2) load driver  (which one for atmel (this one is in vanilla kernel) or for focaltech)  that loads firmware ???  -  where to read details of this process or how and what to load into ft5x0x?  Touch is located on 0x38 at i2c-4, so it is possible to dump firmware from Android, but where is it is located and how organizes?

Thanks in advance! As a base I have porting GSL1680 on Chuwi vi8 experience.

Regards,
           Serge Kolotylo.

[Priit Laes]

On Wed, 2016-02-10 at 18:41 -0800, sergk...@gmail.com wrote:
> Hiya All!
>
> New tablet ;-) old problems.

Please go through http://linux-sunxi.org/New_Device_howto

> -- 
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sergk...@gmail.com]

Hi, Priit.

But this is not new device (I mean touchscreen) - Chuwi Vi10  (approximately) has  focaltech TS ft5x0x that is supported in sunxi under arm or atmel, thats why I have created this thread - to grab practical info and to port it to Baytrail.

I have mentioned Chuwi vi10 as a platform that makes it clear that this is not arm, and recypes should be ported.

Regards,

            Serge.

[Priit Laes]

On Thu, 2016-02-11 at 02:58 -0800, sergk...@gmail.com wrote:
> Hi, Priit.
> But this is not new device (I mean touchscreen) - Chuwi Vi10 
> (approximately) has  focaltech TS ft5x0x that is supported in sunxi
> under arm or atmel, thats why I have created this thread - to grab
> practical info and to port it to Baytrail.

Oops.. my bad. Didn't realise it was x86 (or amd64) platform.

This is what I would do: first, dump and disassemble ACPI data to see
which driver is actually used.

Driver for ft5x0x is already available in mainline Linux kernel, but it
lacks ACPI support. You can see how ACPI stuff is implemented from
existing drivers (goodix, elants_i2c or even atmel_mxt_ts).

Also, linux-input would be better mailinglist for such discussions.

> I have mentioned Chuwi vi10 as a platform that makes it clear that
> this is not arm, and recypes should be ported.
> Regards, 
>             Serge.
>
>
>

[sergk sergk2mail]

"Driver for ft5x0x is already available in mainline Linux kernel, but it
lacks ACPI support. "

What do you mean via lacks ACPI?  If you mean just turn on the touch - is it possible to do it via gpio pin via sysfs? For what do you need ACPI?

Actually code in Vanilla kernel is weird.

What is the logic of chip ? For example my is located in Linux 4.4.1 on i2c-3 0x38.

I could create easily i2c device like echo MYTOUCH 0x38 >/sys/bus/i2c/i2c-3/newdevice.

I could enable (to 1) gpio pin.

What farther should I do according logic of communication with ft5x0x?

I miss the same page like for gsl1680 http://linux-sunxi.org/GSL1680

Could someone explain the core of logic for ft5x0x - does it require any firmware at all?

What does mean offsets from Vanilla driver? Does this base (i2c address + offset) to read for example register storing num x?

#define WORK_REGISTER_THRESHOLD         0x00
#define WORK_REGISTER_REPORT_RATE       0x08
#define WORK_REGISTER_GAIN              0x30
#define WORK_REGISTER_OFFSET            0x31
#define WORK_REGISTER_NUM_X             0x33
#define WORK_REGISTER_NUM_Y             0x34

#define M09_REGISTER_THRESHOLD          0x80
#define M09_REGISTER_GAIN               0x92
#define M09_REGISTER_OFFSET             0x93
#define M09_REGISTER_NUM_X              0x94
#define M09_REGISTER_NUM_Y              0x95

#define NO_REGISTER                     0xff

#define WORK_REGISTER_OPMODE            0x3c
#define FACTORY_REGISTER_OPMODE         0x01

#define TOUCH_EVENT_DOWN                0x00
#define TOUCH_EVENT_UP                  0x01
#define TOUCH_EVENT_ON                  0x02
#define TOUCH_EVENT_RESERVED            0x03

#define EDT_NAME_LEN                    23
#define EDT_SWITCH_MODE_RETRIES         10
#define EDT_SWITCH_MODE_DELAY           5 /* msec */
#define EDT_RAW_DATA_RETRIES            100
#define EDT_RAW_DATA_DELAY              1 /* msec */

[Gregor Riepl]

> What do you mean via lacks ACPI? If you mean just turn on the touch - is it
> possible to do it via gpio pin via sysfs? For what do you need ACPI?

You need it for various things:
- Hardware ID matching
- Automatic configuration of IRQ and GPIO pins
- Bus addresses
- Power management

In a USB or PCI driver, these are not vital, because device IDs and
configuration data are normally obtained from the device descriptor.
But for I2C or similar I/O interfaces, you don't have that, so the information
needs to come from somewhere else.
On x86 platforms, this is usually the DSDT, obtained via ACPI.

It's usually not that hard to add ACPI support to Linux driver, however, as
I've recently discovered.

If you can't figure it out yourself, someone here may be able to help you.
Dump your DSDT and post it somewhere:

# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
# iasl -d dsdt.dat

> Could someone explain the core of logic for ft5x0x - does it require any
> firmware at all?
> What does mean offsets from Vanilla driver? Does this base (i2c address +
> offset) to read for example register storing num x?

I haven't looked at the code, but these look like device-internal registers to
me, not the device address on the I2C bus.

[sergk...@gmail.com]

Hi Gregori.

Thank you for explanation regarding ACPI, but - in case if you have working device (Android as I have wrote before) - all information is available from Android kernel.
fortunately address on I2C is usually for touchscreens fixed  and in my case it is 0x38. (under Android it is i2c-4. under 4.4.1 it is i2c-3, 0x040).
I have found gpio TS wakeup\or init (the same?) pin = in my case it is 393.
Main question is  - OK I have i2c address, I have gpio pin - what should be done next? I do not understand whether ft5x0x has and loads firmware. Does it have and load?
And if yes - what is the logic of this chip - where it is stored firmware? (which address range), what registers does it have and how to bind this registers to base i2c = 0x40.
At the moment main question is - how to initialize this chip to obtain (I guess as I described before from Vanilla kernel) x,y coordinates.

In sunxi this chip is fully supported, so, definitely someone knows the full sequence of logic of this chip.

Regards,
 
             Serge Kolotylo.

[sergk...@gmail.com]

Actually I did mistake  - in my instance of tablet there is no ft5x0t it looks that instead there is chipone-icn85xx. I have firmware for it.
So I am leaving this topic in favour of new one, in sunxi chipone-icn85xx also implemented.
For those who have ft5x0c may be this thread will be useful.