Sorry for the delayed response. I wasn’t able to make any further progress - the wakeup interrupt works the way I described before.
I might try this with another display and thus another touch controller just to check if it’s a driver matter.
While you try with another display, can you tell me if there is a possibility to wake up the SoM using the display’s !INT line (and maybe additional hardware)?
I am thinking of connecting the !INT line to another GPIO (in parallel with the existing connection) and setting that GPIO as a wake up source. However, I am not sure how to do this or if I need additional components to properly do it.
I’ve tried connecting the !INT line to a GPIO configured as a wake up source in the device tree using gpio-keys (I’ve tested it using a push button and confirm that the pin works), but the SoM did not wake up. Maybe the touch controller’s interrupt duration is too small (a monostable multivibrator could prove useful in this case).
So I tried this with another display which uses a Goodix controller and it worked just the way it should just by adding wakeup-source to the device tree node.
This seems like an issue with this Atmel controller driver, then.
I think your idea of connecting the interrupt line externally would work indeed, but as you might have noticed, you might need some additional hardware. You can try debouncing the signal with a simple filter or go the monostable multivibrator approach.
I confirm that the wakeup works with a different touch controller (Focaltech FT5406 - datasheet, Linux driver), found on the display ETM070080BDH6. So this problem is related with the Atmel controller driver.
However, after waking up from sleep, the touch controller does not respond (I touch the screen and nothing happens). I’ve tried disabling/enabling the touch controller using xinput, but with no success. I have to restart the system to make it work again.
If it helps debugging this issue, after the SoM wakes up I’ve noticed a imx-i2c 21a0000.i2c: Unbalanced pm_runtime_enable! error in dmesg and i2cdetect detects only the devices under kernel control. This is the dmesg output:
dmesg | grep i2c
[ 0.393645] i2c i2c-0: IMX I2C adapter registered
[ 0.395432] i2c i2c-1: IMX I2C adapter registered
[ 0.396844] i2c i2c-3: IMX I2C adapter registered
[ 0.872153] input: AD7879 Touchscreen as /devices/soc0/soc/2100000.aips-bus/21a4000.i2c/i2c-1/1-002c/input/input0
[ 1.211436] input: EP0700M09 as /devices/soc0/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0038/input/input1
[ 1.225476] i2c /dev entries driver
[ 155.344389] imx-i2c 21a0000.i2c: Unbalanced pm_runtime_enable!
This is the i2cdetect output before sleep:
i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- 14 -- -- -- -- -- -- -- -- -- -- --
20: UU UU -- -- 24 -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- 37 UU -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- UU -- -- 54 -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
and after waking up by pressing the touchscreen:
i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
I don’t know what to make of this information. I mention that the touch controller’s address is 0x38. I’ve even tried unbinding and binding the I2C device, but with no success. (echo -n "21a0000.i2c" /sys/bus/platform/drivers/imx-i2c/21a0000.i2c/driver/unbind or /bind)
Can you please help me resolve this issue?
Dear @CristianM,
Since we now know that the issue lies within the atmel driver, I would analyze it closely and try to find the parts related to power settings (sleep mode, wake up) and to the I2C subsystem itself. It can be that this is a use case that wasn’t tested by whoever wrote that driver.
Can you confirm the kernel version running? Another approach would be to diff the driver between different kernel versions and investigate any changes that may arise.
Dear @gustavo.tx,
This is my kernel version: 5.4.91-5.2.0-devel+git.590db576d04d. The wakeup works as I need with the other display/touch controller, but afterwards something happens with the touch controller or I2C bus. I will use this controller if this issue can be resolved. Please see the details in my previous response.