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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
