Bug 199207

Created attachment 275685 [details]
Kernel log excerpt from suspend to error messages after resume

I've got same issue on Chuwi Hi13 tablet (Intel Appolo Lake N3450).
After Suspend/Resume Goodix touchscreen behind Synopsys Designware i2c-device becomes unavailable and Linux floods system log with following:
kernel: i2c_designware i2c_designware.3: timeout waiting for bus ready
kernel: Goodix-TS i2c-GDIX1002:00: I2C transfer error: -110

Kernel log excerpt from suspend to error messages after resume is attached.

Created attachment 275687 [details]
Kernel log excerpt from removing to restoring

It's possible to restore touchscreen operation with deleting/discovering device under root:
echo 1 > /sys/bus/pci/devices/0000\:00\:16.3/remove
echo 1 > /sys/devices/pci0000\:00/pci_bus/0000\:00/rescan

PCI name of device may vary.

Kernel log excerpt from removing to restoring is attached.

Looks like in both cases i2c-desingware was without power after resume: "Unknown Synopsys component type: 0xffffffff". Do you have kernel log after successful resume?

You might also want to make sure that this patch:
faec44b6838312484d63e82286087cf2d5ebb891
is in your tree. It's called "Input: goodix - disable IRQs while suspended".

I don't know if it's in the kernel you're using.

(In reply to Jarkko Nikula from comment #3)
> Looks like in both cases i2c-desingware was without power after resume:
> "Unknown Synopsys component type: 0xffffffff". Do you have kernel log after
> successful resume?

Unfortunately, I don't, since "successful resume" never happened at my tablet. The issue is 100% reproducible.


(In reply to Bastien Nocera from comment #4)
> You might also want to make sure that this patch:
> faec44b6838312484d63e82286087cf2d5ebb891
> is in your tree. It's called "Input: goodix - disable IRQs while suspended".
> 
> I don't know if it's in the kernel you're using.

Yes, patch faec44b6838312484d63e82286087cf2d5ebb891 is in my tree. I use kernel 4.16.3 compiled from source. And in goodix.c I can see lines:
	if (!ts->gpiod_int || !ts->gpiod_rst) {
		disable_irq(client->irq);
corresponding to the patch.


Where should I "dig" to provide you with additional info?
May be increase logging level or use sysfs dynamic_debug for modules goodix/i2c_designware*.

Some update from OP here ... I am using a different GPD Pocket unit now and an
updated OS (Ubuntu 18.04) currently with kernel 4.18-rc1 from the linux-sunxi
branch by Hans de Goede.

I so far did not observe a missing touchscreen, but the timeout messages are 
still there. What I did not see yet is the I2C transfer error.

These are still present:


Jun 29 10:47:55: i2c_designware 808622C1:00: Unknown Synopsys component type: 0xffffffff

Jun 29 10:47:57: i2c_designware 808622C1:01: timeout in disabling adapter

[ 1554.922768] i2c_designware 808622C1:01: controller timed out
[ 1555.946911] i2c_designware 808622C1:01: controller timed out

[ 4555.908518] i2c_designware 808622C1:00: timeout waiting for bus ready
[ 4555.936961] i2c_designware 808622C1:00: timeout waiting for bus ready


Preferrably, they happen after a resume cycle. Sometimes they occur with a rate
that drowns out all else in the kernel log. Maybe we can just experiment
with some increased timeouts?

Same i2c timeouts and Goodix error messages on GPD Win 2.

> currently with kernel 4.18-rc1 from the linux-sunxi branch by Hans de Goede

Did you tested this issue with upstream 4.18 build? Possibly necessary patches in upstream by now.

I tested up to kernel.org 4.18-rc5. I switched to 4.17.8 for now, as I experienced a high likelihood of a blank screen after grub2 (where the initramfs waits for me to enter the password for LUKS). Occasional intel gfx troubles are nothing new to me and I hoped that gets ironed out before 4.18 proper.

Anyway, are there specific changes in 4.18-rc6 that concern i2c_designware?

So far, it runs rather well with 4.17.8 as long as I do not attempt suspend to disk. On resume from hibernation, I usuallly don't lose the touchscreen, but the charger and/or battery monitoring instead.

PS: Also with 4.17.8, I get GPU errors, but they don't seem to have long-lasting effects. On resume from s2idle, it's such rather often:

[209268.085465] PM: suspend devices took 1.453 seconds
[212306.645823] ------------[ cut here ]------------
[212306.645833] Unclaimed write to register 0x1e0100
[212306.646215] WARNING: CPU: 0 PID: 23726 at drivers/gpu/drm/i915/intel_uncore.c:1070 __unclaimed_reg_debug+0x46/0x60 [i915]

I figured that I'd first get the basic trouble with i2c settled beffore battling the intel GPU again, which I probably have to if switching to 4.18:-(

> I switched to 4.17.8 for now, as I experienced a high likelihood of a blank
> screen after grub2 (where the initramfs waits for me to enter the password
> for LUKS)

Did you reported this issue anywhere? 

> Also with 4.17.8, I get GPU errors, but they don't seem to have long-lasting
> effects. 

Please follow this steps to report this issue: 

https://01.org/linuxgraphics/documentation/how-report-bugs

drm-tip packages: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/

I know I should report the issues. For the blank screen on boot one I wanted to pin down the commit that caused it first, but that takes unnerving time spent on testing. THe GPU error, yeah, that shoud be easier, just copying the dmesg ...

About the blank screen issue: This might be related to some surrounding machinery (boot loader?). I cannot reproduce it right now, after some Ubuntu updates. I will report if it reappears in a consistent manner.

I will test the most current 4.18 rc again, but I repeat my question: is there something specific after rc5 that should fix the i2c trouble?

> is there something specific after rc5 that should fix the i2c trouble?

I just focused attention on the fact that most of Hans patches already part of upstream kernel.

Created attachment 277829 [details]
log with errors using 4.18-rc8

Yes, I am using the upstream kernel since 4.17 now. I have two little patches on top that do not change the mechanics of resuming device drivers.

I updated my git checkout and tested with 4.18-rc8 now. While s2idle works fine now apart from a little trouble that has user space processes try to write to my USB-connected /home too early (adding a delay after starting kernel threads helps), the resume from hibernation is still resulting in the driver errors.

In my case, with this specific GPD Pocket device, the touchscreen is not affected. But the analog audio output broke. Battery monitoring still works, but charging is broken (only gives 5 V 500 mA, no negotiation of charging modes that would not still deplete the battery);

Regarding hibernation issues, I think two separate reports is necessary (for audio output and for charging).

Reverting this commit https://github.com/torvalds/linux/commit/12864ff8545f6b8144fdf1bb89b5663357f29ec4 or just trying 4.18rc7 also could make a difference.

I just booted rc5 again (before the named commit, I presume) and the audio is also broken after resume from disk. This probably has always been the case, only recently I am more aware of this after blacklisting the HDMI LPE audio module so that pulseaudio starts up at _all_.

The audio being flaky in general is a separate issue, but I do think that it being specifically broken at resume from disk could have a common cause with the touchscreen and i2c issues. So far I see the charging issue to be another symptom of the same problem as the touchscreen failure. Aren't they both caused by failing i2c bus?

I can of course create another bug report for the charger, but I wonder if that is of any help. I expect that problem to disappear once the basic i2c functionality is ensured.

I reckecked a suspend on my Chuwi Hi13 under linux 4.19.0 and it seems the problem has gone.

On GPD Win 2 issue is still reproducible with Linux 4.19.0.

I have just posted a series of Goodix touchscreen driver patches upstream:
https://lore.kernel.org/linux-input/20200101145429.16185-1-hdegoede@redhat.com/T/#t

Which fix some suspend/resume issues with Goodix touchscreens which might help here. I'm not sure these fix this though, as some of the debugging done here so far suggests that this is a i2c controller or suspend-ordering issue, rather then an issue with the touchscreen driver.

These patches are also available in my personal kernel git repo:
https://github.com/jwrdegoede/linux-sunxi/commits/master