Chipone icn85xx support in x86 linux kernel

Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hello All,
Please advice whether it is supported touch screen icn85xx in anykind
of x86 (baytrail interested in!) kernel?

I have discovered in Vanilla chipone_icn8318.c  kernel driver from Hans de Goede
but this driver in contrast to arm available icn83xx.c looks really
strange, it is even excluded from Kconfig by default in 4.4.1: it has
no firmware load while at the same time android driver
https://android.googlesource.com/kernel/bcm/+/android-bcm-tetra-3.10-lollipop-wear-release/drivers/input/touchscreen/icn83xx.c
has.
Also for rtk3128 chip there is!  icn85xx driver:
https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c

I am trying to make it working my touch on Chuwi Vi10 (Baytrail
Z3536), Archlinux, custom 4.4.1 (from Vanilla) kernel.
What I have discovered from Windows and Android: I2c address of TS is
0x48, in Android it is located under i2c-4 0x48

>: cat /sys/bus/i2c/devices/i2c-4/4-0048/name
chipone-icn85xx.

Under windows 8.1 there is icnfirmware.sys for it. (;-) no need to
grab it!), fw also present in .h file of rtk3128 github repo.
GPIO pin I have guessing to enable TS is 393 (stupid looking over all
gpios via sysfs and enabling each to 1).

So my farther additional questions are:

2) Could be icn8318 by Hans de Goede be adopted for icn85xx?
3) Looks currently kernel is not supported ACPII for icn85xx
4) Please advice how to (if possible) having windows and android with
working touch to grab all needed information for makes device working
with kernel (gpio pins).
5) In Windows driver is myi2c.sys and reports that this is chipone ts,
in Android is loaded atmel_mxt_ts module and the most strange thing
afrer rmmod touch is working.
dmesg under android shows: input: chipone-ts as /devices/virtual/input/input5.
modalis: input:b0000v0000p0000-e0,1,3,k8b,9e,d9,ra2f,30,32,35,36,39,m1sfw
how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?

Thanks in advance,
      hope together we will make it working under x86!
Regards,
                 Serge Kolotylo.

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hello,
Just would like to add the following:
There is driver for icn8318 in vanilla kernel.
On Chuwi Vi10 looks that INT/WAKE gpio pin is gpio393 (vanila 4.4.2 x86_64 krnl)
I have firmware for it from Windows driver (separate file).
I have some specs for Chipone ICN88xx (which is the same as 85xx).

:( I have stucked with understanding how to initialize this chip.
At the moment trying to do this via sysfs + i2c-tools.
In Android have read main registers data, when the chip is initialized.

There are also sources for Linux but arm-based platforms:

https://github.com/bbelos/rk3188-kernel/tree/master/drivers/input/touchscreen/ICN8503
http://dl.linux-sunxi.org/SDK/A80/A80_SDK_20140728_stripped/lichee/linux-3.4/drivers/input/touchscreen/icn83xx/

Will be happy if someone would like to help or join efforts of
building the driver for icn85xx on Linux vanilla kernel.
Regards,
                   Serge Kolotylo.


ACPI data:

            Device (TCS5)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "CHPN0001")  // _HID: Hardware ID
                Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus)
*/)  // _CID: Compatible ID
                Name (_S0W, Zero)  // _S0W: S0 Device Wake State
                Name (_DEP, Package (0x02)  // _DEP: Dependencies
                {
                    GPO1,
                    I2C5
                })
                Method (_PS3, 0, Serialized)  // _PS3: Power State 3
                {
                }

                Method (_PS0, 0, Serialized)  // _PS0: Power State 0
                {
                    If ((^^^GPO1.AVBL == One))
                    {
                        ^^^GPO1.TCD3 = Zero
                    }

                    Sleep (0x05)
                    If ((^^^I2C5.PMI1.AVBG == One))
                    {
                        ^^^I2C5.PMI1.TCON = One
                    }

                    Sleep (0x1E)
                    If ((^^^GPO1.AVBL == One))
                    {
                        ^^^GPO1.TCD3 = One
                    }

                    Sleep (0x78)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current
Resource Settings
                {
                    Name (RBUF, ResourceTemplate ()
                    {
                        I2cSerialBus (0x0030, ControllerInitiated, 0x00061A80,
                            AddressingMode7Bit, "\\_SB.I2C4",
                            0x00, ResourceConsumer, ,
                            )
                        Interrupt (ResourceConsumer, Level,
ActiveHigh, Exclusive, ,, )
                        {
                            0x00000044,
                        }
                        GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x001A
                            }
                    })
                    Return (RBUF) /* \_SB_.I2C4.TCS5._CRS.RBUF */
                }

                Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
                {
                    Name (_T_1, Zero)  // _T_x: Emitted by ASL Compiler
                    Name (_T_0, Zero)  // _T_x: Emitted by ASL Compiler
                    Debug = "Method _DSM begin"
                    If ((Arg0 == ToUUID
("3cdff6f7-4267-4555-ad05-b30a3d8938de") /* HID I2C Device */))
                    {
                        While (One)
                        {
                            _T_0 = ToInteger (Arg2)
                            If ((_T_0 == Zero))
                            {
                                While (One)
                                {
                                    _T_1 = ToInteger (Arg1)
                                    If ((_T_1 == One))
                                    {
                                        Debug = "Method _DSM Function Query"
                                        Return (Buffer (One)
                                        {
                                             0x03
                       /* . */
                                        })
                                    }
                                    Else
                                    {
                                        Return (Buffer (One)
                                        {
                                             0x00
                       /* . */
                                        })
                                    }

                                    Break
                                }
                            }
                            Else
                            {
                                If ((_T_0 == One))
                                {
                                    Debug = "Method _DSM Function HID"
                                    Return (Zero)
                                }
                                Else
                                {
                                    Return (Zero)
                                }
                            }

                            Break
                        }
                    }
                    Else
                    {
                        Return (Buffer (One)
                        {
                             0x00
       /* . */
                        })
                    }
                }

                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If ((OSSL & 0x80))
                    {
                        Return (Zero)
                    }

                    If ((OSYS == 0x07DD))
                    {
                        Return (0x0F)
                    }
                    Else
                    {
                        Return (0x0F)
                    }
                }
            }
        }

Regards,
                Serge Kolotylo.

On Sun, Feb 14, 2016 at 11:03 PM, sergk sergk2mail
<sergk.admin@gmail.com> wrote:
> Hello All,
> Please advice whether it is supported touch screen icn85xx in anykind
> of x86 (baytrail interested in!) kernel?
>
> I have discovered in Vanilla chipone_icn8318.c  kernel driver from Hans de Goede
> but this driver in contrast to arm available icn83xx.c looks really
> strange, it is even excluded from Kconfig by default in 4.4.1: it has
> no firmware load while at the same time android driver
> https://android.googlesource.com/kernel/bcm/+/android-bcm-tetra-3.10-lollipop-wear-release/drivers/input/touchscreen/icn83xx.c
> has.
> Also for rtk3128 chip there is!  icn85xx driver:
> https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
>
> I am trying to make it working my touch on Chuwi Vi10 (Baytrail
> Z3536), Archlinux, custom 4.4.1 (from Vanilla) kernel.
> What I have discovered from Windows and Android: I2c address of TS is
> 0x48, in Android it is located under i2c-4 0x48
>
>>: cat /sys/bus/i2c/devices/i2c-4/4-0048/name
> chipone-icn85xx.
>
> Under windows 8.1 there is icnfirmware.sys for it. (;-) no need to
> grab it!), fw also present in .h file of rtk3128 github repo.
> GPIO pin I have guessing to enable TS is 393 (stupid looking over all
> gpios via sysfs and enabling each to 1).
>
> So my farther additional questions are:
>
> 2) Could be icn8318 by Hans de Goede be adopted for icn85xx?
> 3) Looks currently kernel is not supported ACPII for icn85xx
> 4) Please advice how to (if possible) having windows and android with
> working touch to grab all needed information for makes device working
> with kernel (gpio pins).
> 5) In Windows driver is myi2c.sys and reports that this is chipone ts,
> in Android is loaded atmel_mxt_ts module and the most strange thing
> afrer rmmod touch is working.
> dmesg under android shows: input: chipone-ts as /devices/virtual/input/input5.
> modalis: input:b0000v0000p0000-e0,1,3,k8b,9e,d9,ra2f,30,32,35,36,39,m1sfw
> how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?
>
> Thanks in advance,
>       hope together we will make it working under x86!
> Regards,
>                  Serge Kolotylo.

Re: Chipone icn85xx support in x86 linux kernel

[Gregor Riepl]

> 2) Could be icn8318 by Hans de Goede be adopted for icn85xx?

chipone_icn8318.c lacks ACPI support. It may not be difficult to add though.

The question is if both chips are sufficiently compatible.

> how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?

That sounds very odd. Perhaps they share the same control interface?
Or perhaps Chipone just cloned the Atmel chips...

I'm pretty certain that a specific firmware is required for your chip, though.

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Would like to add that specs are located
https://gitlab.com/antruziliak/icn8528.git
The main question - how to wake up chip.
Looks that 2 gpios are used INT/WAKE + RST.
Regards,
               Serge Kolotylo.

On Tue, Mar 1, 2016 at 10:07 AM, Gregor Riepl <onitake@gmail.com> wrote:
>> 2) Could be icn8318 by Hans de Goede be adopted for icn85xx?
>
> chipone_icn8318.c lacks ACPI support. It may not be difficult to add though.
>
> The question is if both chips are sufficiently compatible.
>
>> how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?
>
> That sounds very odd. Perhaps they share the same control interface?
> Or perhaps Chipone just cloned the Atmel chips...
>
> I'm pretty certain that a specific firmware is required for your chip, though.
>

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi ALL.
Gathered all answers to the received questions in the code.
What I did: Using my experience of gsl1680 (userspace) on Chuwi Vi8
and reviewing code
https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
mentioned in the 1st my message (icn85xx.c) - I have created simple
module i2c client without ACPI that is using define constants for
manually setuping i2cbus (i2c-devX), i2cport and gpio pin then it
trying to wake up icn8528 chip and after trying to read main registers
according mentioned above specs for the chip.

0x000a - IcVersion, should be according Android data (i2cget -f 4 0x48
0x000a b) = 0x85 and is major chip version
0x000c - firmware version, according  Android (i2cget 4 0x48 0x000c b)
it is 0x38


Main goal of this module - just to wakeup chip and read some data from
it to ensure that it is working as expected.
For Gregor: in the code there is hw_init - this is my way (actually
attempt) to wake up the chip, also in the code there is the same but
in kernel space I've sent to you (userspace version) of using gpio.
For simplicity and discussing (read at once)  I have created "all in
one file" without includes and code splitting.

QUESTIONS:

 1) It is strange, but it looks that via Vanilla custom x8_64 Linux
4.4.2 ArchLinux   Baytrail on Chuwi Vi10 the Touchscreen Control Chip
probably resides not on 0x48  and it is resides on i2c-3 0x30. This
confused me completely, AFAIK chip could switch buses but not its
address.
Will be happy if anyone helps with this - whether it is possible for
chip to be i2c-4, 0x48 on Android and switched in Linux to i2c-3 0x30?

Also my discovering:
1.1)  On Chuwi Vi8 for gsl1680 it was only such Android: i2c-4, 0x40
and in Linux: i2c-3, 0x40 - only bus! But not address switching!

1.2) Taking into account decoded ACPI DSDT for Chipone icn8528
(CHPN0001) we see that  I2cSerialBus (0x0030, ControllerInitiated,
0x00061A80,
                            AddressingMode7Bit, "\\_SB.I2C4",
                            0x00, ResourceConsumer, ,
                            )

this makes sence of provided information into item 1.

2) I have not got positive results with my code - and still under
guessing whether I am not successful in waking up the chip or
something other wrong. :( I could not even read correct Chip version
in checking whether hw initialized correct.


3) Results of testing my code with different variations of i2cbus,
port  will be provided in next letter.

4) For Dmitry Torokhov : GPL or not included in main line of the
kernel according mentioned by you conditions for Chipone - I do not
care at the moment - my main goal is very simple - make myself happy
and at least get working touch on my Chuwi Vi10 rev 11 under ArchLinux
and help others owners of Baytrail tablets with TS on chipone icn85xx
to add OS Linux on their tablets.
The most important is very simple thing - to have driver for TS. May
be Chipone even approve farther adding it to the mainline (if it will
be created).
It is sad but Linux in contrast to Android has a lack of drivers for
touchscreen and many other hw of the tablets and this is to my mind is
very strange and reminding early times of 2.xx kernel. ;-) I am trying
to join and change this situation!

Regards,
                 Serge Kolotylo.




---------------- Testing Code:  ------------------------


#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/acpi.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/i2c.h>

#define TS_I2C_BUS 4
#define TS_I2C_ADDR 0x30
#define CTP_RST_PORT 393
#define DRIVER_VERSION "0.0.1"
#define CTP_NAME "chipone-ts"
#define ICN85XX_PROG_IIC_ADDR (0x30)


#define POINT_NUM                   5

#define ICN85XX_WITHOUT_FLASH           0x11
#define ICN85XX_WITH_FLASH              0x22

#define IIC_RETRY_NUM 3


typedef struct _POINT_INFO
{
    unsigned char  u8ID;
    unsigned short u16PosX;     // coordinate X, plus 4 LSBs for
precision extension
    unsigned short u16PosY;     // coordinate Y, plus 4 LSBs for
precision extension
    unsigned char  u8Pressure;
    unsigned char  u8EventId;
}POINT_INFO;


struct icn85xx_ts_data {
    struct i2c_client        *client;
    struct input_dev         *input_dev;
    struct work_struct       pen_event_work;
    struct workqueue_struct  *ts_workqueue;
    struct hrtimer           timer;
    spinlock_t               irq_lock;
    struct semaphore         sem;
    int         ictype;
    int         code_loaded_flag;
    POINT_INFO  point_info[POINT_NUM+1];
    int         point_num;
    int         irq;
    int         irq_is_disable;
    int         use_irq;
    int         work_mode;
    int         screen_max_x;
    int         screen_max_y;
    int         revert_x_flag;
    int         revert_y_flag;
    int         exchange_x_y_flag;
};

static struct i2c_client *this_client;

/***********************************************************************************************
Name    :   icn85xx_i2c_rxdata
Input   :   addr
            *rxdata
            length
Output  :   ret
function    : read data from icn85xx, normal mode
***********************************************************************************************/
int icn85xx_i2c_rxdata(unsigned short addr, char *rxdata, int length){
    int ret = -1;
    int retries = 0;

    unsigned char tmp_buf[2];
    struct i2c_msg msgs[] = {
        {
            .addr   = this_client->addr,
            .flags  = 0,
            .len    = 2,
            .buf    = tmp_buf,
        },
        {
            .addr   = this_client->addr,
            .flags  = I2C_M_RD,
            .len    = length,
            .buf    = rxdata,
        },
    };

    tmp_buf[0] = (unsigned char)(addr>>8);
    tmp_buf[1] = (unsigned char)(addr);
    while(retries < IIC_RETRY_NUM){
        ret = i2c_transfer(this_client->adapter, msgs, 2);
        if(ret == 2)break;
        retries++;
    }

    if (retries >= IIC_RETRY_NUM)
    printk("from %s: i2c read error: %d\n", __func__, ret);

    return ret;

}

/***********************************************************************************************
Name    :   icn85xx_read_reg
Input   :   addr
            pdata
Output  :
function    :   read register of icn85xx, normal mode
***********************************************************************************************/
int icn85xx_read_reg(unsigned short addr, char *pdata)
{
    int ret = -1;
    ret = icn85xx_i2c_rxdata(addr, pdata, 1);
    printk("From %s -  addr: 0x%x: 0x%x\n", __func__,addr, *pdata);
    return ret;
}



/***********************************************************************************************
Name    :   icn85xx_iic_test
Input   :   void
Output  :
function    : 0 success,
***********************************************************************************************/
static int icn85xx_iic_test(void){
    struct icn85xx_ts_data *icn85xx_ts = i2c_get_clientdata(this_client);
    int  ret = -1;
    char value = 0;
    int  retry = 0;
    int  flashid;
    icn85xx_ts->ictype = 0;
//    icn85xx_ts->ictype = ICN85XX_WITHOUT_FLASH;
//    return 1;
    printk("\nbegin %s",__func__);
    printk("\n BEGIN test another way of reading CurrFW ver");
    char mtmp[2];
    ret = icn85xx_i2c_rxdata(0x000c, mtmp, 2);
    short CurVersion;
    CurVersion = (mtmp[0]<<8) | mtmp[1];
    printk("\n CurrFW ver=%hu",CurVersion);

    printk("\n END test another way of reading CurrFW ver");

    while(retry++ < 3)
    {
        ret = icn85xx_read_reg(0xa, &value);
        if( (ret > 0) && (value == 0x85) ){
                icn85xx_ts->ictype = ICN85XX_WITH_FLASH;
            return ret;

        }
        ///////////////////////
        printk("\nBegin read fw ver from iictest");
        ret = icn85xx_read_reg(0xc, &value);
        printk("\nEnd read fw ver from iictest");

        printk("\nBegin read IC subver  from iictest");
        ret = icn85xx_read_reg(0xb, &value);
        printk("\nEnd read IC subver from iictest");

        ///////////////////////
        printk("iic test error! %d in %s\n", retry,__func__);
        msleep(3);
    }

    printk("\nend %s",__func__);
    return ret;
}




static int icn85xx_ts_probe(struct i2c_client *client, const struct
i2c_device_id *id){
    printk("\nhello from i2cprobe,%s",__func__);
    struct icn85xx_ts_data *icn85xx_ts;
    short fwVersion = 0;
    short curVersion = 0;
    int err = 0;
    int retry;

    printk("\n====%s begin=====.  \n", __func__);
    if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
    {
        printk("I2C check functionality failed from %s.\n",__func__);
        return -ENODEV;
    }

    //memdata
    icn85xx_ts = kzalloc(sizeof(*icn85xx_ts), GFP_KERNEL);
    if (!icn85xx_ts)
    {
        printk("Alloc icn85xx_ts memory failed. %s\n",__func__);
        return -ENOMEM;
    }
    memset(icn85xx_ts, 0, sizeof(*icn85xx_ts));
    this_client = client;
    this_client->addr = client->addr;
    i2c_set_clientdata(client, icn85xx_ts);

    icn85xx_ts->work_mode = 0;
    spin_lock_init(&icn85xx_ts->irq_lock);
//    icn85xx_ts->irq_lock = SPIN_LOCK_UNLOCKED;
    err = icn85xx_iic_test();
    if (err <= 0){
        printk("func %s: icn85xx_iic_test  failed.\n",__func__);
        return -1;
    }
    else
        printk("iic communication ok: 0x%x\n", icn85xx_ts->ictype);


    printk("\nBye from i2cprobe,%s",__func__);
return 0;
}


static int  icn85xx_ts_remove(struct i2c_client *client){
return 0;
}



static const struct i2c_device_id icn85xx_ts_id[] = {
    { CTP_NAME, 0 },
    {}
};

MODULE_DEVICE_TABLE(i2c, icn85xx_ts_id);

static struct i2c_driver icn85xx_ts_driver = {
    .class      = I2C_CLASS_HWMON,
    .probe      = icn85xx_ts_probe,
    .remove     = icn85xx_ts_remove,
    .id_table   = icn85xx_ts_id,
    .driver = {
        .name   = CTP_NAME,
        .owner  = THIS_MODULE,
    },
};

static struct i2c_board_info ts_info = {
    .type    = CTP_NAME,
    .addr    =  TS_I2C_ADDR,
};



static int icn85xx_hw_init(void){
    int err = 0;
    err = gpio_request(CTP_RST_PORT, CTP_NAME);
    if ( err ) {
    printk("\nError CTP_RST_PORTgpio in %s ",__func__);
    err = -EINVAL;
    return err;
    }
    err = gpio_direction_output(CTP_RST_PORT, 1);
    if ( err ) {
    printk("\nError CTP_RST_PORTgpiodirection in %s ",__func__);
    err = -EINVAL;
    return err;
    }
    msleep(20);
    gpio_set_value_cansleep(CTP_RST_PORT, 0);
    msleep(100);
    gpio_set_value_cansleep(CTP_RST_PORT, 1);
    msleep(300);
return err;
}

static int __init ts_init(void){
    printk("\nINIT icn MODULE,func %s",__func__);
    printk("\n get pwr gpio in func %s",__func__);
    icn85xx_hw_init();

    struct i2c_adapter *adap = i2c_get_adapter(TS_I2C_BUS);
    printk(KERN_ERR "==icn85xx ts_init %d at i2cbus:
%d!!!!!!!!\n",__LINE__,TS_I2C_BUS);
    i2c_new_device(adap, &ts_info);
    //i2c client reg
    int ret = -1;
    ret = i2c_add_driver(&icn85xx_ts_driver);


return 0;
}



static void __exit ts_exit(void){
    printk("\nEXIT icn MODULE,func:  %s",__func__);
    gpio_free(CTP_RST_PORT);
    i2c_del_driver(&icn85xx_ts_driver);

}


module_init(ts_init);
module_exit(ts_exit);
MODULE_DESCRIPTION("MyICN touchscreen controller driver");
MODULE_AUTHOR("Serge Kolotylo sergk.admin@gmail.com>");
MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL");







On Wed, Mar 2, 2016 at 11:06 PM, sergk sergk2mail <sergk.admin@gmail.com> wrote:
> Would like to add that specs are located
> https://gitlab.com/antruziliak/icn8528.git
> The main question - how to wake up chip.
> Looks that 2 gpios are used INT/WAKE + RST.
> Regards,
>                Serge Kolotylo.
>
> On Tue, Mar 1, 2016 at 10:07 AM, Gregor Riepl <onitake@gmail.com> wrote:
>>> 2) Could be icn8318 by Hans de Goede be adopted for icn85xx?
>>
>> chipone_icn8318.c lacks ACPI support. It may not be difficult to add though.
>>
>> The question is if both chips are sufficiently compatible.
>>
>>> how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?
>>
>> That sounds very odd. Perhaps they share the same control interface?
>> Or perhaps Chipone just cloned the Atmel chips...
>>
>> I'm pretty certain that a specific firmware is required for your chip, though.
>>

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi ALL,
Results of testing my code on Chuwi Vi10 rev11 with different
combinations of define
#TS_I2C_BUS  - i2c bus (i2c-dev)
#define TS_I2C_ADDR  - chip address on i2c bus
#define CTP_RST_PORT 393 - wakeup gpio. Actually have chosen 393
because it is the same as it was on Chuwi Vi8. Also may be for Chuwi
Vi10 could be used 391, 392 gpios. All 391-393 gpios by setting them
to 0 and then to 1 do the same - turn on\off screen.


Results of testing: dmesg output:
Procedure of testing: modprobe i2c-dev gpio && insmod myicn,ko

i2c-3 0x30:   (last lines looks strange like battery is resided on this address)


-- Logs begin at Thu 2016-03-10 17:49:10 UTC, end at Thu 2016-03-10
17:49:58 UTC. --
Mar 10 17:49:56 archiso kernel: device: 'i2c-0': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:i2c-0
Mar 10 17:49:56 archiso kernel: device: 'i2c-1': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:i2c-1
Mar 10 17:49:56 archiso kernel: device: 'i2c-2': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:i2c-2
Mar 10 17:49:56 archiso kernel: device: 'i2c-3': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:i2c-3
Mar 10 17:49:56 archiso kernel: device: 'i2c-4': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:i2c-4
Mar 10 17:49:56 archiso kernel: device class 'mtd': registering
Mar 10 17:49:56 archiso kernel: device: 'mtd': device_add
Mar 10 17:49:56 archiso kernel: PM: Adding info for No Bus:mtd
Mar 10 17:49:56 archiso kernel: bus: 'platform': add driver gpio-nand
Mar 10 17:49:57 archiso kernel:
                                INIT icn MODULE,func ts_init
                                 get pwr gpio in func ts_init
Mar 10 17:49:57 archiso kernel: ------------[ cut here ]------------
Mar 10 17:49:57 archiso kernel: WARNING: CPU: 2 PID: 714 at
drivers/pinctrl/intel/pinctrl-baytrail.c:214
byt_gpio_request+0xaf/0xe0()
Mar 10 17:49:57 archiso kernel: Modules linked in: myicn(O+) gpio nand
nand_ecc nand_ids mtd i2c_dev intel_rapl intel_soc_dts_thermal
intel_soc_dts_iosf intel_powerclamp iTCO_wdt iTCO_vendor_support
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd
i915 brcmfmac uio_pdrv_genirq uio joydev cfg80211 i2c_algo_bit
input_leds rfkill drm_kms_helper brcmutil efi_pstore
snd_intel_sst_acpi snd_intel_sst_core snd_soc_sst_mfld_platform
efivars drm pcspkr dw_dmac dw_dmac_core snd_soc_core snd_compress
evdev myicn_ts_acpi(O) intel_gtt kxcjk_1013 i2c_hid snd_pcm_dmaengine
industrialio_triggered_buffer mei_txe kfifo_buf syscopyarea
sysfillrect snd_pcm industrialio mei sysimgblt tpm_tis snd_timer snd
lpc_ich battery fb_sys_fops tpm i2c_designware_platform
Mar 10 17:49:57 archiso kernel:  i2c_designware_core ac acpi_pad
soundcore spi_pxa2xx_platform i2c_core snd_soc_sst_acpi processor
thermal 8250_dw sch_fq_codel nfs lockd grace sunrpc fscache ip_tables
x_tables overlay squashfs isofs nls_iso8859_1 nls_cp437 vfat fat
sd_mod hid_generic usbhid hid uas usb_storage scsi_mod xhci_pci
xhci_hcd usbcore crc32c_intel usb_common button serio wmi video
sdhci_acpi sdhci led_class loop
Mar 10 17:49:57 archiso kernel: CPU: 2 PID: 714 Comm: insmod Tainted:
G        W  O    4.4.2-2-ARCH #2
Mar 10 17:49:57 archiso kernel: Hardware name: ilife S165/BYT-PF02,
BIOS J1D_S165C_206 10/29/2014
Mar 10 17:49:57 archiso kernel:  0000000000000000 00000000bde94ada
ffff8800736efb68 ffffffff812b324b
Mar 10 17:49:57 archiso kernel:  0000000000000000 ffff8800736efba0
ffffffff8105dc53 ffffc9000036a0f0
Mar 10 17:49:57 archiso kernel:  ffff88007c056e18 000000000000000b
0000000000000002 ffff88007c056f20
Mar 10 17:49:57 archiso kernel: Call Trace:
Mar 10 17:49:57 archiso kernel:  [<ffffffff812b324b>] dump_stack+0x4b/0x70
Mar 10 17:49:57 archiso kernel:  [<ffffffff8105dc53>]
warn_slowpath_common+0x83/0xc0
Mar 10 17:49:57 archiso kernel:  [<ffffffff8105ddab>]
warn_slowpath_null+0x1b/0x20
Mar 10 17:49:57 archiso kernel:  [<ffffffff812e683f>] byt_gpio_request+0xaf/0xe0
Mar 10 17:49:57 archiso kernel:  [<ffffffffa00d8000>] ? 0xffffffffa00d8000
Mar 10 17:49:57 archiso kernel:  [<ffffffff812e7004>] __gpiod_request+0x74/0x100
Mar 10 17:49:57 archiso kernel:  [<ffffffff812e9dad>] gpiod_request+0x5d/0x100
Mar 10 17:49:57 archiso kernel:  [<ffffffff812e9101>] ? gpio_to_desc+0x91/0xe0
Mar 10 17:49:57 archiso kernel:  [<ffffffff812ea8c4>] gpio_request+0x34/0x40
Mar 10 17:49:57 archiso kernel:  [<ffffffffa00d803c>]
ts_init+0x3c/0x1000 [myicn]
Mar 10 17:49:57 archiso kernel:  [<ffffffff810003e2>] do_one_initcall+0xb2/0x1f0
Mar 10 17:49:57 archiso kernel:  [<ffffffff8118cd52>] ? __vunmap+0x92/0xf0
Mar 10 17:49:57 archiso kernel:  [<ffffffff811aabce>] ? kfree+0x14e/0x160
Mar 10 17:49:57 archiso kernel:  [<ffffffff8114966f>] do_init_module+0x5f/0x1f0
Mar 10 17:49:57 archiso kernel:  [<ffffffff810e7d01>] load_module+0x2231/0x28a0
Mar 10 17:49:57 archiso kernel:  [<ffffffff810e4b10>] ?
symbol_put_addr+0x50/0x50
Mar 10 17:49:57 archiso kernel:  [<ffffffff811cdec1>] ? kernel_read+0x51/0x80
Mar 10 17:49:57 archiso kernel:  [<ffffffff810e85cd>] SyS_finit_module+0xbd/0xf0
Mar 10 17:49:57 archiso kernel:  [<ffffffff8157a217>]
entry_SYSCALL_64_fastpath+0x12/0x66
Mar 10 17:49:57 archiso kernel: ---[ end trace dcb1f480a2bec481 ]---
Mar 10 17:49:57 archiso kernel: byt_gpio INT33FC:01: pin 11 forcibly
re-configured as GPIO
Mar 10 17:49:58 archiso kernel: ==icn85xx ts_init 280 at i2cbus: 3!!!!!!!!
Mar 10 17:49:58 archiso kernel: device: '3-0030': device_add
Mar 10 17:49:58 archiso kernel: bus: 'i2c': add device 3-0030
Mar 10 17:49:58 archiso kernel: PM: Adding info for i2c:3-0030
Mar 10 17:49:58 archiso kernel: bus: 'i2c': add driver chipone-ts
Mar 10 17:49:58 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 3-0030 with driver chipone-ts
Mar 10 17:49:58 archiso kernel: bus: 'i2c': really_probe: probing
driver chipone-ts with device 3-0030
Mar 10 17:49:58 archiso kernel: chipone-ts 3-0030: no default pinctrl state
Mar 10 17:49:58 archiso kernel: devices_kset: Moving 3-0030 to end of list
Mar 10 17:49:58 archiso kernel:
                                hello from i2cprobe,icn85xx_ts_probe
                                ====icn85xx_ts_probe begin=====.
Mar 10 17:49:58 archiso kernel:
                                begin icn85xx_iic_test
                                 BEGIN test another way of reading CurrFW ver
                                 CurrFW ver=43360
                                 END test another way of reading
CurrFW verFrom icn85xx_read_reg -  addr: 0xa: 0x42
Mar 10 17:49:58 archiso kernel:
                                Begin read fw ver from iictestFrom
icn85xx_read_reg -  addr: 0xc: 0x7
Mar 10 17:49:58 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestFrom
icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 17:49:58 archiso kernel:
                                End read IC subver from iictestiic
test error! 1 in icn85xx_iic_test
Mar 10 17:49:58 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x11
Mar 10 17:49:58 archiso kernel:
                                Begin read fw ver from iictestFrom
icn85xx_read_reg -  addr: 0xc: 0x28
Mar 10 17:49:58 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestFrom
icn85xx_read_reg -  addr: 0xb: 0x8
Mar 10 17:49:58 archiso kernel:
                                End read IC subver from iictestiic
test error! 2 in icn85xx_iic_test
Mar 10 17:49:58 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x4a
Mar 10 17:49:58 archiso kernel:
                                Begin read fw ver from iictestFrom
icn85xx_read_reg -  addr: 0xc: 0x74
Mar 10 17:49:58 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestFrom
icn85xx_read_reg -  addr: 0xb: 0x4
Mar 10 17:49:58 archiso kernel:
                                End read IC subver from iictestiic
test error! 3 in icn85xx_iic_test
Mar 10 17:49:58 archiso kernel:
                                end icn85xx_iic_testiic communication ok: 0x0
Mar 10 17:49:58 archiso kernel:
                                Bye from i2cprobe,icn85xx_ts_probe
Mar 10 17:49:58 archiso kernel: driver: 'chipone-ts': driver_bound:
bound to device '3-0030'
Mar 10 17:49:58 archiso kernel: bus: 'i2c': really_probe: bound device
3-0030 to driver chipone-ts
Mar 10 17:49:58 archiso kernel: PM: Moving acpi:PNP0C0A:01 to end of list
Mar 10 17:49:58 archiso kernel: acpi PNP0C0A:01: Retrying from deferred list
Mar 10 17:49:58 archiso kernel: bus: 'acpi': driver_probe_device:
matched device PNP0C0A:01 with driver battery
Mar 10 17:49:58 archiso kernel: bus: 'acpi': really_probe: probing
driver battery with device PNP0C0A:01
Mar 10 17:49:58 archiso kernel: battery PNP0C0A:01: no default pinctrl state
Mar 10 17:49:58 archiso kernel: devices_kset: Moving PNP0C0A:01 to end of list
Mar 10 17:49:58 archiso kernel: acpi PNP0C0A:01: Driver battery
requests probe deferral

-----------------
i2c-4 0x48  - this is etalon because Android and Windows using these
params!!! And :( failed to probe!
-----------------

Mar 10 20:53:53 archiso kernel: i2c /dev entries driver
Mar 10 20:53:53 archiso kernel: device class 'i2c-dev': registering
Mar 10 20:53:53 archiso kernel: device: 'i2c-0': device_add
Mar 10 20:53:53 archiso kernel: PM: Adding info for No Bus:i2c-0
Mar 10 20:53:53 archiso kernel: device: 'i2c-1': device_add
Mar 10 20:53:53 archiso kernel: PM: Adding info for No Bus:i2c-1
Mar 10 20:53:53 archiso kernel: device: 'i2c-2': device_add
Mar 10 20:53:53 archiso kernel: PM: Adding info for No Bus:i2c-2
Mar 10 20:53:53 archiso kernel: device: 'i2c-3': device_add
Mar 10 20:53:53 archiso kernel: PM: Adding info for No Bus:i2c-3
Mar 10 20:53:53 archiso kernel: device: 'i2c-4': device_add
Mar 10 20:53:53 archiso kernel: PM: Adding info for No Bus:i2c-4
Mar 10 20:53:55 archiso kernel: device class 'mtd': registering
Mar 10 20:53:55 archiso kernel: device: 'mtd': device_add
Mar 10 20:53:55 archiso kernel: PM: Adding info for No Bus:mtd
Mar 10 20:53:55 archiso kernel: bus: 'platform': add driver gpio-nand
Mar 10 20:53:58 archiso kernel:
                                INIT icn MODULE,func ts_init
                                 get pwr gpio in func ts_init
Mar 10 20:53:58 archiso kernel: ------------[ cut here ]------------
Mar 10 20:53:58 archiso kernel: WARNING: CPU: 2 PID: 696 at
drivers/pinctrl/intel/pinctrl-baytrail.c:214
byt_gpio_request+0xaf/0xe0()
Mar 10 20:53:58 archiso kernel: Modules linked in: myicn(O+) gpio nand
nand_ecc nand_ids mtd i2c_dev intel_rapl intel_soc_dts_thermal
intel_soc_dts_iosf intel_powerclamp iTCO_wdt coretemp
iTCO_vendor_support kvm_intel brcmfmac i915 kvm cfg80211 irqbypass
crct10dif_pclmul crc32_pclmul i2c_algo_bit aesni_intel aes_x86_64
joydev lrw rfkill gf128mul input_leds efi_pstore brcmutil glue_helper
ablk_helper drm_kms_helper uio_pdrv_genirq efivars uio cryptd pcspkr
myicn_ts_acpi(O) drm kxcjk_1013 industrialio_triggered_buffer
kfifo_buf thermal i2c_hid evdev industrialio snd_intel_sst_acpi
dw_dmac snd_intel_sst_core snd_soc_sst_mfld_platform dw_dmac_core
battery intel_gtt mei_txe syscopyarea sysfillrect sysimgblt
fb_sys_fops i2c_designware_platform snd_soc_core snd_compress
snd_pcm_dmaengine ac acpi_pad tpm_tis snd_pcm tpm spi_pxa2xx_platform
Mar 10 20:53:58 archiso kernel:  lpc_ich i2c_designware_core mei
snd_timer snd i2c_core processor soundcore 8250_dw snd_soc_sst_acpi
sch_fq_codel nfs lockd grace sunrpc fscache ip_tables x_tables overlay
squashfs isofs nls_iso8859_1 nls_cp437 vfat fat sd_mod hid_generic
usbhid hid uas usb_storage scsi_mod xhci_pci xhci_hcd usbcore
crc32c_intel usb_common button serio video wmi sdhci_acpi sdhci
led_class loop
Mar 10 20:53:58 archiso kernel: CPU: 2 PID: 696 Comm: insmod Tainted:
G        W  O    4.4.2-2-ARCH #2
Mar 10 20:53:58 archiso kernel: Hardware name: ilife S165/BYT-PF02,
BIOS J1D_S165C_206 10/29/2014
Mar 10 20:53:58 archiso kernel:  0000000000000000 00000000deb7bf9d
ffff88007799fb68 ffffffff812b324b
Mar 10 20:53:58 archiso kernel:  0000000000000000 ffff88007799fba0
ffffffff8105dc53 ffffc9000036a0f0
Mar 10 20:53:58 archiso kernel:  ffff88007c056e18 000000000000000b
0000000000000002 ffff88007c056f20
Mar 10 20:53:58 archiso kernel: Call Trace:
Mar 10 20:53:58 archiso kernel:  [<ffffffff812b324b>] dump_stack+0x4b/0x70
Mar 10 20:53:58 archiso kernel:  [<ffffffff8105dc53>]
warn_slowpath_common+0x83/0xc0
Mar 10 20:53:58 archiso kernel:  [<ffffffff8105ddab>]
warn_slowpath_null+0x1b/0x20
Mar 10 20:53:58 archiso kernel:  [<ffffffff812e683f>] byt_gpio_request+0xaf/0xe0
Mar 10 20:53:58 archiso kernel:  [<ffffffffa002a000>] ? 0xffffffffa002a000
Mar 10 20:53:58 archiso kernel:  [<ffffffff812e7004>] __gpiod_request+0x74/0x100
Mar 10 20:53:58 archiso kernel:  [<ffffffff812e9dad>] gpiod_request+0x5d/0x100
Mar 10 20:53:58 archiso kernel:  [<ffffffff812e9101>] ? gpio_to_desc+0x91/0xe0
Mar 10 20:53:58 archiso kernel:  [<ffffffff812ea8c4>] gpio_request+0x34/0x40
Mar 10 20:53:58 archiso kernel:  [<ffffffffa002a03c>]
ts_init+0x3c/0x1000 [myicn]
Mar 10 20:53:58 archiso kernel:  [<ffffffff810003e2>] do_one_initcall+0xb2/0x1f0
Mar 10 20:53:58 archiso kernel:  [<ffffffff8114966f>] do_init_module+0x5f/0x1f0
Mar 10 20:53:58 archiso kernel:  [<ffffffff810e7d01>] load_module+0x2231/0x28a0
Mar 10 20:53:58 archiso kernel:  [<ffffffff810e4b10>] ?
symbol_put_addr+0x50/0x50
Mar 10 20:53:58 archiso kernel:  [<ffffffff811cdec1>] ? kernel_read+0x51/0x80
Mar 10 20:53:58 archiso kernel:  [<ffffffff810e85cd>] SyS_finit_module+0xbd/0xf0
Mar 10 20:53:58 archiso kernel:  [<ffffffff8157a217>]
entry_SYSCALL_64_fastpath+0x12/0x66
Mar 10 20:53:58 archiso kernel: ---[ end trace 50506b677151cf1f ]---
Mar 10 20:53:58 archiso kernel: byt_gpio INT33FC:01: pin 11 forcibly
re-configured as GPIO
Mar 10 20:53:59 archiso kernel: ==icn85xx ts_init 280 at i2cbus: 4!!!!!!!!
Mar 10 20:53:59 archiso kernel: device: '4-0048': device_add
Mar 10 20:53:59 archiso kernel: bus: 'i2c': add device 4-0048
Mar 10 20:53:59 archiso kernel: PM: Adding info for i2c:4-0048
Mar 10 20:53:59 archiso kernel: bus: 'i2c': add driver chipone-ts
Mar 10 20:53:59 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 4-0048 with driver chipone-ts
Mar 10 20:53:59 archiso kernel: bus: 'i2c': really_probe: probing
driver chipone-ts with device 4-0048
Mar 10 20:53:59 archiso kernel: chipone-ts 4-0048: no default pinctrl state
Mar 10 20:53:59 archiso kernel: devices_kset: Moving 4-0048 to end of list
Mar 10 20:53:59 archiso kernel:
                                hello from i2cprobe,icn85xx_ts_probe
                                ====icn85xx_ts_probe begin=====.
Mar 10 20:53:59 archiso kernel:
                                begin icn85xx_iic_test
                                 BEGIN test another way of reading
CurrFW verfrom icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel:
                                 CurrFW ver=0
                                 END test another way of reading
CurrFW verfrom icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 20:53:59 archiso kernel:
                                Begin read fw ver from iictestFrom
icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read IC subver from iictestiic
test error! 1 in icn85xx_iic_test
Mar 10 20:53:59 archiso kernel: from icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 20:53:59 archiso kernel:
                                Begin read fw ver from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read IC subver from iictestiic
test error! 2 in icn85xx_iic_test
Mar 10 20:53:59 archiso kernel: from icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 20:53:59 archiso kernel:
                                Begin read fw ver from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 20:53:59 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 20:53:59 archiso kernel:
                                End read IC subver from iictestiic
test error! 3 in icn85xx_iic_test
Mar 10 20:53:59 archiso kernel:
                                end icn85xx_iic_testfunc
icn85xx_ts_probe: icn85xx_iic_test  failed.
Mar 10 20:53:59 archiso kernel: chipone-ts: probe of 4-0048 failed with error -1

-----
i2c-4, 0x30 - just as written in ACPI DSDT - again failed
-----
-- Logs begin at Thu 2016-03-10 21:03:40 UTC, end at Thu 2016-03-10
21:04:41 UTC. --
Mar 10 21:04:39 archiso kernel: i2c /dev entries driver
Mar 10 21:04:39 archiso kernel: device class 'i2c-dev': registering
Mar 10 21:04:39 archiso kernel: device: 'i2c-0': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:i2c-0
Mar 10 21:04:39 archiso kernel: device: 'i2c-1': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:i2c-1
Mar 10 21:04:39 archiso kernel: device: 'i2c-2': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:i2c-2
Mar 10 21:04:39 archiso kernel: device: 'i2c-3': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:i2c-3
Mar 10 21:04:39 archiso kernel: device: 'i2c-4': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:i2c-4
Mar 10 21:04:39 archiso kernel: device class 'mtd': registering
Mar 10 21:04:39 archiso kernel: device: 'mtd': device_add
Mar 10 21:04:39 archiso kernel: PM: Adding info for No Bus:mtd
Mar 10 21:04:39 archiso kernel: bus: 'platform': add driver gpio-nand
Mar 10 21:04:40 archiso kernel:
                                INIT icn MODULE,func ts_init
                                 get pwr gpio in func ts_init
Mar 10 21:04:40 archiso kernel: ------------[ cut here ]------------
Mar 10 21:04:40 archiso kernel: WARNING: CPU: 3 PID: 703 at
drivers/pinctrl/intel/pinctrl-baytrail.c:214
byt_gpio_request+0xaf/0xe0()
Mar 10 21:04:40 archiso kernel: Modules linked in: myicn(O+) gpio nand
nand_ecc nand_ids mtd i2c_dev iTCO_wdt iTCO_vendor_support intel_rapl
intel_soc_dts_thermal intel_soc_dts_iosf intel_powerclamp coretemp
kvm_intel kvm brcmfmac i915 irqbypass crct10dif_pclmul crc32_pclmul
joydev input_leds cfg80211 i2c_algo_bit aesni_intel aes_x86_64 lrw
gf128mul drm_kms_helper glue_helper rfkill ablk_helper brcmutil drm
cryptd snd_intel_sst_acpi uio_pdrv_genirq snd_intel_sst_core
efi_pstore uio snd_soc_sst_mfld_platform pcspkr efivars intel_gtt
snd_soc_core snd_compress snd_pcm_dmaengine thermal snd_pcm evdev
dw_dmac myicn_ts_acpi(O) dw_dmac_core syscopyarea kxcjk_1013
industrialio_triggered_buffer mei_txe spi_pxa2xx_platform sysfillrect
kfifo_buf i2c_hid sysimgblt battery industrialio snd_timer acpi_pad ac
mei lpc_ich fb_sys_fops
Mar 10 21:04:40 archiso kernel:  snd tpm_tis 8250_dw tpm processor
i2c_designware_platform i2c_designware_core soundcore snd_soc_sst_acpi
i2c_core sch_fq_codel nfs lockd grace sunrpc fscache ip_tables
x_tables overlay squashfs isofs nls_iso8859_1 nls_cp437 vfat fat
sd_mod hid_generic usbhid hid uas usb_storage scsi_mod xhci_pci
xhci_hcd usbcore crc32c_intel usb_common button serio wmi video
sdhci_acpi sdhci led_class loop
Mar 10 21:04:40 archiso kernel: CPU: 3 PID: 703 Comm: insmod Tainted:
G        W  O    4.4.2-2-ARCH #2
Mar 10 21:04:40 archiso kernel: Hardware name: ilife S165/BYT-PF02,
BIOS J1D_S165C_206 10/29/2014
Mar 10 21:04:40 archiso kernel:  0000000000000000 000000001e8b0650
ffff880073abbb68 ffffffff812b324b
Mar 10 21:04:40 archiso kernel:  0000000000000000 ffff880073abbba0
ffffffff8105dc53 ffffc9000036a0f0
Mar 10 21:04:40 archiso kernel:  ffff88007c066e18 000000000000000b
0000000000000002 ffff88007c066f20
Mar 10 21:04:40 archiso kernel: Call Trace:
Mar 10 21:04:40 archiso kernel:  [<ffffffff812b324b>] dump_stack+0x4b/0x70
Mar 10 21:04:40 archiso kernel:  [<ffffffff8105dc53>]
warn_slowpath_common+0x83/0xc0
Mar 10 21:04:40 archiso kernel:  [<ffffffff8105ddab>]
warn_slowpath_null+0x1b/0x20
Mar 10 21:04:40 archiso kernel:  [<ffffffff812e683f>] byt_gpio_request+0xaf/0xe0
Mar 10 21:04:40 archiso kernel:  [<ffffffffa0059000>] ? 0xffffffffa0059000
Mar 10 21:04:40 archiso kernel:  [<ffffffff812e7004>] __gpiod_request+0x74/0x100
Mar 10 21:04:40 archiso kernel:  [<ffffffff812e9dad>] gpiod_request+0x5d/0x100
Mar 10 21:04:40 archiso kernel:  [<ffffffff812e9101>] ? gpio_to_desc+0x91/0xe0
Mar 10 21:04:40 archiso kernel:  [<ffffffff812ea8c4>] gpio_request+0x34/0x40
Mar 10 21:04:40 archiso kernel:  [<ffffffffa005903c>]
ts_init+0x3c/0x1000 [myicn]
Mar 10 21:04:40 archiso kernel:  [<ffffffff810003e2>] do_one_initcall+0xb2/0x1f0
Mar 10 21:04:40 archiso kernel:  [<ffffffff8114966f>] do_init_module+0x5f/0x1f0
Mar 10 21:04:40 archiso kernel:  [<ffffffff810e7d01>] load_module+0x2231/0x28a0
Mar 10 21:04:40 archiso kernel:  [<ffffffff810e4b10>] ?
symbol_put_addr+0x50/0x50
Mar 10 21:04:40 archiso kernel:  [<ffffffff811cdec1>] ? kernel_read+0x51/0x80
Mar 10 21:04:40 archiso kernel:  [<ffffffff810e85cd>] SyS_finit_module+0xbd/0xf0
Mar 10 21:04:40 archiso kernel:  [<ffffffff8157a217>]
entry_SYSCALL_64_fastpath+0x12/0x66
Mar 10 21:04:40 archiso kernel: ---[ end trace c17ab1bcd4ba3d1e ]---
Mar 10 21:04:40 archiso kernel: byt_gpio INT33FC:01: pin 11 forcibly
re-configured as GPIO
Mar 10 21:04:41 archiso kernel: ==icn85xx ts_init 280 at i2cbus: 4!!!!!!!!
Mar 10 21:04:41 archiso kernel: device: '4-0030': device_add
Mar 10 21:04:41 archiso kernel: bus: 'i2c': add device 4-0030
Mar 10 21:04:41 archiso kernel: PM: Adding info for i2c:4-0030
Mar 10 21:04:41 archiso kernel: bus: 'i2c': add driver chipone-ts
Mar 10 21:04:41 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 4-0030 with driver chipone-ts
Mar 10 21:04:41 archiso kernel: bus: 'i2c': really_probe: probing
driver chipone-ts with device 4-0030
Mar 10 21:04:41 archiso kernel: chipone-ts 4-0030: no default pinctrl state
Mar 10 21:04:41 archiso kernel: devices_kset: Moving 4-0030 to end of list
Mar 10 21:04:41 archiso kernel:
                                hello from i2cprobe,icn85xx_ts_probe
                                ====icn85xx_ts_probe begin=====.
Mar 10 21:04:41 archiso kernel:
                                begin icn85xx_iic_test
                                 BEGIN test another way of reading
CurrFW verfrom icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel:
                                 CurrFW ver=0
                                 END test another way of reading
CurrFW verfrom icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 21:04:41 archiso kernel:
                                Begin read fw ver from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read IC subver from iictestiic
test error! 1 in icn85xx_iic_test
Mar 10 21:04:41 archiso kernel: from icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 21:04:41 archiso kernel:
                                Begin read fw ver from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read IC subver from iictestiic
test error! 2 in icn85xx_iic_test
Mar 10 21:04:41 archiso kernel: from icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xa: 0x0
Mar 10 21:04:41 archiso kernel:
                                Begin read fw ver from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xc: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read fw ver from iictest
                                Begin read IC subver  from iictestfrom
icn85xx_i2c_rxdata: i2c read error: -121
Mar 10 21:04:41 archiso kernel: From icn85xx_read_reg -  addr: 0xb: 0x0
Mar 10 21:04:41 archiso kernel:
                                End read IC subver from iictestiic
test error! 3 in icn85xx_iic_test
Mar 10 21:04:41 archiso kernel:
                                end icn85xx_iic_testfunc
icn85xx_ts_probe: icn85xx_iic_test  failed.
Mar 10 21:04:41 archiso kernel: chipone-ts: probe of 4-0030 failed with error -1

Re: Chipone icn85xx support in x86 linux kernel

[Gregor Riepl]

>  1) It is strange, but it looks that via Vanilla custom x8_64 Linux
> 4.4.2 ArchLinux   Baytrail on Chuwi Vi10 the Touchscreen Control Chip
> probably resides not on 0x48  and it is resides on i2c-3 0x30. This
> confused me completely, AFAIK chip could switch buses but not its
> address.
> Will be happy if anyone helps with this - whether it is possible for
> chip to be i2c-4, 0x48 on Android and switched in Linux to i2c-3 0x30?

The way I2C works, this is simply not possible unless the chip is reconfigured
somehow. I2C frames always start with the device address, and if a chip isn't
listening for a specific address (or a broadcast), it will not respond.

The I2C bus number in user space on the other hand is completely dynamic and
depends on the driver load order.

So in short, without any separate "switching" mechanism (highly unlikely), the
device will always have the same address (0x30 is 48 in decimal, mind you),
but it may live on i2c-0, i2c-1, i2c-2, i2c-3, i2c-4, i2c-5 depending on when
the bus is initialised or which drivers are loaded.

> Also my discovering:
> 1.1)  On Chuwi Vi8 for gsl1680 it was only such Android: i2c-4, 0x40
> and in Linux: i2c-3, 0x40 - only bus! But not address switching!

Are you sure this is the TS controller and not a different device?

> 2) I have not got positive results with my code - and still under
> guessing whether I am not successful in waking up the chip or
> something other wrong. :( I could not even read correct Chip version
> in checking whether hw initialized correct.

Perhaps there's more initialisation needed. Have a look at the _PS0/_PS3
methods in the DSDT. Those are usually meant for automatic power management
when the system exits/enters standby.
Perhaps the icn85 is still in sleep mode?

> It is sad but Linux in contrast to Android has a lack of drivers for
> touchscreen and many other hw of the tablets and this is to my mind is
> very strange and reminding early times of 2.xx kernel. ;-) I am trying
> to join and change this situation!

That is sad indeed. There wasn't much support for touchscreens in Linux before
tablets became so widespread, and most manufacturers just cared about "getting
things working". Many Android drivers out in the wild don't even use
DeviceTree for hardware configuration, instead relying on proprietary blobs or
hardcoded data in the driver code. Messed up ACPI tables aren't improving the
situation either.

Thanks to the effort of the fine people here on linux-input however, the
situation is getting better. :)
But it will take time.

Re: Chipone icn85xx support in x86 linux kernel

[Dmitry Torokhov]

On Thu, Mar 10, 2016 at 1:59 PM, Gregor Riepl <onitake@gmail.com> wrote:
>>  1) It is strange, but it looks that via Vanilla custom x8_64 Linux
>> 4.4.2 ArchLinux   Baytrail on Chuwi Vi10 the Touchscreen Control Chip
>> probably resides not on 0x48  and it is resides on i2c-3 0x30. This
>> confused me completely, AFAIK chip could switch buses but not its
>> address.
>> Will be happy if anyone helps with this - whether it is possible for
>> chip to be i2c-4, 0x48 on Android and switched in Linux to i2c-3 0x30?
>
> The way I2C works, this is simply not possible unless the chip is reconfigured
> somehow. I2C frames always start with the device address, and if a chip isn't
> listening for a specific address (or a broadcast), it will not respond.
>
> The I2C bus number in user space on the other hand is completely dynamic and
> depends on the driver load order.
>
> So in short, without any separate "switching" mechanism (highly unlikely), the
> device will always have the same address (0x30 is 48 in decimal, mind you),
> but it may live on i2c-0, i2c-1, i2c-2, i2c-3, i2c-4, i2c-5 depending on when
> the bus is initialised or which drivers are loaded.

Some devices do allow you to switch slave address, Goodix touchscreen
is one example.

Thanks.

-- 
Dmitry

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi Gregor,

"Perhaps there's more initialisation needed. Have a look at the _PS0/_PS3
methods in the DSDT. Those are usually meant for automatic power management
when the system exits/enters standby.
Perhaps the icn85 is still in sleep mode?"

I guess probably :( still yes not wake uped.
The key is - how to wake up?! I have provided link to specs
(unfortunately in Chines, but there is there also CN-EN google
translation in .odt)
https://gitlab.com/antruziliak/icn8528/tree/master/SPECS
Any ideas\information from community will be useful!

I see in https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
lines 49 - 55 for one of the platform variants of using kernel
consumer power regulator.

define CTP_POWER_ID ("sensor28")//("touchPannel_power")

tp_regulator = regulator_init(CTP_POWER_ID, CTP_POWER_MIN_VOL,
CTP_POWER_MAX_VOL); if ( !tp_regulator ) { // printk(KERN_ERR "icn85xx
tp init power failed"); err = -EINVAL; return err; }


The main question is - where to get regulator ID for linux baytrail?
In Android I see in sysfs 2 of them, will try to research trying both
later.

Dmitriy, Gregor:
regarding i2c bus address:
It is very strange but even in provided specs for example
https://gitlab.com/antruziliak/icn8528/blob/master/SPECS/Android%E5%B9%B3%E5%8F%B0%E4%B8%8BICN85XX%E9%A9%B1%E5%8A%A8%E7%A7%BB%E6%A4%8D%E8%AF%B4%E6%98%8E%E4%B9%A61.0.doc

is mentioned 0x40
but in https://gitlab.com/antruziliak/icn8528/blob/master/SPECS/ICNT88xx_Application%20note_CN_V1.0_20150330.pdf

is mentioned 0x48!

at the same time

https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN850X/icn85xx.h

#define ICN85XX_PROG_IIC_ADDR (0x30)

at the same time
https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c

static struct i2c_board_info tp_info = {
    .type    = CTP_NAME,
    .addr    =  0x48,
};


this makes me "crying crazy" = where is the chip located! Imagine that
I could not wake up it and not sure where is it located or should be
located! I have discovered that in Android it is resides on i2c-4,
0x48.
In Windows driver looks also 0x48 (not sure, trying to recheck,
unfortunately do not know at the moment how to inspect i2c bus under
windows 8).

In ACPI DSDT it is declared something regarding 0x30, but may be below
lines mean something other???


Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (RBUF, ResourceTemplate ()
                    {
                        I2cSerialBus (0x0030, ControllerInitiated, 0x00061A80,
                            AddressingMode7Bit, "\\_SB.I2C4",
                            0x00, ResourceConsumer, ,
                            )

 Device (TCS5)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "CHPN0001")  // _HID: Hardware ID
                Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus)
*/)  // _CID: Compatible ID
                Name (_S0W, Zero)  // _S0W: S0 Device Wake State
                Name (_DEP, Package (0x02)  // _DEP: Dependencies
                {
                    GPO1,
                    I2C5
                })
                Method (_PS3, 0, Serialized)  // _PS3: Power State 3
                {
                }

                Method (_PS0, 0, Serialized)  // _PS0: Power State 0
                {
                    If ((^^^GPO1.AVBL == One))
                    {
                        ^^^GPO1.TCD3 = Zero
                    }

                    Sleep (0x05)
                    If ((^^^I2C5.PMI1.AVBG == One))
                    {
                        ^^^I2C5.PMI1.TCON = One
                    }

                    Sleep (0x1E)
                    If ((^^^GPO1.AVBL == One))
                    {
                        ^^^GPO1.TCD3 = One
                    }

                    Sleep (0x78)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current
Resource Settings
                {
                    Name (RBUF, ResourceTemplate ()
                    {
                        I2cSerialBus (0x0030, ControllerInitiated, 0x00061A80,
                            AddressingMode7Bit, "\\_SB.I2C4",
                            0x00, ResourceConsumer, ,
                            )
                        Interrupt (ResourceConsumer, Level,
ActiveHigh, Exclusive, ,, )
                        {
                            0x00000044,
                        }
                        GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,


Regards,
                Serge Kolotylo.

Re: Chipone icn85xx support in x86 linux kernel

[Gregor Riepl]

> In ACPI DSDT it is declared something regarding 0x30, but may be below
> lines mean something other???
> 
> 
> Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>                 {
>                     Name (RBUF, ResourceTemplate ()
>                     {
>                         I2cSerialBus (0x0030, ControllerInitiated, 0x00061A80,
>                             AddressingMode7Bit, "\\_SB.I2C4",
>                             0x00, ResourceConsumer, ,
>                             )

In general, you should go with the values in the DSDT.
They may be wrong if the manufacturer messed up (it happens), but they are
your best bet. Remember, even the Windows driver needs to get the values
somewhere.

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi Gregor,
"In general, you should go with the values in the DSDT.
They may be wrong if the manufacturer messed up (it happens), but they are
your best bet. Remember, even the Windows driver needs to get the values
somewhere."

Thanks that you are here!
Suppose also that some one interested in Chipone icn8528 joint too!
Let me start from lyric goal - I could not believe that having working
touch in Android and Windows + some kind of specs + working drivers
and firmware it is not possible to make Chipone icn8528 working in
Linux.
Please someone comment whether I am mistaken in this or not?

Current :( bad news:



Bad news 1
- on Chuwi Vi10 standard method from kernel doc does NOT work :(

I2C serial bus support
~~~~~~~~~~~~~~~~~~~~~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
with the platform and SPI drivers. The I2C core automatically enumerates
any slave devices behind the controller device once the adapter is
registered.

Below is an example of how to add ACPI support to the existing mpu3050
input driver:

#ifdef CONFIG_ACPI
static const struct acpi_device_id mpu3050_acpi_match[] = {
{ "MPU3050", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match);
#endif

static struct i2c_driver mpu3050_i2c_driver = {
.driver = {
.name = "mpu3050",
.owner = THIS_MODULE,
.pm = &mpu3050_pm,
.of_match_table = mpu3050_of_match,
.acpi_match_table = ACPI_PTR(mpu3050_acpi_match),
},
.probe = mpu3050_probe,
.remove = mpu3050_remove,
.id_table = mpu3050_ids,
};

BAD NEWS 2:

Actually I am not sure if I have waked up chip, BUT at the same I am
stabile receive something on i2c-3 0x30.
This looks like in DSDT ACPI and by analogy with Chuwi vi8 again is a
shift on Baytrail -1 on i2cbus.
The problem is - why I am receiving each time different values for
reading the same addresses on i2c bus?
I mean if I read 0xa address (should be 0x85 - the major version of
the chip) - I receive each time new values but not 0x85! see my posts
with test results.

HOW IT COULD BE  POSSIBLE SO?


Under Windows driver has in its properties values from DSDT like
\\SB.I2c4 and etc.
:( unfrotrunately could not find working utility for Windows to scan
i2cbus and i2cdevices.

Also have read that modern devices could switch their addressed on i2cbus!

Also from android - the only TS module is loaded and present is
atmel_mxt_ts - nm g shows

nm -g atmel_mxt_ts.ko
         U __dynamic_dev_dbg
         U __gpio_set_value
         U __init_waitqueue_head
         U __kmalloc
00000000 D __mod_acpi_device_table
00000180 R __mod_i2c_device_table
         U __mutex_init
00000000 D __this_module
         U _dev_info
         U acpi_get_gpio_by_index
00000000 T cleanup_module
         U complete
         U dev_err
         U dev_get_drvdata
         U dev_set_drvdata
         U dev_warn
         U device_create_file
         U device_remove_file
         U disable_irq
         U enable_irq
         U free_irq
         U gpio_direction_output
         U gpio_export
         U gpio_free
         U gpio_request
         U gpio_set_value_cansleep
         U i2c_del_driver
         U i2c_master_send
         U i2c_register_driver
         U i2c_transfer
00000000 T init_module
         U input_alloc_absinfo
         U input_allocate_device
         U input_event
         U input_free_device
         U input_mt_init_slots
         U input_mt_report_pointer_emulation
         U input_mt_report_slot_state
         U input_register_device
         U input_set_abs_params
         U input_set_capability
         U input_unregister_device
         U kfree
         U kmalloc_caches
         U kmem_cache_alloc_trace
         U krealloc
         U mcount
         U memcpy
         U msecs_to_jiffies
         U msleep
         U mutex_lock
         U mutex_unlock
         U print_hex_dump
         U register_early_suspend
         U register_early_suspend_device
         U regulator_disable
         U regulator_enable
         U regulator_get
         U regulator_put
         U release_firmware
         U request_firmware
         U request_threaded_irq
         U scnprintf
         U snprintf
         U sprintf
         U sscanf
         U strlen
         U strncmp
00000040 D supported_panels
         U sysfs_create_bin_file
         U sysfs_create_group
         U sysfs_notify
         U sysfs_remove_bin_file
         U sysfs_remove_group
         U unregister_early_suspend_device
         U usleep_range
         U wait_for_completion_interruptible_timeout

Regards,
                  Serge Kolotylo.

Re: Chipone icn85xx support in x86 linux kernel

[Gregor Riepl]

> Actually I am not sure if I have waked up chip, BUT at the same I am
> stabile receive something on i2c-3 0x30.
> This looks like in DSDT ACPI and by analogy with Chuwi vi8 again is a
> shift on Baytrail -1 on i2cbus.
> The problem is - why I am receiving each time different values for
> reading the same addresses on i2c bus?
> I mean if I read 0xa address (should be 0x85 - the major version of
> the chip) - I receive each time new values but not 0x85! see my posts
> with test results.
> 
> HOW IT COULD BE  POSSIBLE SO?
>
> ...
> 
> Also from android - the only TS module is loaded and present is
> atmel_mxt_ts - nm g shows

Well.... Perhaps you have one of those Atmel maXTouch chips after all?

Have you looked inside your tablet to confirm this?

The mXT most likely has a different protocol/memory map than the icn85xx.
If you can find a data sheet, you may be able to read the respective
identification registers.

Also, keep in mind that a loaded module does not necessarily mean you have the
corresponding hardware. There could be a user space driver that handles touch
on Android.

Or perhaps... You have a totally different chip.
Are you sure that all icnxxxx devices use the same memory map?

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi Gregor, and ALL.

Good news - have created module that wake up chip and load in FW and
reads coordinates!
Could not at the moment setup IRQ.
Polling mode is possible! but have not yet tested it completely, also
some weird happens with reading y coordinate - instead reading from 0
to 768 it reads normally till something 2xx-3xx, then overflow then
again from 0 to 500. Anyway even with this it could be fixed just with
corelation received information based on current behaviour. X looks is
readed perfect (0 - 1366).

Will generate dedicated to IRQ and touch screen thread with result and question.

Regards,

                Serge Kolotylo.

On Sun, Mar 13, 2016 at 1:24 PM, Gregor Riepl <onitake@gmail.com> wrote:
>> Actually I am not sure if I have waked up chip, BUT at the same I am
>> stabile receive something on i2c-3 0x30.
>> This looks like in DSDT ACPI and by analogy with Chuwi vi8 again is a
>> shift on Baytrail -1 on i2cbus.
>> The problem is - why I am receiving each time different values for
>> reading the same addresses on i2c bus?
>> I mean if I read 0xa address (should be 0x85 - the major version of
>> the chip) - I receive each time new values but not 0x85! see my posts
>> with test results.
>>
>> HOW IT COULD BE  POSSIBLE SO?
>>
>> ...
>>
>> Also from android - the only TS module is loaded and present is
>> atmel_mxt_ts - nm g shows
>
> Well.... Perhaps you have one of those Atmel maXTouch chips after all?
>
> Have you looked inside your tablet to confirm this?
>
> The mXT most likely has a different protocol/memory map than the icn85xx.
> If you can find a data sheet, you may be able to read the respective
> identification registers.
>
> Also, keep in mind that a loaded module does not necessarily mean you have the
> corresponding hardware. There could be a user space driver that handles touch
> on Android.
>
> Or perhaps... You have a totally different chip.
> Are you sure that all icnxxxx devices use the same memory map?

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

Hi all,
At last I am releasing my icn85xx (tested on icn8528 on Chuwi Vi10,
Baytrail) kernel space driver.
It is unfortunately polling mode, but at the moment, I am happy with
it and have no enough time to dig in with irq mode.

https://gitlab.com/SergK/icn85xx/tree/master

My special thanks for their help to:
Gregor Riepl
Mika Westerberg
linux-input

PS: further contribution are welcome! And regarding irq I will reply
later, ;-) JavaEE steal me from linuxC world.

Kind regards,
                   Serge Kolotylo.

On Sun, Feb 14, 2016 at 11:03 PM, sergk sergk2mail
<sergk.admin@gmail.com> wrote:
> Hello All,
> Please advice whether it is supported touch screen icn85xx in anykind
> of x86 (baytrail interested in!) kernel?
>
> I have discovered in Vanilla chipone_icn8318.c  kernel driver from Hans de Goede
> but this driver in contrast to arm available icn83xx.c looks really
> strange, it is even excluded from Kconfig by default in 4.4.1: it has
> no firmware load while at the same time android driver
> https://android.googlesource.com/kernel/bcm/+/android-bcm-tetra-3.10-lollipop-wear-release/drivers/input/touchscreen/icn83xx.c
> has.
> Also for rtk3128 chip there is!  icn85xx driver:
> https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
>
> I am trying to make it working my touch on Chuwi Vi10 (Baytrail
> Z3536), Archlinux, custom 4.4.1 (from Vanilla) kernel.
> What I have discovered from Windows and Android: I2c address of TS is
> 0x48, in Android it is located under i2c-4 0x48
>
>>: cat /sys/bus/i2c/devices/i2c-4/4-0048/name
> chipone-icn85xx.
>
> Under windows 8.1 there is icnfirmware.sys for it. (;-) no need to
> grab it!), fw also present in .h file of rtk3128 github repo.
> GPIO pin I have guessing to enable TS is 393 (stupid looking over all
> gpios via sysfs and enabling each to 1).
>
> So my farther additional questions are:
>
> 2) Could be icn8318 by Hans de Goede be adopted for icn85xx?
> 3) Looks currently kernel is not supported ACPII for icn85xx
> 4) Please advice how to (if possible) having windows and android with
> working touch to grab all needed information for makes device working
> with kernel (gpio pins).
> 5) In Windows driver is myi2c.sys and reports that this is chipone ts,
> in Android is loaded atmel_mxt_ts module and the most strange thing
> afrer rmmod touch is working.
> dmesg under android shows: input: chipone-ts as /devices/virtual/input/input5.
> modalis: input:b0000v0000p0000-e0,1,3,k8b,9e,d9,ra2f,30,32,35,36,39,m1sfw
> how it is possible to use atmel_mxt_ts module for chipone? or what is the trick?
>
> Thanks in advance,
>       hope together we will make it working under x86!
> Regards,
>                  Serge Kolotylo.

Re: Chipone icn85xx support in x86 linux kernel

[Gregor Riepl]

> At last I am releasing my icn85xx (tested on icn8528 on Chuwi Vi10,
> Baytrail) kernel space driver.
> It is unfortunately polling mode, but at the moment, I am happy with
> it and have no enough time to dig in with irq mode.
> 
> https://gitlab.com/SergK/icn85xx/tree/master

Good work!

A few comments - but bear in mind that I'm not an experienced kernel
developer. Someone else may be able to give better advice.

First: Patches to the kernel should be submitted according to these guidelines
at https://www.kernel.org/doc/Documentation/SubmittingPatches
In particular, a new driver should be a patch against the respective kernel
branch, which means it should live in the appropriate directory in the kernel
tree and include an addendum to the Kconfig/Makefile there. Standalone
Makefiles are nice when building drivers out-of-tree, but they are not
suitable for kernel code. This doesn't apply to your development repo, of
course. Testing may be easier when a driver can be built standalone.

Second: The patch should be formatted according to the Linux kernel coding
style at https://www.kernel.org/doc/Documentation/CodingStyle
There's also the checkpatch.pl utility in the kernel tree that can help you
find and fix mistakes.

But don't be discouraged by the lenghty guides - it's not that hard and
checkpatch helps a lot.

One thing I noticed on a quick glance is that line 833 in your code is
redundant. kzalloc aready clears the memory (hence, k_z_alloc).

Also: I highly recommend using devm_ variants of constructors, where
available. If you use those, you can reduce the footprint of your _remove()
function or even remove it completely. devm_input_allocate_device() is a good
example. You should use it instead of input_allocate_device(), and it will
take care of unregistering and deallocation automatically.

Re: Chipone icn85xx support in x86 linux kernel

[sergk sergk2mail]

"But don't be discouraged by the lenghty guides - it's not that hard and
checkpatch helps a lot."

Gregor, ,on the contrary ;-) u r welcome! My main goal with publishing
it - to do not waste time and waiting till one person finish
everything - join efforts in making icn85xx driver for x86.
My end goal also is more global - full linux on Chuwi Vi10, ;-) next
round sound ESSX8316.
Regards,
              Serge.

On Tue, May 3, 2016 at 11:35 PM, Gregor Riepl <onitake@gmail.com> wrote:
>> At last I am releasing my icn85xx (tested on icn8528 on Chuwi Vi10,
>> Baytrail) kernel space driver.
>> It is unfortunately polling mode, but at the moment, I am happy with
>> it and have no enough time to dig in with irq mode.
>>
>> https://gitlab.com/SergK/icn85xx/tree/master
>
> Good work!
>
> A few comments - but bear in mind that I'm not an experienced kernel
> developer. Someone else may be able to give better advice.
>
> First: Patches to the kernel should be submitted according to these guidelines
> at https://www.kernel.org/doc/Documentation/SubmittingPatches
> In particular, a new driver should be a patch against the respective kernel
> branch, which means it should live in the appropriate directory in the kernel
> tree and include an addendum to the Kconfig/Makefile there. Standalone
> Makefiles are nice when building drivers out-of-tree, but they are not
> suitable for kernel code. This doesn't apply to your development repo, of
> course. Testing may be easier when a driver can be built standalone.
>
> Second: The patch should be formatted according to the Linux kernel coding
> style at https://www.kernel.org/doc/Documentation/CodingStyle
> There's also the checkpatch.pl utility in the kernel tree that can help you
> find and fix mistakes.
>
> But don't be discouraged by the lenghty guides - it's not that hard and
> checkpatch helps a lot.
>
> One thing I noticed on a quick glance is that line 833 in your code is
> redundant. kzalloc aready clears the memory (hence, k_z_alloc).
>
> Also: I highly recommend using devm_ variants of constructors, where
> available. If you use those, you can reduce the footprint of your _remove()
> function or even remove it completely. devm_input_allocate_device() is a good
> example. You should use it instead of input_allocate_device(), and it will
> take care of unregistering and deallocation automatically.