I’ve just tested the recent kernel update and it looks like this bug is really fixed! My test case is Waydroid with user data on sd-card. Previously, without my workaround, I got an i/o error after the first suspend. Now I’m able to suspend/resume several times without any issue! Thank you very much for so delicate work!
In fact, another issue with the display happen one time. Did you familiar with that? I mean the repeated messages like this:
March 23 10:11:34 pureos kernel: edt_ft5x06 2-0038: Unable to fetch data, error: -6
It floods my logs and the screen stays black. Sometime it is trying to on, I see a picture for a second or less, but finally it fails. Complete reboot fix the issue for a day or two.
As far as I remember I observed it all time and reported here previously. And I can not recognize how the display bug may be connected with the touchscreen debug message…
The message means that the driver attempted to read the data from the touchscreen after receiving an interrupt, but couldn’t do so.
Since the touchscreen’s and the display’s power is shared, whenever the display is turned off, the touchscreen goes off too. However, currently the touchscreen driver isn’t aware of the display being turned off, so it gets an interrupt and tries to read from now turned off touchscreen. This obviously fails - and that’s why it’s currently expected to see such message when turning the screen off.
In your case, it would seem like your display module may experience some kind of power issues. You see a flood of messages because the interrupt from the touchscreen keeps firing - perhaps its power keeps browning out when in this state.
I’m afraid that this really smells like a hardware issue, you may want to replace your display, or at least check its connector.
Thanks a lot for so detailed explanation! I also have another idea about this issue - i2c bus can be locked by some random spikes… I’ve found one confirmation for that. In fact, imx-i2c driver has a workaround, but it does not work in our case as soon as it not configured in the dts file. I’ve try to fix it and my four-hours test is very positive! I will look further and write more detailed description of my investigations
I meant random spikes from environment caused by electrostatic discharges which can be considered as start/stop conditions of an I2C bus. This link reveals the problem for another circuit, but it looks like it is also valid for Librem5.
I have an IMX9 here. I pulled the I2C to ground and the recovery seems to work. Does anyone know where a test point is located on the LM5?
Then I can test the recovery.
But spikes shouldn’t occur anyway. Do you have access to an oscilloscope?
Software I2C recovery is definitely disabled in Librem5 as far as the related GPIO pins are not configured. This is my patch to activate it. I believe @dos could examine and push it to upstream.
This is dmesg output after applying the patch:
$ sudo dmesg | grep i2c | grep sda
[ 1.259563] imx-i2c 30a20000.i2c: using DT '/soc@0/bus@30800000/i2c@30a20000' for 'sda' GPIO lookup
[ 1.259605] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a20000[0]' - status (0)
[ 1.276907] imx-i2c 30a30000.i2c: using DT '/soc@0/bus@30800000/i2c@30a30000' for 'sda' GPIO lookup
[ 1.276956] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a30000[0]' - status (0)
[ 1.279998] imx-i2c 30a40000.i2c: using DT '/soc@0/bus@30800000/i2c@30a40000' for 'sda' GPIO lookup
[ 1.280039] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a40000[0]' - status (0)
[ 1.283571] imx-i2c 30a50000.i2c: using DT '/soc@0/bus@30800000/i2c@30a50000' for 'sda' GPIO lookup
[ 1.283615] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a50000[0]' - status (0)
Finally, it is some kind of ESD protection. I have an oscilloscope but it wont help as far the issue occurs unpredictably during a day. But that is more interesting - I do not observed the display hangup anymore throughout the last three days! I’ve checked the logs. Sometimes a few messages about edt_ft5x06 error occurred in a row, but the phone remains fully functional.
