How to use ACPI for touchscreen

How to use ACPI for touchscreen

[sergk sergk2mail]

Hi ALL,
Please help or reference with the following:

Howto use ACPI for touchscreen:

  1) is it possible to detect via ACPI GPIO pin to INT/WAKE Touch?
   2) If yes how to find out equivalent of this gpio pin in
/sys/class/gpio? (to have userspace interface to it via export
gpioPINNUMBER> /sys/class/gpio/export
3) From the bellow DSDT table touch is dependant from I2C5  while
i2c-dev creates devices i2c-0...i2c-4. Does this mean that in ACPI
base is 1 and I2C5 is identical to i2c-4 dev ?


As input additional info - I have decoded under 4.4.2 vanilla kernel
x86_64 the following DSDT:
touch related area: (chipone icn 8528).

          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)
                    }
                }
            }
        }


  Device (GPO1)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "INT33FC" /* Intel Baytrail GPIO Controller
*/)  // _HID: Hardware ID
            Name (_CID, "INT33FC" /* Intel Baytrail GPIO Controller
*/)  // _CID: Compatible ID
            Name (_DDN, "ValleyView GPNCORE controller")  // _DDN: DOS
Device Name
            Name (_UID, 0x02)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    Memory32Fixed (ReadWrite,
                        0xFED0D000,         // Address Base
                        0x00001000,         // Address Length
                        )
                    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000030,
                    }
                })
                Return (RBUF) /* \_SB_.GPO1._CRS.RBUF */
            }

            Name (AVBL, Zero)
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If ((Arg0 == 0x08))
                {
                    AVBL = Arg1
                }
            }

            OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
            Field (GPOP, ByteAcc, NoLock, Preserve)
            {
                Connection (
                    GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly,
                        "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                        )
                        {   // Pin list
                            0x000F
                        }
                ),
                BST5,   1,
                Connection (
                    GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly,
                        "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                        )
                        {   // Pin list
                            0x001A
                        }
                ),
                TCD3,   1
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }
        }

Kind regards,
                     Serge Kolotylo.

Re: How to use ACPI for touchscreen

[Gregor Riepl]

Hi Serge,

> Howto use ACPI for touchscreen:
>
>   1) is it possible to detect via ACPI GPIO pin to INT/WAKE Touch?
>    2) If yes how to find out equivalent of this gpio pin in
> /sys/class/gpio? (to have userspace interface to it via export
> gpioPINNUMBER> /sys/class/gpio/export
> 3) From the bellow DSDT table touch is dependant from I2C5  while
> i2c-dev creates devices i2c-0...i2c-4. Does this mean that in ACPI
> base is 1 and I2C5 is identical to i2c-4 dev ?

In a kernel driver, you don't have to do all of this yourself, as the kernel
will take care of ACPI parsing and device configuration when you request it.

If your driver lives in user space, you need to do this mapping yourself.

This is all the relevant information:

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

Device on I2C address 0x30 (with 7-bit addressing), on I2C controller I2C4
(not I2C5, I believe this dependency is a bug in the DSDT entry of many
touchscreen devices), speed 400kHz.
One IRQ line (pin number 0x44), high level triggered. This maps directly to
the physical pin on Baytrail AFAIK. I'm not sure how to access it from user
space. Perhaps GPIO works, and perhaps it's not needed at all if you do polling.
One output GPIO pin, number 0x1a on GPO1 with default pullup settings. This is
most likely the "wakeup" pin on the controller.

I don't quite remember how the GPIO pin mapping works on Baytrail. Usually,
each "chip" has a base pin number, and the pin number from the DSDT entry is
added to that. Maybe check all /sys/class/gpio/gpiochip*/label entries and see
if you can find GPO1? You can then map the logical pin number (base + 0x1a)
using /sys/class/gpio/export

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Hi Gregor,

Thanks for joining!
Unfortunately DSDT was taken from my Chuwi Vi10 tablet rev 11 with
Chipone icn8528.h touch and information provided via ACPI looks like a
total false.
I have compared DSDTs on both Android and Linux 4.4.2  - they are lie
both and are the same.
Touch is located in Android on i2c-4, 0x48 (exactly as it is mentioned
in the specs I have sent to you).
In Android I am able to read via i2cget -f (force because is used by
ts driver in Adroid) 4 0x48 main registers of icn85xx, for example:
i2cget -f 4 0x048 0x000c FW version returns 0x38
i2cget -f 4 0x048 0x000a IcVersion main - returns 0x85 = 85xx family

The additional strange things are: in Android is loaded only
atmel_mxt_ts which even could be rmmod and touch still working! no
any other module relative to touch! Looks someone just modified
atmel_mxt_ts and used it as a stub for initializing chip, loads
firmware and switch to it = no need module.

In Bios for touch there is option I2c Touch address field with
Options: Auto/0x4a, 0x4b. By default is Auto.

This makes me completely crazy hot this all works together while wrong
DSDT ACPI, strange options in BIOS.
Actually Chuwi Vi10 has 11 revisions, so thats why possibly there are
rudiment settings not relative to actual HW that is used.

So, the question still interesting - I exactly know which touch I have
and on which i2c bus and address (based on Android and Windows working
on it) and we have wrong? DSDT - how to obtain something to wakeup the
chip!
According spec: there are 2 methods: INT/WAKE pin or something weird
for me - SCL SDA and delays between them as it is described in
ICNT88xx_Application note spec.
In userspace I have just done enumerating all via exporting and
probing: 391-392-393 - is TS relative (blank on/off) and by analogy
with Chuwi Vi8 my experience - 393 is the same gpio to wakeup TS on
Chuwi vi8.
Simpe set 0-1 of 393 pin doesnot make i2cdetect -r -y 4  permanently
something on 0x48 - it sometimes detects sometimes not and I am unable
to read via mentioned above i2cget -f 4 0x048 0x000a nothing.
So looks like chip is not wake uped.

Kind regards,
                       Serge Kolotylo.

On Tue, Mar 1, 2016 at 10:02 AM, Gregor Riepl <onitake@gmail.com> wrote:
> Hi Serge,
>
>> Howto use ACPI for touchscreen:
>>
>>   1) is it possible to detect via ACPI GPIO pin to INT/WAKE Touch?
>>    2) If yes how to find out equivalent of this gpio pin in
>> /sys/class/gpio? (to have userspace interface to it via export
>> gpioPINNUMBER> /sys/class/gpio/export
>> 3) From the bellow DSDT table touch is dependant from I2C5  while
>> i2c-dev creates devices i2c-0...i2c-4. Does this mean that in ACPI
>> base is 1 and I2C5 is identical to i2c-4 dev ?
>
> In a kernel driver, you don't have to do all of this yourself, as the kernel
> will take care of ACPI parsing and device configuration when you request it.
>
> If your driver lives in user space, you need to do this mapping yourself.
>
> This is all the relevant information:
>
>>                        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
>>                             }
>>
>
> Device on I2C address 0x30 (with 7-bit addressing), on I2C controller I2C4
> (not I2C5, I believe this dependency is a bug in the DSDT entry of many
> touchscreen devices), speed 400kHz.
> One IRQ line (pin number 0x44), high level triggered. This maps directly to
> the physical pin on Baytrail AFAIK. I'm not sure how to access it from user
> space. Perhaps GPIO works, and perhaps it's not needed at all if you do polling.
> One output GPIO pin, number 0x1a on GPO1 with default pullup settings. This is
> most likely the "wakeup" pin on the controller.
>
> I don't quite remember how the GPIO pin mapping works on Baytrail. Usually,
> each "chip" has a base pin number, and the pin number from the DSDT entry is
> added to that. Maybe check all /sys/class/gpio/gpiochip*/label entries and see
> if you can find GPO1? You can then map the logical pin number (base + 0x1a)
> using /sys/class/gpio/export
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

In addition this touch is used like so:

dmesg | grep chipone:
<6> : input: chipone-ts as /devices/virtual/input/input3
cat /devices/virtual/input/input3/modalias gives

input:b000v0000p0000e0000-e0,1,3,k8B,9E,D9,ra2F,30,32,35,36,39,m1sfw
- I guess the key is m1sfw which means loaded firmware.
Kind regards,
                      Serge Kolotylo.

On Tue, Mar 1, 2016 at 4:30 PM, sergk sergk2mail <sergk.admin@gmail.com> wrote:
> Hi Gregor,
>
> Thanks for joining!
> Unfortunately DSDT was taken from my Chuwi Vi10 tablet rev 11 with
> Chipone icn8528.h touch and information provided via ACPI looks like a
> total false.
> I have compared DSDTs on both Android and Linux 4.4.2  - they are lie
> both and are the same.
> Touch is located in Android on i2c-4, 0x48 (exactly as it is mentioned
> in the specs I have sent to you).
> In Android I am able to read via i2cget -f (force because is used by
> ts driver in Adroid) 4 0x48 main registers of icn85xx, for example:
> i2cget -f 4 0x048 0x000c FW version returns 0x38
> i2cget -f 4 0x048 0x000a IcVersion main - returns 0x85 = 85xx family
>
> The additional strange things are: in Android is loaded only
> atmel_mxt_ts which even could be rmmod and touch still working! no
> any other module relative to touch! Looks someone just modified
> atmel_mxt_ts and used it as a stub for initializing chip, loads
> firmware and switch to it = no need module.
>
> In Bios for touch there is option I2c Touch address field with
> Options: Auto/0x4a, 0x4b. By default is Auto.
>
> This makes me completely crazy hot this all works together while wrong
> DSDT ACPI, strange options in BIOS.
> Actually Chuwi Vi10 has 11 revisions, so thats why possibly there are
> rudiment settings not relative to actual HW that is used.
>
> So, the question still interesting - I exactly know which touch I have
> and on which i2c bus and address (based on Android and Windows working
> on it) and we have wrong? DSDT - how to obtain something to wakeup the
> chip!
> According spec: there are 2 methods: INT/WAKE pin or something weird
> for me - SCL SDA and delays between them as it is described in
> ICNT88xx_Application note spec.
> In userspace I have just done enumerating all via exporting and
> probing: 391-392-393 - is TS relative (blank on/off) and by analogy
> with Chuwi Vi8 my experience - 393 is the same gpio to wakeup TS on
> Chuwi vi8.
> Simpe set 0-1 of 393 pin doesnot make i2cdetect -r -y 4  permanently
> something on 0x48 - it sometimes detects sometimes not and I am unable
> to read via mentioned above i2cget -f 4 0x048 0x000a nothing.
> So looks like chip is not wake uped.
>
> Kind regards,
>                        Serge Kolotylo.
>
> On Tue, Mar 1, 2016 at 10:02 AM, Gregor Riepl <onitake@gmail.com> wrote:
>> Hi Serge,
>>
>>> Howto use ACPI for touchscreen:
>>>
>>>   1) is it possible to detect via ACPI GPIO pin to INT/WAKE Touch?
>>>    2) If yes how to find out equivalent of this gpio pin in
>>> /sys/class/gpio? (to have userspace interface to it via export
>>> gpioPINNUMBER> /sys/class/gpio/export
>>> 3) From the bellow DSDT table touch is dependant from I2C5  while
>>> i2c-dev creates devices i2c-0...i2c-4. Does this mean that in ACPI
>>> base is 1 and I2C5 is identical to i2c-4 dev ?
>>
>> In a kernel driver, you don't have to do all of this yourself, as the kernel
>> will take care of ACPI parsing and device configuration when you request it.
>>
>> If your driver lives in user space, you need to do this mapping yourself.
>>
>> This is all the relevant information:
>>
>>>                        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
>>>                             }
>>>
>>
>> Device on I2C address 0x30 (with 7-bit addressing), on I2C controller I2C4
>> (not I2C5, I believe this dependency is a bug in the DSDT entry of many
>> touchscreen devices), speed 400kHz.
>> One IRQ line (pin number 0x44), high level triggered. This maps directly to
>> the physical pin on Baytrail AFAIK. I'm not sure how to access it from user
>> space. Perhaps GPIO works, and perhaps it's not needed at all if you do polling.
>> One output GPIO pin, number 0x1a on GPO1 with default pullup settings. This is
>> most likely the "wakeup" pin on the controller.
>>
>> I don't quite remember how the GPIO pin mapping works on Baytrail. Usually,
>> each "chip" has a base pin number, and the pin number from the DSDT entry is
>> added to that. Maybe check all /sys/class/gpio/gpiochip*/label entries and see
>> if you can find GPO1? You can then map the logical pin number (base + 0x1a)
>> using /sys/class/gpio/export
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Hi Gregor,

Have modified (remove all besides i2c and acpi + added CHPN0001 ACPI)
from your gsl680 driver.
Main goal - to verify what is getting from ACPI for my touchChipone
icn8528 and next step add here mentioned in linux-sunxi wakeuping
procedure for the chip.


The only thing I have receive from loading it with debug option to kernel:

insmod ./myicn_ts_acpi.ko
bus: 'i2c: add driver CHPN001.

I have not received "hello from probe_ts_probe".

So, my questions are:

1) Am I right when I am registering i2c client  mentioned in .probe
function should be called immediately ?
2) how to ensure and output all info that was taken from ACPI, as
minimum i2cbus number and address,
    irq
3) how to ensure that gpios are taken? from where was taken name
"power" for gpio?  Why exactly the name "power" ?    Looks also like I
need one more gpio that is "reset".
4) How will be created i2c-dev ? is this should be done by kernel
automatically? I mean there is no any direct creation of device on
predefined i2c-bus at predefined address.

Regards,
                Serge Kolotylo.



/*
    Playing with GSL1680 by "Gregor Riepl <onitake@gmail.com>"
 */

#include <linux/module.h>
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/delay.h>
#include <linux/firmware.h>
#include <linux/input/mt.h>
#include <linux/acpi.h>
#include <linux/of.h>
#include <linux/gpio/consumer.h>
#include <linux/version.h>

/* Device and driver information */
#define DEVICE_NAME    "CHPN001"
#define DRIVER_VERSION    "0.0.1"
#define GSL_PWR_GPIO "power"


/* Hardware API constants */
enum gsl_ts_state {
    GSL_TS_INIT,
    GSL_TS_SHUTDOWN,
    GSL_TS_GREEN,
};

/* Driver instance data structure */
struct gsl_ts_data {
    struct i2c_client *client;
    struct input_dev *input;
    struct gpio_desc *gpio;

    enum gsl_ts_state state;

    bool wake_irq_enabled;

    unsigned int x_max;
    unsigned int y_max;
    unsigned int multi_touches;
    bool x_reversed;
    bool y_reversed;
    bool xy_swapped;
    bool soft_tracking;
    int jitter;
    int deadzone;
};




#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
static const struct acpi_gpio_params gsl_ts_power_gpio = { 0, 0, true };
static const struct acpi_gpio_mapping gsl_ts_acpi_gpios[] = {
    { "power-gpio", &gsl_ts_power_gpio, 1 },
    { },
};
#endif

static int gsl_ts_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
    printk("Hello from probe_ts_probe");
    struct gsl_ts_data *ts;
    unsigned long irqflags;
    int error;

    dev_warn(&client->dev, "%s: got a device named %s at address 0x%x,
IRQ %d, flags 0x%x\n", __func__, client->name, client->addr,
client->irq, client->flags);

    if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
        dev_err(&client->dev, "%s: i2c check functionality error\n", __func__);
        return -ENXIO;
    }

    if (client->irq <= 0) {
        dev_err(&client->dev, "%s: missing IRQ configuration\n", __func__);
        return -ENODEV;
    }

    ts = devm_kzalloc(&client->dev, sizeof(struct gsl_ts_data), GFP_KERNEL);
    if (!ts) {
        return -ENOMEM;
    }

    ts->client = client;
    i2c_set_clientdata(client, ts);

#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
    /* Set up ACPI device descriptor GPIO name mappings.
        * This is a fallback, it will only be used if the system does not
        * provide a corresponding _DSD entry.
        */
    error = acpi_dev_add_driver_gpios(ACPI_COMPANION(&client->dev),
gsl_ts_acpi_gpios);
    if (error < 0) {
        dev_warn(&client->dev, "%s: failed to register GPIO names,
continuing anyway\n", __func__);
    }
#endif

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
    ts->gpio = devm_gpiod_get(&client->dev, GSL_PWR_GPIO);
#else
    ts->gpio = devm_gpiod_get(&client->dev, GSL_PWR_GPIO, GPIOD_OUT_LOW);
#endif
    if (IS_ERR(ts->gpio)) {
        dev_err(&client->dev, "%s: error obtaining power pin GPIO
resource\n", __func__);
        error = PTR_ERR(ts->gpio);
        goto release_gpios;
    }
#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
    error = gpiod_direction_output(ts->gpio, 0);
    if (error < 0) {
        dev_err(&client->dev, "%s: error setting GPIO pin
direction\n", __func__);
        goto release_gpios;
    }
#endif

    if (ACPI_COMPANION(&client->dev)) {
        /* Wake the device up with a power on reset */
        error = acpi_bus_set_power(ACPI_HANDLE(&client->dev), ACPI_STATE_D3);
        if (error == 0) {
            error = acpi_bus_set_power(ACPI_HANDLE(&client->dev),
ACPI_STATE_D0);
        }
        if (error) {
            dev_err(&client->dev, "%s: failed to wake up device
through ACPI: %d, continuting anyway\n", __func__, error);
        }
    }


    ts->input = devm_input_allocate_device(&client->dev);
    if (!ts->input) {
        dev_err(&client->dev, "%s: failed to allocate input device\n",
__func__);
        error = -ENOMEM;
        goto release_fw;
    }

    ts->input->name = "chipone_icn85xx Touchscreen";
    ts->input->id.bustype = BUS_I2C;
    ts->input->phys = "input/ts";

    input_set_capability(ts->input, EV_ABS, ABS_X);
    input_set_capability(ts->input, EV_ABS, ABS_Y);

    input_set_abs_params(ts->input, ABS_MT_POSITION_X, 0, ts->x_max,
ts->jitter, ts->deadzone);
    input_set_abs_params(ts->input, ABS_MT_POSITION_Y, 0, ts->y_max,
ts->jitter, ts->deadzone);

    input_mt_init_slots(ts->input, ts->multi_touches, INPUT_MT_DIRECT
| INPUT_MT_DROP_UNUSED | INPUT_MT_TRACK);

    input_set_drvdata(ts->input, ts);

    error = input_register_device(ts->input);
    if (error) {
        dev_err(&client->dev, "%s: unable to register input device:
%d\n", __func__, error);
        goto release_fw;
    }

    /* Execute the controller startup sequence */

    /*
     * Systems using device tree should set up wakeup via DTS,
     * the rest will configure device as wakeup source by default.
     */

release_fw:
//    if (fw) {
//        release_firmware(fw);
//    }

release_gpios:
    if (error < 0) {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
        acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
#endif

        return error;
    }
    return 0;
}

int gsl_ts_remove(struct i2c_client *client) {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
    acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
#endif
    return 0;
}


static const struct i2c_device_id gsl_ts_i2c_id[] = {
    { DEVICE_NAME, 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, gsl_ts_i2c_id);


#ifdef CONFIG_ACPI
/* GSL3680 ACPI IDs are untested */
static const struct acpi_device_id gsl_ts_acpi_match[] = {
    { "CHPN0001", 0 },
    { "PNP05C0", 0 },
    { "CHIPONE",0},
    { "ICN8528",0},
    { "ICN8500",0},
    { },
};
MODULE_DEVICE_TABLE(acpi, gsl_ts_acpi_match);
#endif

#ifdef CONFIG_OF
/* This should take care of OpenFirmware and DeviceTree instantiations,
 * but they're completely untested. Volunteers welcome.
 * Is anyone using DeviceTree with this touch screen at all?
 */
static const struct of_device_id gsl_ts_of_match[] = {
    { .compatible = "chipone,icn85xx" },
    { .compatible = "chipone,icn8528" },
    { .compatible = "chipone,icn8500" },
    { }
};
MODULE_DEVICE_TABLE(of, gsl_ts_of_match);
#endif

static struct i2c_driver gslx680_ts_driver = {
    .probe = gsl_ts_probe,
    .remove = gsl_ts_remove,
    .id_table = gsl_ts_i2c_id,
    .driver = {
        .name = DEVICE_NAME,
        .owner = THIS_MODULE,
#ifdef CONFIG_ACPI
        .acpi_match_table = ACPI_PTR(gsl_ts_acpi_match),
#endif
#ifdef CONFIG_OF
        .of_match_table = of_match_ptr(gsl_ts_of_match),
#endif
    },
};
module_i2c_driver(gslx680_ts_driver);

MODULE_DESCRIPTION("MyICN touchscreen controller driver");
MODULE_AUTHOR("Gregor Riepl <onitake@gmail.com> & Serge Kolotylo
sergk.admin@gmail.com>");
MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL");

On Tue, Mar 1, 2016 at 10:02 AM, Gregor Riepl <onitake@gmail.com> wrote:
> Hi Serge,
>
>> Howto use ACPI for touchscreen:
>>
>>   1) is it possible to detect via ACPI GPIO pin to INT/WAKE Touch?
>>    2) If yes how to find out equivalent of this gpio pin in
>> /sys/class/gpio? (to have userspace interface to it via export
>> gpioPINNUMBER> /sys/class/gpio/export
>> 3) From the bellow DSDT table touch is dependant from I2C5  while
>> i2c-dev creates devices i2c-0...i2c-4. Does this mean that in ACPI
>> base is 1 and I2C5 is identical to i2c-4 dev ?
>
> In a kernel driver, you don't have to do all of this yourself, as the kernel
> will take care of ACPI parsing and device configuration when you request it.
>
> If your driver lives in user space, you need to do this mapping yourself.
>
> This is all the relevant information:
>
>>                        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
>>                             }
>>
>
> Device on I2C address 0x30 (with 7-bit addressing), on I2C controller I2C4
> (not I2C5, I believe this dependency is a bug in the DSDT entry of many
> touchscreen devices), speed 400kHz.
> One IRQ line (pin number 0x44), high level triggered. This maps directly to
> the physical pin on Baytrail AFAIK. I'm not sure how to access it from user
> space. Perhaps GPIO works, and perhaps it's not needed at all if you do polling.
> One output GPIO pin, number 0x1a on GPO1 with default pullup settings. This is
> most likely the "wakeup" pin on the controller.
>
> I don't quite remember how the GPIO pin mapping works on Baytrail. Usually,
> each "chip" has a base pin number, and the pin number from the DSDT entry is
> added to that. Maybe check all /sys/class/gpio/gpiochip*/label entries and see
> if you can find GPO1? You can then map the logical pin number (base + 0x1a)
> using /sys/class/gpio/export
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to use ACPI for touchscreen

[Gregor Riepl]

> So, my questions are:
> 
> 1) Am I right when I am registering i2c client  mentioned in .probe
> function should be called immediately ?

Please clarify: Are you trying to configure any i2c stuff from user space? You
shouldn't do that, as the kernel will take care of everything.

The probing procedure works like this, I believe:
- Module has an ACPI HID or OF/DT matching table
- Kernel finds an entry in the DSDT or DT
- Kernel loads module with corresponding entry (if not loaded)
or
- Module is loaded manually
- Kernel calls probe() with the preconfigured device structure
- probe() fetches i2c, gpio and irq information from device structure
- probe() configures gpio, irq handler, internal stuff and input devices
- probe() starts up the device
- probe() returns

If your probe routine isn't called, there may be a mismatch, or someone
claimed the device already. Try a reboot, perhaps.

> 2) how to ensure and output all info that was taken from ACPI, as
> minimum i2cbus number and address,
>     irq

You shouldn't have to worry about that.

This line should print all the interesting information:
>     dev_warn(&client->dev, "%s: got a device named %s at address 0x%x,
> IRQ %d, flags 0x%x\n", __func__, client->name, client->addr,
> client->irq, client->flags);
If it doesn't something may have gone wrong.

> 3) how to ensure that gpios are taken? from where was taken name
> "power" for gpio?  Why exactly the name "power" ?    Looks also like I
> need one more gpio that is "reset".

"power" is a name I gave to the wakeup pin. The DSDT does not contain named
GPIOs, and AFAIK direct use of unnamed GPIOs is deprecated.

> 4) How will be created i2c-dev ? is this should be done by kernel
> automatically? I mean there is no any direct creation of device on
> predefined i2c-bus at predefined address.

Yes, the kernel will take care of that whenever it finds a matching device.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Hi Gregor,
Thank you very much for clear explanation how it works,

Here is my results for my touch: in some sence positive but not so perfect :(
Sequence of actions in console:
no boot with module, compile module then copy to /lib/modules/KVER && depmod -a
modprobe i2c-dev
modprobe gpio
echo icn8528 0x48 > /sys/bus/i2c/devices/i2c-4/newdevice
After this kernel automatically loads myicn_ts_acpi.ko module.

Result is the following:

Mar 02 12:07:31 archiso kernel: i2c i2c-4: new_device: Instantiated
device CHPN0001 at 0x48
Mar 02 12:07:31 archiso kernel: bus: 'i2c': add driver CHPN0001
Mar 02 12:07:31 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 4-0048 with driver CHPN0001
Mar 02 12:07:31 archiso kernel: bus: 'i2c': really_probe: probing
driver CHPN0001 with device 4-0048
Mar 02 12:07:31 archiso kernel: icn8528 4-0048: no default pinctrl state
Mar 02 12:07:31 archiso kernel: devices_kset: Moving 4-0048 to end of list
Mar 02 12:07:31 archiso kernel: Hello from probe_ts_probe
Mar 02 12:07:31 archiso kernel: icn8528 4-0048: probe info:
gsl_ts_probe: got a device named icn8528 at address 0x48, IRQ 0, flags
0x0
Mar 02 12:07:31 archiso kernel: icn8528 4-0048: gsl_ts_probe: missing
IRQ configuration
Mar 02 12:07:31 archiso kernel: icn8528: probe of 4-0048 rejects match -19


So, based on main line output: archiso kernel: CHPN0001 4-0048: probe
info: gsl_ts_probe: got a device named CHPN0001 at address 0x48, IRQ
0, flags 0x0

It looks that via ACPI no info is provided? No IRQ, no flags?



The code is the following: (ver 0.0.2 - added some debug printk).

/*
    Playing with GSL1680 by "Gregor Riepl <onitake@gmail.com>"
 */

#include <linux/module.h>
#include <linux/input.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/delay.h>
#include <linux/firmware.h>
#include <linux/input/mt.h>
#include <linux/acpi.h>
#include <linux/of.h>
#include <linux/gpio/consumer.h>
#include <linux/version.h>

/* Device and driver information */
#define DEVICE_NAME    "icn8528"
#define DRIVER_VERSION    "0.0.2"
#define GSL_PWR_GPIO "power"


/* Hardware API constants */
enum gsl_ts_state {
    GSL_TS_INIT,
    GSL_TS_SHUTDOWN,
    GSL_TS_GREEN,
};

/* Driver instance data structure */
struct gsl_ts_data {
    struct i2c_client *client;
    struct input_dev *input;
    struct gpio_desc *gpio;

    enum gsl_ts_state state;

    bool wake_irq_enabled;

    unsigned int x_max;
    unsigned int y_max;
    unsigned int multi_touches;
    bool x_reversed;
    bool y_reversed;
    bool xy_swapped;
    bool soft_tracking;
    int jitter;
    int deadzone;
};




#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
static const struct acpi_gpio_params gsl_ts_power_gpio = { 0, 0, true };
static const struct acpi_gpio_mapping gsl_ts_acpi_gpios[] = {
    { "power-gpio", &gsl_ts_power_gpio, 1 },
    { },
};
#endif

static int gsl_ts_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
    printk("Hello from probe_ts_probe");
    struct gsl_ts_data *ts;
    unsigned long irqflags;
    int error;

    dev_warn(&client->dev, "probe info: %s: got a device named %s at
address 0x%x, IRQ %d, flags 0x%x\n", __func__, client->name,
client->addr, client->irq, client->flags);

    if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
        dev_err(&client->dev, "%s: i2c check functionality error\n", __func__);
        return -ENXIO;
    }

    if (client->irq <= 0) {
        dev_err(&client->dev, "%s: missing IRQ configuration\n", __func__);
        return -ENODEV;
    }

    ts = devm_kzalloc(&client->dev, sizeof(struct gsl_ts_data), GFP_KERNEL);
    if (!ts) {
        return -ENOMEM;
    }

    ts->client = client;
    printk("%s, i2c_set_clientdata begin",__func__);
    i2c_set_clientdata(client, ts);
    printk("%s, i2c_set_clientdata end",__func__);

#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
    /* Set up ACPI device descriptor GPIO name mappings.
        * This is a fallback, it will only be used if the system does not
        * provide a corresponding _DSD entry.
        */
    error = acpi_dev_add_driver_gpios(ACPI_COMPANION(&client->dev),
gsl_ts_acpi_gpios);
    if (error < 0) {
        dev_warn(&client->dev, "%s: failed to register GPIO names,
continuing anyway\n", __func__);
    }
#endif

#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
    ts->gpio = devm_gpiod_get(&client->dev, GSL_PWR_GPIO);
#else
    ts->gpio = devm_gpiod_get(&client->dev, GSL_PWR_GPIO, GPIOD_OUT_LOW);
#endif
    if (IS_ERR(ts->gpio)) {
        dev_err(&client->dev, "%s: error obtaining power pin GPIO
resource\n", __func__);
        error = PTR_ERR(ts->gpio);
        goto release_gpios;
    }
#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
    error = gpiod_direction_output(ts->gpio, 0);
    if (error < 0) {
        dev_err(&client->dev, "%s: error setting GPIO pin
direction\n", __func__);
        goto release_gpios;
    }
#endif

    if (ACPI_COMPANION(&client->dev)) {
        /* Wake the device up with a power on reset */
        error = acpi_bus_set_power(ACPI_HANDLE(&client->dev), ACPI_STATE_D3);
        if (error == 0) {
            error = acpi_bus_set_power(ACPI_HANDLE(&client->dev),
ACPI_STATE_D0);
        }
        if (error) {
            dev_err(&client->dev, "%s: failed to wake up device
through ACPI: %d, continuting anyway\n", __func__, error);
        }
    }


    ts->input = devm_input_allocate_device(&client->dev);
    if (!ts->input) {
        dev_err(&client->dev, "%s: failed to allocate input device\n",
__func__);
        error = -ENOMEM;
        goto release_fw;
    }

    ts->input->name = "chipone_icn85xx Touchscreen";
    ts->input->id.bustype = BUS_I2C;
    ts->input->phys = "input/ts";

    input_set_capability(ts->input, EV_ABS, ABS_X);
    input_set_capability(ts->input, EV_ABS, ABS_Y);

    input_set_abs_params(ts->input, ABS_MT_POSITION_X, 0, ts->x_max,
ts->jitter, ts->deadzone);
    input_set_abs_params(ts->input, ABS_MT_POSITION_Y, 0, ts->y_max,
ts->jitter, ts->deadzone);

    input_mt_init_slots(ts->input, ts->multi_touches, INPUT_MT_DIRECT
| INPUT_MT_DROP_UNUSED | INPUT_MT_TRACK);

    input_set_drvdata(ts->input, ts);

    error = input_register_device(ts->input);
    if (error) {
        dev_err(&client->dev, "%s: unable to register input device:
%d\n", __func__, error);
        goto release_fw;
    }

    /* Execute the controller startup sequence */

    /*
     * Systems using device tree should set up wakeup via DTS,
     * the rest will configure device as wakeup source by default.
     */

release_fw:
//    if (fw) {
//        release_firmware(fw);
//    }

release_gpios:
    if (error < 0) {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
        acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
#endif

        return error;
    }
    return 0;
}

int gsl_ts_remove(struct i2c_client *client) {
printk("Hello from %s",__func__);
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)
    acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
#endif
    return 0;
}


static const struct i2c_device_id gsl_ts_i2c_id[] = {
    { DEVICE_NAME, 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, gsl_ts_i2c_id);


#ifdef CONFIG_ACPI
/* GSL3680 ACPI IDs are untested */
static const struct acpi_device_id gsl_ts_acpi_match[] = {
    { "CHPN0001", 0 },
    { "PNP05C0", 0 },
    { "CHIPONE",0},
    { "ICN8528",0},
    { "ICN8500",0},
    { },
};
MODULE_DEVICE_TABLE(acpi, gsl_ts_acpi_match);
#endif

#ifdef CONFIG_OF
/* This should take care of OpenFirmware and DeviceTree instantiations,
 * but they're completely untested. Volunteers welcome.
 * Is anyone using DeviceTree with this touch screen at all?
 */
static const struct of_device_id gsl_ts_of_match[] = {
    { .compatible = "chipone,icn85xx" },
    { .compatible = "chipone,icn8528" },
    { .compatible = "chipone,icn8500" },
    { }
};
MODULE_DEVICE_TABLE(of, gsl_ts_of_match);
#endif

static struct i2c_driver gslx680_ts_driver = {
    .probe = gsl_ts_probe,
    .remove = gsl_ts_remove,
    .id_table = gsl_ts_i2c_id,
    .driver = {
        .name = DEVICE_NAME,
        .owner = THIS_MODULE,
#ifdef CONFIG_ACPI
        .acpi_match_table = ACPI_PTR(gsl_ts_acpi_match),
#endif
#ifdef CONFIG_OF
        .of_match_table = of_match_ptr(gsl_ts_of_match),
#endif
    },
};
module_i2c_driver(gslx680_ts_driver);

MODULE_DESCRIPTION("MyICN touchscreen controller driver");
MODULE_AUTHOR("Gregor Riepl <onitake@gmail.com> & Serge Kolotylo
sergk.admin@gmail.com>");
MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL");


Kind regards,
                    Serge Kolotylo.

On Tue, Mar 1, 2016 at 10:56 PM, Gregor Riepl <onitake@gmail.com> wrote:
>> So, my questions are:
>>
>> 1) Am I right when I am registering i2c client  mentioned in .probe
>> function should be called immediately ?
>
> Please clarify: Are you trying to configure any i2c stuff from user space? You
> shouldn't do that, as the kernel will take care of everything.
>
> The probing procedure works like this, I believe:
> - Module has an ACPI HID or OF/DT matching table
> - Kernel finds an entry in the DSDT or DT
> - Kernel loads module with corresponding entry (if not loaded)
> or
> - Module is loaded manually
> - Kernel calls probe() with the preconfigured device structure
> - probe() fetches i2c, gpio and irq information from device structure
> - probe() configures gpio, irq handler, internal stuff and input devices
> - probe() starts up the device
> - probe() returns
>
> If your probe routine isn't called, there may be a mismatch, or someone
> claimed the device already. Try a reboot, perhaps.
>
>> 2) how to ensure and output all info that was taken from ACPI, as
>> minimum i2cbus number and address,
>>     irq
>
> You shouldn't have to worry about that.
>
> This line should print all the interesting information:
>>     dev_warn(&client->dev, "%s: got a device named %s at address 0x%x,
>> IRQ %d, flags 0x%x\n", __func__, client->name, client->addr,
>> client->irq, client->flags);
> If it doesn't something may have gone wrong.
>
>> 3) how to ensure that gpios are taken? from where was taken name
>> "power" for gpio?  Why exactly the name "power" ?    Looks also like I
>> need one more gpio that is "reset".
>
> "power" is a name I gave to the wakeup pin. The DSDT does not contain named
> GPIOs, and AFAIK direct use of unnamed GPIOs is deprecated.
>
>> 4) How will be created i2c-dev ? is this should be done by kernel
>> automatically? I mean there is no any direct creation of device on
>> predefined i2c-bus at predefined address.
>
> Yes, the kernel will take care of that whenever it finds a matching device.
>
>

Re: How to use ACPI for touchscreen

[Gregor Riepl]

> echo icn8528 0x48 > /sys/bus/i2c/devices/i2c-4/newdevice
> After this kernel automatically loads myicn_ts_acpi.ko module.
> 
> ...
>
> gsl_ts_probe: got a device named icn8528 at address 0x48, IRQ 0, flags
> 0x0
> Mar 02 12:07:31 archiso kernel: icn8528 4-0048: gsl_ts_probe: missing
> IRQ configuration
> Mar 02 12:07:31 archiso kernel: icn8528: probe of 4-0048 rejects match -19
> 
> So, based on main line output: archiso kernel: CHPN0001 4-0048: probe
> info: gsl_ts_probe: got a device named CHPN0001 at address 0x48, IRQ
> 0, flags 0x0
> 
> It looks that via ACPI no info is provided? No IRQ, no flags?

Umm... Ok, this seems a bit weird. Normally, you wouldn't create devices from
user space, as the kernel should automatically instantiate them when parsing
the DSDT or DT.

However, you got an ACPI name (CHPN0001), which leads me to conclude that some
interaction was going on.

Ok, now about the interrupt. The DSDT you posted previously contained this:

Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
                        {
                            0x00000044,
                        }

So the irq field should have been set. I don't really understand why this
wasn't the case, sorry.

I recommend you try to load the module without creating a device from user
space first. Either install the module and reboot or load the module manually.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

"Umm... Ok, this seems a bit weird. Normally, you wouldn't create devices from
user space, as the kernel should automatically instantiate them when parsing
the DSDT or DT."

Hi Gregor,

Probably I know the reason of this - I have taken chuwi vi8 with
gsl1680, after modprobe i2c-dev, i2cdetect -r 3  - detects gsl1680 on
0x40 PERMANENTLY! In Android touch is on i2c-4, but on the same
address.
AFAIK - i2c devices could switch bus number but not their port on bus,
this means that if you have chipone icn85xx it should answer on 0x48
on one of the i2c bus.
Am I right?

In case of Chuwi Vi10 with Chipone icn8528 situation with i2cdetect is
very very strange.
On kernels 4.4.2 and 4.0.1 - modprobe i2c-dev and then i2cdetect -r X
(1,2,3,4) does NOT!!!!!!!! Detect NOTHING permanently on 0x48 on any
bus!
This make me confused completely! To wake up something it should be
visible on i2c bus but it is NOT!

Regards,
                Serge Kolotylo.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

"However, you got an ACPI name (CHPN0001), which leads me to conclude that some
interaction was going on."

Hi, Gregor.
Unfortunately it is not so :(
In previous reply, version 0.0.2 - I have changed i2c dev name to icn8528.
I have added the module to the /lib/modules/KVER, with right depmod and booted.
The output is only - registering i2c drv: bus: 'i2c': add driver icn8528.

And again only manual! echo icn8528 0x48 >/sys/bus/devices/i2c-4/newdevice
is called probe_ts funct but output shows bad news:

Mar 02 15:45:06 archiso kernel: i2c i2c-4: new_device: Instantiated
device icn8528 at 0x48
Mar 02 15:45:06 archiso kernel: bus: 'i2c': add driver icn8528
Mar 02 15:45:06 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 4-0048 with driver icn8528
Mar 02 15:45:06 archiso kernel: bus: 'i2c': really_probe: probing
driver icn8528 with device 4-0048
Mar 02 15:45:06 archiso kernel: icn8528 4-0048: no default pinctrl state
Mar 02 15:45:06 archiso kernel: devices_kset: Moving 4-0048 to end of list
Mar 02 15:45:06 archiso kernel: Hello from probe_ts_probe
Mar 02 15:45:06 archiso kernel: icn8528 4-0048: probe info:
gsl_ts_probe: got a device named icn8528 at address 0x48, IRQ 0, flags
0x0
Mar 02 15:45:06 archiso kernel: icn8528 4-0048: gsl_ts_probe: missing
IRQ configuration
Mar 02 15:45:06 archiso kernel: icn8528: probe of 4-0048 rejects match -19.

Parameters it takes just from my manual creating of i2cdev through sysfs.

Kind regards,
                      Serge Kolotylo.

On Wed, Mar 2, 2016 at 1:07 PM, Gregor Riepl <onitake@gmail.com> wrote:
>> echo icn8528 0x48 > /sys/bus/i2c/devices/i2c-4/newdevice
>> After this kernel automatically loads myicn_ts_acpi.ko module.
>>
>> ...
>>
>> gsl_ts_probe: got a device named icn8528 at address 0x48, IRQ 0, flags
>> 0x0
>> Mar 02 12:07:31 archiso kernel: icn8528 4-0048: gsl_ts_probe: missing
>> IRQ configuration
>> Mar 02 12:07:31 archiso kernel: icn8528: probe of 4-0048 rejects match -19
>>
>> So, based on main line output: archiso kernel: CHPN0001 4-0048: probe
>> info: gsl_ts_probe: got a device named CHPN0001 at address 0x48, IRQ
>> 0, flags 0x0
>>
>> It looks that via ACPI no info is provided? No IRQ, no flags?
>
> Umm... Ok, this seems a bit weird. Normally, you wouldn't create devices from
> user space, as the kernel should automatically instantiate them when parsing
> the DSDT or DT.
>
> However, you got an ACPI name (CHPN0001), which leads me to conclude that some
> interaction was going on.
>
> Ok, now about the interrupt. The DSDT you posted previously contained this:
>
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, )
>                         {
>                             0x00000044,
>                         }
>
> So the irq field should have been set. I don't really understand why this
> wasn't the case, sorry.
>
> I recommend you try to load the module without creating a device from user
> space first. Either install the module and reboot or load the module manually.
>

Re: How to use ACPI for touchscreen

[Gregor Riepl]

> Probably I know the reason of this - I have taken chuwi vi8 with
> gsl1680, after modprobe i2c-dev, i2cdetect -r 3  - detects gsl1680 on
> 0x40 PERMANENTLY! In Android touch is on i2c-4, but on the same
> address.

The differing bus assignment by be caused by slightly different loading order
or DeviceTree or platform driver configurations.

> AFAIK - i2c devices could switch bus number but not their port on bus,
> this means that if you have chipone icn85xx it should answer on 0x48
> on one of the i2c bus.
> Am I right?

Yes, the device address is normally hardcoded into the device itself.
So, unless there is an internal register or a chip pin to change, it will
always be the same.
And since I2C addressing is standardised, the physical and logical addresses
are identical.

As mentioned above, the logical I2C bus number may change depending on certain
factors. The physical bus pins are still the same though.

> In case of Chuwi Vi10 with Chipone icn8528 situation with i2cdetect is
> very very strange.
> On kernels 4.4.2 and 4.0.1 - modprobe i2c-dev and then i2cdetect -r X
> (1,2,3,4) does NOT!!!!!!!! Detect NOTHING permanently on 0x48 on any
> bus!
> This make me confused completely! To wake up something it should be
> visible on i2c bus but it is NOT!

It's possible that the device simply doesn't answer until the wakeup pin has
turned it on. In the case of the Silead chips, I think they are already turned
on at system boot and stay on until they are shut down via PM commands.

So you definitely need to configure the GPIO pin, send the wakeup sequence,
and then you should be able to communicate with the chip.

Re: How to use ACPI for touchscreen

[Dmitry Torokhov]

On Tue, Mar 01, 2016 at 04:55:02PM +0000, sergk sergk2mail wrote:
> In addition this touch is used like so:
> 
> dmesg | grep chipone:
> <6> : input: chipone-ts as /devices/virtual/input/input3
> cat /devices/virtual/input/input3/modalias gives
> 
> input:b000v0000p0000e0000-e0,1,3,k8B,9E,D9,ra2F,30,32,35,36,39,m1sfw
> - I guess the key is m1sfw which means loaded firmware.

Why do you think that mlsfw in modalias string has anything to do with
loading firmware? I must have misunderstood your statement...

Thanks.

-- 
Dmitry

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

"Why do you think that mlsfw in modalias string has anything to do with
loading firmware? I must have misunderstood your statement..."

Hi Dmitriy,
  Its rather guessing based on such disovering: On Chuwi Vi10 rev 11
under Android the only touch related module that is loaded is
atmel_mxt_ts while I exactly know (and have firmware too) that in this
tablet there is Chipone icn8528.h.   (drivers from Windows + dmesg
provs this).
When you rmmod atmel_mxt_ts the touch still continues to work! I guess
someone just used atmel_mxt_ts probably as prototype for detecting
(wake uping) chip and loading its firmware and after - no need in any
module. According specs of Chipone icn85xx it looks that it even has
corresponding mode - to be initialized from firmware and work after
with it. It looks weird, but this is the clevest explanation that I
could provide - I never seen before such behaviour in Android when
there is no dedicated driver for touch screen.

In anyway - this is only curiousity, the main goal is simple - to
create a driver for icn85xx that wakeup it and loads firmware.
I have specs, I have firmware, there is for arm open source drivers
(including firmware in .h file):
https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c

Current problem - I could not wake up the chip to obtain its permanent
presence on i2c-bus.
Regards,
                Serge Kolotylo.

On Wed, Mar 2, 2016 at 5:52 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Mar 01, 2016 at 04:55:02PM +0000, sergk sergk2mail wrote:
>> In addition this touch is used like so:
>>
>> dmesg | grep chipone:
>> <6> : input: chipone-ts as /devices/virtual/input/input3
>> cat /devices/virtual/input/input3/modalias gives
>>
>> input:b000v0000p0000e0000-e0,1,3,k8B,9E,D9,ra2F,30,32,35,36,39,m1sfw
>> - I guess the key is m1sfw which means loaded firmware.
>
> Why do you think that mlsfw in modalias string has anything to do with
> loading firmware? I must have misunderstood your statement...
>
> Thanks.
>
> --
> Dmitry

Re: How to use ACPI for touchscreen

[Gregor Riepl]

> When you rmmod atmel_mxt_ts the touch still continues to work! I guess
> someone just used atmel_mxt_ts probably as prototype for detecting
> (wake uping) chip and loading its firmware and after - no need in any

It may simply be that the pin assignments are the same for these devices, i.e.
they use the same physical pin for controller wakeup. This wouldn't surprise
me at all.

And since the wakeup sequence is sent before actually communicating with the
device over I2C, it seems logical that the ChipOne wakes up and stays on after
the atmel_probe function has been called - even if probe fails afterwards.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Hi Gregor,

Actually if you look for the code of atmel_mxt_ts - all actions are in probe.
Also simple experimental like:
echo maxtouch 0x48 > /sys/bus/i2c/i2c-4/new_device
you got the same as in my case with modified your driver:

Mar 02 18:51:39 archiso kernel: device: '4-0048': device_add
Mar 02 18:51:39 archiso kernel: bus: 'i2c': add device 4-0048
Mar 02 18:51:39 archiso kernel: PM: Adding info for i2c:4-0048
Mar 02 18:51:39 archiso kernel: i2c i2c-4: new_device: Instantiated
device maxtouch at 0x48
Mar 02 18:51:39 archiso kernel: bus: 'i2c': add driver atmel_mxt_ts
Mar 02 18:51:39 archiso kernel: bus: 'i2c': driver_probe_device:
matched device 4-0048 with driver atmel_mxt_ts
Mar 02 18:51:39 archiso kernel: bus: 'i2c': really_probe: probing
driver atmel_mxt_ts with device 4-0048
Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: no default pinctrl state
Mar 02 18:51:39 archiso kernel: devices_kset: Moving 4-0048 to end of list
Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: No platform data specified
Mar 02 18:51:39 archiso kernel: atmel_mxt_ts: probe of 4-0048 faile

Regards,
                 Serge Kolotylo.

PS: it will be really good if here will be someone who is fluent in
Chinese and could directly read spec for Chipone and translate it to
us.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Sorry, have forgotten to mentione that after this i2cdetect -r 4
detects nothing on i2c-4 0x48.
Kind regards,
                        Serge Kolotylo.

On Wed, Mar 2, 2016 at 7:00 PM, sergk sergk2mail <sergk.admin@gmail.com> wrote:
> Hi Gregor,
>
> Actually if you look for the code of atmel_mxt_ts - all actions are in probe.
> Also simple experimental like:
> echo maxtouch 0x48 > /sys/bus/i2c/i2c-4/new_device
> you got the same as in my case with modified your driver:
>
> Mar 02 18:51:39 archiso kernel: device: '4-0048': device_add
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': add device 4-0048
> Mar 02 18:51:39 archiso kernel: PM: Adding info for i2c:4-0048
> Mar 02 18:51:39 archiso kernel: i2c i2c-4: new_device: Instantiated
> device maxtouch at 0x48
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': add driver atmel_mxt_ts
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': driver_probe_device:
> matched device 4-0048 with driver atmel_mxt_ts
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': really_probe: probing
> driver atmel_mxt_ts with device 4-0048
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: no default pinctrl state
> Mar 02 18:51:39 archiso kernel: devices_kset: Moving 4-0048 to end of list
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: No platform data specified
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts: probe of 4-0048 faile
>
> Regards,
>                  Serge Kolotylo.
>
> PS: it will be really good if here will be someone who is fluent in
> Chinese and could directly read spec for Chipone and translate it to
> us.

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Actually specs are located here https://gitlab.com/antruziliak/icn8528.git
Regards ,
                 Serge Kolotylo.

On Wed, Mar 2, 2016 at 7:00 PM, sergk sergk2mail <sergk.admin@gmail.com> wrote:
> Hi Gregor,
>
> Actually if you look for the code of atmel_mxt_ts - all actions are in probe.
> Also simple experimental like:
> echo maxtouch 0x48 > /sys/bus/i2c/i2c-4/new_device
> you got the same as in my case with modified your driver:
>
> Mar 02 18:51:39 archiso kernel: device: '4-0048': device_add
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': add device 4-0048
> Mar 02 18:51:39 archiso kernel: PM: Adding info for i2c:4-0048
> Mar 02 18:51:39 archiso kernel: i2c i2c-4: new_device: Instantiated
> device maxtouch at 0x48
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': add driver atmel_mxt_ts
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': driver_probe_device:
> matched device 4-0048 with driver atmel_mxt_ts
> Mar 02 18:51:39 archiso kernel: bus: 'i2c': really_probe: probing
> driver atmel_mxt_ts with device 4-0048
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: no default pinctrl state
> Mar 02 18:51:39 archiso kernel: devices_kset: Moving 4-0048 to end of list
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts 4-0048: No platform data specified
> Mar 02 18:51:39 archiso kernel: atmel_mxt_ts: probe of 4-0048 faile
>
> Regards,
>                  Serge Kolotylo.
>
> PS: it will be really good if here will be someone who is fluent in
> Chinese and could directly read spec for Chipone and translate it to
> us.

Re: How to use ACPI for touchscreen

[Dmitry Torokhov]

On Wed, Mar 02, 2016 at 06:13:27PM +0000, sergk sergk2mail wrote:
> "Why do you think that mlsfw in modalias string has anything to do with
> loading firmware? I must have misunderstood your statement..."
> 
> Hi Dmitriy,
>   Its rather guessing based on such disovering: On Chuwi Vi10 rev 11
> under Android the only touch related module that is loaded is
> atmel_mxt_ts while I exactly know (and have firmware too) that in this
> tablet there is Chipone icn8528.h.   (drivers from Windows + dmesg
> provs this).
> When you rmmod atmel_mxt_ts the touch still continues to work! I guess
> someone just used atmel_mxt_ts probably as prototype for detecting
> (wake uping) chip and loading its firmware and after - no need in any
> module. According specs of Chipone icn85xx it looks that it even has
> corresponding mode - to be initialized from firmware and work after
> with it. It looks weird, but this is the clevest explanation that I
> could provide - I never seen before such behaviour in Android when
> there is no dedicated driver for touch screen.

I find this hard to believe. If you inspect /proc/bus/input/devices you
should be able to see the parent device for the touchscreen (via sysfs
entry) and if you inspect sysfs you should be able to see the driver
that is connected to the device (unless they use i2c dev from userspace
but then they'd have to resort to polling and their battery life would
be abysmal).

> 
> In anyway - this is only curiousity, the main goal is simple - to
> create a driver for icn85xx that wakeup it and loads firmware.
> I have specs, I have firmware, there is for arm open source drivers
> (including firmware in .h file):
> https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c

Just so we are clear: the driver above is not an open source driver.
Even though it has MODULE_LICENSE("GPL") to circumvent kernel module
loading policies the actual copyright notice in the sources say that the
code is proprietary.

If any code is taken from it the resulting driver should not be
submitted for inclusion in mainline Linux kernel unless it is done by
ChipOne themselves.

Thanks.

-- 
Dmitry

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

"find this hard to believe. If you inspect /proc/bus/input/devices you
should be able to see the parent device for the touchscreen (via sysfs
entry) and if you inspect sysfs you should be able to see the driver
that is connected to the device (unless they use i2c dev from userspace
but then they'd have to resort to polling and their battery life would
be abysmal)"

Yep me too, but : as a wrote before - it is so:

cat /proc/bus/input/devices:

I: Bus=0000 Vendor=0000 Product=0000 Version=0000  - so nothing!
N: Name="chipone-ts"
P: Phys=
S: Sysfs=/devices/virtual/input/input3 ---- this one I have described
before with modalias!
U: Uniq=
H: Handlers=kbd event3
B: Prop=2
B: EV=b
B: KEY=2000000 0 40000800 40 0 0 0
B: ABS=2658000 0

Regards,
                   Serge Kolotylo.


On Wed, Mar 2, 2016 at 9:19 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Mar 02, 2016 at 06:13:27PM +0000, sergk sergk2mail wrote:
>> "Why do you think that mlsfw in modalias string has anything to do with
>> loading firmware? I must have misunderstood your statement..."
>>
>> Hi Dmitriy,
>>   Its rather guessing based on such disovering: On Chuwi Vi10 rev 11
>> under Android the only touch related module that is loaded is
>> atmel_mxt_ts while I exactly know (and have firmware too) that in this
>> tablet there is Chipone icn8528.h.   (drivers from Windows + dmesg
>> provs this).
>> When you rmmod atmel_mxt_ts the touch still continues to work! I guess
>> someone just used atmel_mxt_ts probably as prototype for detecting
>> (wake uping) chip and loading its firmware and after - no need in any
>> module. According specs of Chipone icn85xx it looks that it even has
>> corresponding mode - to be initialized from firmware and work after
>> with it. It looks weird, but this is the clevest explanation that I
>> could provide - I never seen before such behaviour in Android when
>> there is no dedicated driver for touch screen.
>
> I find this hard to believe. If you inspect /proc/bus/input/devices you
> should be able to see the parent device for the touchscreen (via sysfs
> entry) and if you inspect sysfs you should be able to see the driver
> that is connected to the device (unless they use i2c dev from userspace
> but then they'd have to resort to polling and their battery life would
> be abysmal).
>
>>
>> In anyway - this is only curiousity, the main goal is simple - to
>> create a driver for icn85xx that wakeup it and loads firmware.
>> I have specs, I have firmware, there is for arm open source drivers
>> (including firmware in .h file):
>> https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
>
> Just so we are clear: the driver above is not an open source driver.
> Even though it has MODULE_LICENSE("GPL") to circumvent kernel module
> loading policies the actual copyright notice in the sources say that the
> code is proprietary.
>
> If any code is taken from it the resulting driver should not be
> submitted for inclusion in mainline Linux kernel unless it is done by
> ChipOne themselves.
>
> Thanks.
>
> --
> Dmitry

Re: How to use ACPI for touchscreen

[sergk sergk2mail]

Hi ALL,

Please help (ideally adding some code to my skeleton) how to obtain
info in i2c client driver from ACPI DSD table.

According kernel docs I have used this one skeleton:
========================================================
#define DEVICE_NAME  "testme"

static const struct acpi_device_id icn_ts_acpi_match[] = {
    { "CHPN0001", 0 },
    { "PNP05C0", 0 },
    { },
};
MODULE_DEVICE_TABLE(acpi, icn_ts_acpi_match);


static int ts_probe(struct i2c_client *client, const struct i2c_device_id *id){
    printk("Hello from %s",__func__);

    printk(&client->dev, "%s: got a device named %s at address 0x%x,
IRQ %d, flags 0x%x\n", __func__, client->name, client->addr,
client->irq, client->flags);

return 0;
}

static struct i2c_driver icn_ts_driver = {
    .probe = ts_probe,
    .remove = ts_remove,
    .id_table = ts_i2c_id,
    .driver = {
        .name = DEVICE_NAME,
        .owner = THIS_MODULE,
        .acpi_match_table = ACPI_PTR(icn_ts_acpi_match),

    },
};

static const struct i2c_device_id ts_i2c_id[] = {
    { DEVICE_NAME, 0 },
    { }
};
MODULE_DEVICE_TABLE(i2c, gsl_ts_i2c_id);


module_i2c_driver(icn_ts_driver);

===============================================


As result - nothing until I create i2c device with the name testme. I
am using user space way from kernel doc: echo testme 0x30 >
/sys/bus/i2c/devices/i2c-3/new_device.

ONLY AFTER this (Creating i2c device) I receive output from .probe function.
And as result I do NOT receive NOTHING ACPI related because i2c device
was created manually and all information is taken from my manual
created dev (bus address and bus number), no irq - nothing while DSDT
HAS THIS INFO!


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


MAIN QUESTIONS:

1) What is wrong with i2c client driver code? Why it is NOT obtain
info from ACPI DSD table?

2) In which way should be created i2c dev while registering i2c acpi
driver? Who\where\what and how should create this i2c device?


3) how to obtain info from ACPI DSD table?
In kernel doc there is a few lines but there is no enough detail explanation:


"This means that when ACPI_HANDLE(dev) returns non-NULL the device was
enumerated from ACPI namespace. This handle can be used to extract other
device-specific configuration."

PS: In Android I have seen some technic when 1st is created platform
driver, then via ACPI handle it gather all DSDT info.

Could some one example this with code (skeleton) and how then move
from platfrom driver to i2c client driver?

Regards,
                 Serge Kolotylo.

On Wed, Mar 2, 2016 at 11:01 PM, sergk sergk2mail <sergk.admin@gmail.com> wrote:
> "find this hard to believe. If you inspect /proc/bus/input/devices you
> should be able to see the parent device for the touchscreen (via sysfs
> entry) and if you inspect sysfs you should be able to see the driver
> that is connected to the device (unless they use i2c dev from userspace
> but then they'd have to resort to polling and their battery life would
> be abysmal)"
>
> Yep me too, but : as a wrote before - it is so:
>
> cat /proc/bus/input/devices:
>
> I: Bus=0000 Vendor=0000 Product=0000 Version=0000  - so nothing!
> N: Name="chipone-ts"
> P: Phys=
> S: Sysfs=/devices/virtual/input/input3 ---- this one I have described
> before with modalias!
> U: Uniq=
> H: Handlers=kbd event3
> B: Prop=2
> B: EV=b
> B: KEY=2000000 0 40000800 40 0 0 0
> B: ABS=2658000 0
>
> Regards,
>                    Serge Kolotylo.
>
>
> On Wed, Mar 2, 2016 at 9:19 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Wed, Mar 02, 2016 at 06:13:27PM +0000, sergk sergk2mail wrote:
>>> "Why do you think that mlsfw in modalias string has anything to do with
>>> loading firmware? I must have misunderstood your statement..."
>>>
>>> Hi Dmitriy,
>>>   Its rather guessing based on such disovering: On Chuwi Vi10 rev 11
>>> under Android the only touch related module that is loaded is
>>> atmel_mxt_ts while I exactly know (and have firmware too) that in this
>>> tablet there is Chipone icn8528.h.   (drivers from Windows + dmesg
>>> provs this).
>>> When you rmmod atmel_mxt_ts the touch still continues to work! I guess
>>> someone just used atmel_mxt_ts probably as prototype for detecting
>>> (wake uping) chip and loading its firmware and after - no need in any
>>> module. According specs of Chipone icn85xx it looks that it even has
>>> corresponding mode - to be initialized from firmware and work after
>>> with it. It looks weird, but this is the clevest explanation that I
>>> could provide - I never seen before such behaviour in Android when
>>> there is no dedicated driver for touch screen.
>>
>> I find this hard to believe. If you inspect /proc/bus/input/devices you
>> should be able to see the parent device for the touchscreen (via sysfs
>> entry) and if you inspect sysfs you should be able to see the driver
>> that is connected to the device (unless they use i2c dev from userspace
>> but then they'd have to resort to polling and their battery life would
>> be abysmal).
>>
>>>
>>> In anyway - this is only curiousity, the main goal is simple - to
>>> create a driver for icn85xx that wakeup it and loads firmware.
>>> I have specs, I have firmware, there is for arm open source drivers
>>> (including firmware in .h file):
>>> https://github.com/bbelos/rk3188-kernel/blob/master/drivers/input/touchscreen/ICN8503/icn85xx.c
>>
>> Just so we are clear: the driver above is not an open source driver.
>> Even though it has MODULE_LICENSE("GPL") to circumvent kernel module
>> loading policies the actual copyright notice in the sources say that the
>> code is proprietary.
>>
>> If any code is taken from it the resulting driver should not be
>> submitted for inclusion in mainline Linux kernel unless it is done by
>> ChipOne themselves.
>>
>> Thanks.
>>
>> --
>> Dmitry