Re: вопрос по suspend/resume в goodix

[Dmitry Mastykin <mastichi@gmail.com>]

Thank you Hans!

Your explanations were extremely useful!
Manufacturer answered, he had an error in pin numbers.

I've changed table to:
--------------------
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveHigh, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0015
}
GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0019
}
})
Now the I2C address is stably detected. But interrupt doesn't work:
Goodix-TS i2c-GDIX1002:00: request IRQ failed: -1
--------------------

If I use:
--------------------
I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C3",
0x00, ResourceConsumer, , Exclusive,
)
GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0015
}
GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0019
}
Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared, ,, )
{
0x00000032,
}
})
--------------------
there is no error, but no interrupt is generated.

I understand that the problem is far from the driver but may be you
could suggest where the problem is.
Thank you!

Dmitry

On Fri, Dec 20, 2019 at 1:45 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 19-12-2019 10:10, Dmitry Mastykin wrote:
> > Hi,
> >>> I discovered what was with my device.
> >>> After suspend/resume I2C address often changes to 0x5d (and ACPI table
> >>> has 0x14).
> >>>
> >> Often but not always?
> >>
> > Yes, I think this is because INT from chipset side is tri-stated.
> >
> > I'm attaching the acpidump.
>
> Thanks, hmm, so looking at the acpidump, your device is using an Apollo
> Lake and thus definitely is NOT the fieldbook-k122 as that is using
> a Cherry Trail SoC and not an Apollo Lake SoC.
>
> It is also using a GPIO pin configured in direct-irq mode pin for the IRQ line:
>
>         Name (RBUF, ResourceTemplate ()
>         {
>             I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80,
>                 AddressingMode7Bit, "\\_SB.PCI0.I2C3",
>                 0x00, ResourceConsumer, , Exclusive,
>                 )
>             Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
>             {
>                 0x00000032,
>             }
>             GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                 "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                 )
>                 {   // Pin list
>                     0x0019
>                 }
>             GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                 "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                 )
>                 {   // Pin list
>                     0x0005
>                 }
>         })
>
> And both GPIOs are listed as output-only which certainly does not match the
> IRQ pin. So this setup is a bit foobar and the plan I have to allow the touchscreen
> to properly power-down on suspend on Cherry Trail devices, will not work here :|
>
> For reference here are the ACPI resources for a GDIX touchscreen on Cherry Trail:
>
>      Name (WBUF, ResourceTemplate ()
>      {
>          I2cSerialBusV2 (0x0014, ControllerInitiated, 0x00061A80,
>              AddressingMode7Bit, "\\_SB.PCI0.I2C6",
>              0x00, ResourceConsumer, , Exclusive,
>              )
>          GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000,
>              "\\_SB.GPO3", 0x00, ResourceConsumer, ,
>              )
>              {   // Pin list
>                  0x004D
>              }
>          GpioIo (Shared, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>              "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>              )
>              {   // Pin list
>                  0x0014
>              }
>      })
>
> Notice how the Interrupt is specified as a GpioInt so we should be able
> to use it as a GPIO during suspend so that we can wakeup the touchscreen on
> resume...
>
> I'm afraid I do not have any easy ideas / fixes for how to fix the issue
> you are seeing on your device.
>
> Regards,
>
> Hans
>
>
>
>
> > On Wed, Dec 18, 2019 at 6:07 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 18-12-2019 15:50, Dmitry Mastykin wrote:
> >>> Hi,
> >>>
> >>> I discovered what was with my device.
> >>> After suspend/resume I2C address often changes to 0x5d (and ACPI table
> >>> has 0x14).
> >>
> >> Often but not always?
> >>
> >>> ACPI tables doesn't contain _DSD section, and GPIOs are not mapped to
> >>> ts->gpiod_int/rst. They are NULL. So reset sequence is not called.
> >>> That's why rmmod/insmod doesn't help.
> >>>
> >>> (As temporary solution i changed client->addr, and will wait for
> >>> better ACPI tables.
> >>> I tried also to map gpios by index and seems that RESET works but INT
> >>> doesn't. I can't change I2C address by reset sequence.
> >>> I've sent a question to tablet's manufacturer about that.)
> >>
> >> Interesting, can you provide an acpidump of the device:
> >>
> >> sudo acpidump -o acpidump
> >>
> >> And then attach the generated acpidump file to your next email ?
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>>
> >>>> On most newer devices (such as the GPD) the IRQ pin is actually declared
> >>>> as a GpioInt in the ACPI tables, so we should be able to use it as a GPIO
> >>>> with some extra work.
> >>>>
> >>> I will be glad to test this when it's ready provided I have new ACPI tables.
> >>>
> >>> Thank you!
> >>> Kind regards,
> >>> Dmitry Mastykin
> >>>
> >>> On Wed, Dec 18, 2019 at 9:16 AM Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 13-12-2019 09:17, Dmitry Mastykin wrote:
> >>>>> Hi guys!
> >>>>> Thank you very much for your answers, it's always surprising how fast
> >>>>> the community reacts!
> >>>>>
> >>>>>> We have reports of the touchscreen no longer working after suspend/resume
> >>>>>> on some GPD pocket devices, but not combined with these errors.
> >>>>>>
> >>>>> I copied my error messages precisely from gpd support site, because I
> >>>>> have the same:
> >>>>> https://gpdsupport.com/t/touchscreen-issue-resolved/132/84
> >>>>> But seems that rmmod/insmod helps in their case.
> >>>>> I noticed that the problem is not repeatable. But happens very often.
> >>>>
> >>>> Interesting I did not realize the same errors are showing on the GPD pocket.
> >>>>
> >>>> I have the feeling this might have something todo with us not putting the
> >>>> touchscreen controller to sleep on ACPI devices because we cannot use
> >>>> the IRQ pin as GPIO which is necessary for wakeup.
> >>>>
> >>>> On most newer devices (such as the GPD) the IRQ pin is actually declared
> >>>> as a GpioInt in the ACPI tables, so we should be able to use it as a GPIO
> >>>> with some extra work.
> >>>>
> >>>> I plan to write a patch to make us do this sometime in the near future
> >>>> (no idea when I will get around to this though). I will put you
> >>>> (Dmitry Mastykin) in the Cc of the patch when I get around to writing it.
> >>>>
> >>>> Note I do not know if this patch will actually help.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hans
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> When this happens, are these messages appear constantly, or only in
> >>>>>> response to actual touch? Can you still interact with the device?
> >>>>>>
> >>>>> Constantly with 25Hz frequency.
> >>>>>
> >>>>>> The fact that you can talk to the controller like that is interesting.
> >>>>>> Just to confirm, does it return sane data, or garbage?
> >>>>>>
> >>>>> root@or212:/home/u# i2cset -y 6 0x5d 0x81 0x4e 0x00 i
> >>>>> root@or212:/home/u# i2cset -y 6 0x5d 0x81 0x4e i
> >>>>> root@or212:/home/u# i2cget -y 6 0x5d
> >>>>> 0x83
> >>>>> root@or212:/home/u# i2cset -y 6 0x5d 0x81 0x4e 0x00 i
> >>>>> root@or212:/home/u# i2cset -y 6 0x5d 0x81 0x4e i
> >>>>> root@or212:/home/u# i2cget -y 6 0x5d
> >>>>> 0x81
> >>>>> First I touch with 3 fingers, then with one.
> >>>>>
> >>>>>> What is the model of the tablet?
> >>>>>>
> >>>>> Not sure about model, seems that it's this one:
> >>>>> http://logic-instrument.com/en/fieldbook-k122.php
> >>>>>
> >>>>> Dmesg is attached
> >>>>>
> >>>>> Thank you!
> >>>>> Kind regards,
> >>>>> Dmitry Mastykin
> >>>>>
> >>>>> On Thu, Dec 12, 2019 at 11:51 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 12-12-2019 20:20, Dmitry Torokhov wrote:
> >>>>>>> Hi Dmitry,
> >>>>>>>
> >>>>>>> On Thu, Dec 12, 2019 at 06:34:46PM +0300, Dmitry Mastykin wrote:
> >>>>>>>> Здравствуйте, Дмитрий.
> >>>>>>>> Простите, что отвлекаю, если что - не отвечайте и в лучшем случае
> >>>>>>>> пошлите в mail-list)
> >>>>>>>> У меня есть планшет с x86, вариантом Debian с ядром 4.15 и
> >>>>>>>> контроллером тач-скрина gt928.
> >>>>>>>
> >>>>>>> What is the model of the tablet?
> >>>>>>>
> >>>>>>>> После suspend/resume не всегда, но очень часто тачскрин перестает
> >>>>>>>> работать и постоянно выводит:
> >>>>>>>> [ 3276.729412] Goodix-TS i2c-GDIX1002:00: I2C write end_cmd error
> >>>>>>>> [ 3276.770153] Goodix-TS i2c-GDIX1002:00: I2C transfer error: -121
> >>>>>>>
> >>>>>>> When this happens, are these messages appear constantly, or only in
> >>>>>>> response to actual touch? Can you still interact with the device?
> >>>>>>>
> >>>>>>> Could you please send the full dmesg so we know more about the device.
> >>>>>>>
> >>>>>>> Hans, Bastien, have you seen such issues with Goodix occasionally
> >>>>>>> misbehaving on resume?
> >>>>>>
> >>>>>> We have reports of the touchscreen no longer working after suspend/resume
> >>>>>> on some GPD pocket devices, but not combined with these errors.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Hans
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>> По i2cget/i2cset контроллер успешно отвечает.
> >>>>>>>
> >>>>>>> The fact that you can talk to the controller like that is interesting.
> >>>>>>> Just to confirm, does it return sane data, or garbage?
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
>